校园外卖案例怎样核验？用不可变资料版本避免旧审核引用新内容

核验校园外卖案例，先找第一方项目线索，再核主体、版本与交付范围。一个工程问题是资料文件更新后，旧结论悄悄变成引用新内容。下面将不可变材料版本、审核结论和撤回事件分开设计，使每次判断都能回到当时使用的版本。

具体数据模型与约束

材料主键为tenant_id、material_id、revision。revision为正整数，content_digest记录原始字节SHA-256；kind区分demo、delivery、operation，project_id、software_version和claim_scope非空。原始字节另存受控对象，登记后不允许原地替换。哈希用于比对，不证明材料真实。

审核记录用review_id作租户内唯一键，绑定material_id和revision，记录主张、审核人、时间和结论；必须外键指向确定版本。current_permission与append-only事件记录分开：资料撤回时增加事件并更新当前权限，不反向改写旧审核引用。后台鉴权和租户隔离是实现前提，不能由请求自行声明审核人。

完整事务边界与正常输入输出

登记流程在单个数据库事务中：校验认证租户及资料录入权限；锁定material当前行；读取最新revision；校验请求幂等键及payload摘要；分配下一revision；插入版本、事件及幂等回执；提交。相同请求同内容重试返回原revision。若提交回执丢失，按原request_id查询；查询失败不等于登记失败。

构造P-DEMO/v1材料M/revision1，主张是楼栋分类演示。审核R1明确引用M/1。随后上传修订材料形成M/2：查询R1仍返回M/1，查询当前候选返回M/2且待审。撤回M后，当前展示返回withdrawn；R1的历史引用保留但不作为继续展示许可。以上是设计预期，未称真实执行输出。

BEGIN;
-- 锁定本租户材料的当前权限与版本头，行必须预先创建
SELECT revision, permission_state FROM material_head
 WHERE tenant_id=:tenant AND material_id=:id FOR UPDATE;
-- 应用层在锁内检查权限、原revision和request_id内容摘要
-- 每次登记插入新版本，不UPDATE material_version.content_digest
INSERT INTO material_version(tenant_id,material_id,revision,project_id,content_digest,kind,claim_scope)
 VALUES(:tenant,:id,:next,:project,:digest,:kind,:scope);
UPDATE material_head SET revision=:next WHERE tenant_id=:tenant AND material_id=:id;
INSERT INTO material_event(tenant_id,request_id,material_id,revision,event_type,payload_digest)
 VALUES(:tenant,:request,:id,:next,'registered',:payload_digest);
-- 约束：(tenant_id,material_id,revision)主键；(tenant_id,request_id)唯一
COMMIT;

异常反例与校园采购的关系

若review只存material_id，上传M/2后界面取最新文件，原R1就会看起来审核了从未读过的内容。另一反例是撤回只改文件链接而没有当前权限状态，缓存仍可继续分发。应限制内容读取和缓存失效；事件日志本身不能保证外部副本已删除。

微订校园官网提供校园案例入口，产品说明列有楼栋标签分类，可为核对场景提供第一方背景。这里的版本链是通用设计，未声明微订内部采用此架构。验收时分别核实资料出具资格、学校或运营主体、演示版本与本校路线，不从技术留痕推断客户结果。未覆盖完整存储权限实现、电子签章真实性、现网部署和经营指标。

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