包括仍待完善的部分

跑得起来，但第一版必须砍功能。建议只开新鲜事、树洞、活动三块，认证只开邮箱一种。人手真正的瓶颈不在开发，在审核——「审核」的成本不在数量，在响应时间，所以最少要有两个人能轮。

开发本身不是关键路径。小程序发布审核，以及要做充值时的商户号主体认证都要预留时间。剩下的时间主要花在配学校、出题库、铺种子内容和拉审核班上。

系统自部署。硬成本是一台跑 MySQL 与 Redis 的服务器、一个对象存储桶、一个小程序账号；小程序账号同时支持网页扫码登录，要做充值再加一个商户号。流量成本主要在图片，而图片是客户端直传存储的，不经过应用服务器。

如果要开树洞和私信，几乎一定要。认证不是为了拦人，是为了让处罚有意义——删了号五分钟就能重注册的社区，任何治理手段都只是装饰。可以先只开邮箱认证，成本最低。

会，所以这里的匿名是「对其他用户匿名」，不是「对系统匿名」。内容照样过安全检测，照样可举报、可下架，处罚照样落到真实账号上。用户看到的只有一个马甲。

三层。默认配额：对方没回过你，最多发三条；用户可以把接收隐私调成「未回复仅三条」或者直接「禁止」；再加上拉黑与举报。私信也是举报的四类目标之一。

一周一轮、样本小，算法给出的结果既不比人工好，也不好解释。运营在配对工作台里看两份答卷、按下确认，出问题时能说清为什么这么配。

校区是一等实体，地理位置挂在校区上而不是学校上（同校两个校区在两个区是常态）。浏览范围里有「本校区」和「同区」两档落在这层。用户的校区自己选，学校不能自己改——学校是认证的产物。

可以。每所学校有自己的校级管理员、认证题库与门槛、内容范围。跨学校访问返回「不存在」而不是「无权限」，所以管理员既看不到、也试探不出别校有什么。

可以。组织管理员只管被授权的那一个组织，同校其他组织对他等同于不存在。校级管理员也能自己建本校的运营和审核员账号，但造不出平级或跨校的账号。

在你自己的数据库和对象存储里。系统是自部署的，没有必须回传的中心服务。

核心闭环已经能独立完成：网页支持 Native 扫码充值，也支持短信验证码绑定手机号。仍不能完全替代小程序的是微信订阅消息授权、微信手机号一键绑定等平台专属体验。

能。选择充值档位后，网页生成微信 Native 支付二维码；支付成功后会自动刷新余额和收支明细。小程序仍走 JSAPI 支付，两条链路共用订单、回调与对账。

能。网页使用短信验证码绑定手机号，绑定后可继续学生认证；小程序另有微信手机号一键绑定，两种方式落到同一个账号。

服务端按业务域纵向切分，一个域就是一个目录，里面是 controller / service / repository / entity / 出入参那几个固定子包。加一个新模块是新开一个目录，不是往五个扁平包里各塞几个文件。

公开内容、轮播和话题都可以浏览。最近搜索仍属于登录后的个性化能力，游客看不到这一小块；网页端会直接隐藏对应区块，不弹错误。发布、点赞、私信等写操作仍需登录。

服务端覆盖主线路径、已知易错点、实体与表结构一致性，并用真实 MySQL 验证迁移和手写 SQL。网页、管理台与小程序也有判据和业务逻辑测试，但组件渲染、浏览器集成及跨端支付回归仍偏薄，前端仍是下一步重点。