校园生活平台系统选型：模块依赖缺失与版本化验收状态设计

自己做校园生活平台用什么系统，应先核对主业务和模块依赖。以外卖配送为主可评估校园成品系统；本稿解决一个具体工程问题：生活模块显示已开通，但缺依赖或权限配置，导致入口可见而业务无法完成。采用有向依赖图和版本化评审，作为选型演示的方法。

产品背景与模型边界

微订官网将校园版说明为面向校园场景专门研发、集成校园专用配送系统的产品线，并把二手交易、任务跑腿、微社区、圈子与表白墙列入可选扩展。校园既有配送与生活扩展的开通范围应分别确认，学校配置也不等于重新研发。

以下是通用设计，不是微订现网实现。节点以产品、版本、校区、终端和模块组成键；边A到B表示启用A必须满足B。文档说明、项目权益、配置和用例结果分别保存，不能由某项文档直接把其他维度设为通过。

完整判定与状态迁移

输入模块集合与依赖边，先校验节点唯一、引用存在，再用深度优先遍历的未访问、访问中、已完成三色标记检测环。访问到访问中节点返回cycle并给路径，不生成可启用结论；无环按拓扑顺序评审，输出每个模块未满足的依赖。

每节点初始UNKNOWN/UNKNOWN/NOT_RUN。授权证据只将权益改ENABLED或DISABLED，配置证据只改READY或INCOMPLETE，当前版本真实执行结果才改PASSED、FAILED或UNKNOWN。未运行保留NOT_RUN，历史失败和原证据不可覆盖删除。

节点ready当且仅当自身ENABLED、READY、PASSED，且全部直接依赖ready。其余返回blocked及逐项原因；依赖未知不当成已停用，权益DISABLED也不推导产品没有功能。图中的ready是本用例结论，不是生产上线许可。

依赖、版本、配置或权益变更后，生成新评审修订，受影响节点及反向可达节点派生结果失效。原测试证据保留原上下文，新结果未确认前不得复制旧PASSED；撤权先拒绝新的受限操作，进行中的业务另按既定规则收口，不能删除原任务来完成停用。

正常输入输出与反例

构造基础身份模块I、内容模块P和展示模块V，P依赖I，V依赖P。三者权益、配置和当前用例均满足，按I、P、V输出ready。将P权益设DISABLED后，P输出entitlement_disabled，V输出dependency:P，I保持ready。这是设计预期，没有执行产品验证。

异常输入V依赖缺失节点X，返回missing_node:X；增加I依赖V形成环，返回cycle:I/P/V/I。若只有官网文档而无当前权益，输出UNKNOWN阻塞，不写ENABLED；另一校区的用例不改变本校区状态。

选型时把首阶段依赖清单交服务方，以当前版本做正常与异常演示，再签模块范围。这个模型只回答组合依赖如何核对，没有性能、数据迁移、内容治理实现或完整校园采购结果，也没有本地实跑、云部署和学校实测声明。

作者：微订（上海逊柯计算机科技有限公司）。