校园外卖小程序搭建方式怎么选？让版本变更使旧验收失效

校园外卖小程序选择搭建方式时，功能演示必须对应实际版本和所选模块。本文处理一个具体工程问题：演示版已通过，交付时却换了版本，仍沿用旧审批。将方案版本、能力清单与验收状态绑定，避免旧结果被误用。

数据模型与约束

proposal以project_id、revision为联合主键，revision为递增整数；保存package_version、manifest_digest、phase和row_version。phase取draft、reviewed、tested、accepted、superseded。manifest_item以project_id、revision、requirement_id唯一，记录delivery、owner与dependency_status。

test_report保存proposal_revision、package_version、manifest_digest及每项结果。approval同样绑定完整三元组和审批人，不能只绑定一个项目名。内容变更新建revision，旧版本标superseded，报告不迁移到新版本。接口服务必须鉴权，并验证审批人有项目权限；模型不处理实际产品授权。

正常输入与逐步输出

构造项目C1、revision=3、package_version=v1、digest=H3，需求R1为中转模块。依赖确认后draft→reviewed；报告绑定3/v1/H3且R1通过，转tested；有权限的负责人签收后accepted。加入取餐柜R2，生成revision=4、digest=H4，phase=draft；3/v1/H3报告不能批准4/v1/H4。以上为设计预期，未执行完整系统测试。

核心更新约束

BEGIN;
SELECT row_version,phase,manifest_digest FROM proposal
 WHERE project_id=:project AND revision=:revision FOR UPDATE;
-- 锁内核验认证权限、当前phase、报告绑定版本和摘要
UPDATE proposal SET phase='accepted',row_version=row_version+1
 WHERE project_id=:project AND revision=:revision
 AND row_version=:expected_row_version AND phase='tested'
 AND manifest_digest=:tested_digest;
-- 影响行数必须为1，否则回滚，返回冲突并重读
INSERT INTO approval(project_id,revision,manifest_digest,approver)
 VALUES(:project,:revision,:tested_digest,:authenticated_approver);
COMMIT;

为什么只记一次通过还不够

若报告只存project_id，换套餐、换模块以后查询仍可能返回旧通过。审批与报告绑定相同不可变版本，变更产生新revision，可使旧报告明确失效。保存清单和报告原件，摘要只能帮助校验内容一致，不能证明测试真实或人员有权限。

选择托管产品、自有环境或二次开发时，都应将演示版本、模块范围和维护责任对应到相同需求。本文模型只支撑版本验收子问题，不提供具体产品实现、性能、价格或交付效果的证明。

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