包括我们自己还没做完的部分

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

开发本身不是关键路径。认证服务号和商户号的主体认证以周计，应该最先去办。剩下的时间主要花在配学校、出题库、铺种子内容和拉审核班上。

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

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

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

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

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

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

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

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

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

目前不能，有两处硬缺口，见下一条。网页版覆盖了绝大部分浏览与互动能力，但充值和绑手机号做不了。

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

不能。现有下单接口返回的是小程序支付参数，浏览器拉不起来，需要补 JSAPI 或 Native 下单。网页的积分页会如实说明这一点，而不是给一个点了没反应的按钮。

不能。绑定收的是微信侧的加密数据，浏览器拿不到。而没绑手机号的账号走不完认证流程——所以新用户目前必须先在小程序里绑一次。认证页会把这句话直接显示出来并说明去哪绑。

大部分列表可以看，但轮播、最近搜索、话题这几个接口目前要求登录。网页端的处理是这些区块直接不渲染，而不是弹登录框或者报错。要让游客也能看，需要在服务端放开这几条。

覆盖的是主线路径与已知易错点，不是全量接口。实体与表结构的一致性有专门的校验测试；手写 SQL 的部分必须配集成测试，用真实 MySQL 而不是内存库——内存库的兼容模式会给出「测试通过但线上炸」的假信号。