落地手册
从零到上线的八件事
按顺序做。前三件决定这事能不能成，后五件决定它能开多久。
01
先划边界，别一次全开
十二个模块全开的第一版，通常死在没人管。建议首版只开新鲜事、树洞、活动三块，认证只开邮箱一种。等日活稳定、审核跟得上，再逐个放开闲置、评课、CP。
判断标准不是「功能做没做完」，是「出问题时有没有人能在两小时内处理」。
02
先去申请账号，它比开发慢
小程序账号、认证服务号、对象存储桶、发信邮箱；要做充值再加商户号。认证服务号和商户号都要走主体认证，周期以周计——这两件事应该在写第一行配置之前就开始办。
服务号与小程序要绑在同一个开放平台账号下，否则网页扫码登录和小程序登录会变成两个账号。
03
部署与迁移
准备 MySQL 8、Redis、JDK 25，把凭据配成环境变量。跑完建表与迁移脚本再启动；启动期会校验配置，缺哪一项会直接告诉你。
每段迁移脚本都要跑完。漏跑的那种典型症状是「操作成功但没生效」，比直接报错难查得多。
04
把学校配进去
建学校、学院、校区；决定这所学校开哪几种认证方式。开答题认证的话要先出题——题库按学校配，单选多选都行，还要定答对几题算过（留空就是必须全对）。
在线题目不够一套时，该校的答题认证会直接不可用而不是拿别校的题凑数。上线前先自己走一遍认证流程。
05
配运营位，别让首页空着
首页轮播、能力宫格、每日诗词、话题、首页分栏都在后台配。跳转路径按页面注册表校验，写错的路径提交不上去。
新建的运营位默认是下线状态，配完记得开。
06
组一个审核班
至少两个人轮，把学生认证审核和举报处理排进日程。驳回理由必须写具体——它会原样发给学生，模糊的理由会变成第二天的重复提交。
同一条被别人处理过时会有提示，不用担心两个人各判一次。
07
冷启动：先有内容，再有人
空社区没人愿意第一个发言。上线前一周由运营和社团先把内容铺起来：树洞几十条、活动两三场、闲置一批。第一批真实用户看到的应该是一个已经在运转的地方。
先开一个院系或一个校区，别一上来全校。范围小的时候，出问题也小。
08
上量之后：把权力下放
校级管理员可以自己建本校的运营与审核员账号；社团可以拿到只管自己那一个组织的管理员。一个人管全校的模式撑不过一个学期。
组织管理员看不到别的组织，也看不到别的学校——所以下放权限不等于放开数据。
多校区与多学校
两件事经常被混为一谈，但它们的处理方式完全不同。
一所学校多个校区
校区是一等实体，地理位置挂在校区上而不是学校上——同一所学校的两个校区在两个区是常态。浏览范围里的「本校区」「同区」直接落在这层结构上。用户的校区可以自己选，学校不行（学校是认证的产物）。
多所学校共用一套部署
可以。每所学校有自己的校级管理员、自己的认证题库与门槛、自己的内容范围。跨学校的资源访问返回「不存在」，管理员看不到别校的任何东西。全站级的内容（比如全站话题）由超管维护，校级管理员只读。
上线前检查
凭据全部从环境变量注入，没有明文写进配置文件
所有迁移脚本都跑过一遍，没有跳段
自己完整走一遍：注册 → 认证 → 发帖 → 评论 → 举报 → 后台处置
对象存储的跨域规则配好了，客户端真的能传上去
审核台有人排班，举报进来有人看得到
隐私政策与用户协议已经在客户端里可查
小程序页面路径与后台的注册表对得上
别人踩过的坑
认证流程自己没走完就上线
认证是新用户遇到的第一道门，它卡住等于全站卡住。上线前用一个全新账号从头走一遍，包括驳回后重新提交。
驳回理由写成「不符合要求」
学生会原样看到这句话，然后原样再提交一次。写清楚缺什么、怎么补，能省掉一半的重复审核。
上线当天首页是空的
运营位默认下线、没有种子内容——第一批用户看到的是一个废墟，他们不会来第二次。
只有一个人有后台账号
他一忙，整个社区的审核就停了。第一天就要有第二个人。