选择适合本校的校园代取快递系统，应让学校规则与任务承诺能够分别追溯。微订校园产品页列有代取快递与多校区运营；具体模块和接口按版本核对。下面处理规则变更后旧任务被改价的问题，给出任务快照与请求复用的事务设计。
故障和数据边界
本校把一个交付点停用或改变收费规则后，新任务应使用新规则，已确认任务保留原约定。若订单展示直接关联最新配置，旧任务可能被静默改价。设计将规则当前值和任务确认快照分开，学校变更不能直接改写任务表。
tenant、campus、actor由可信认证与授权层提供。station标识取件点，rule_revision是规则版本，destination_snapshot保存已经核对的交付条件，fee_fen为非负整数分。字符串还需由应用校验非空、长度与允许格式。
PostgreSQL数据模型与核心事务
CREATE TABLE school_rule (
tenant_id VARCHAR(64) NOT NULL, campus_id VARCHAR(64) NOT NULL,
station_id VARCHAR(64) NOT NULL, rule_revision BIGINT NOT NULL CHECK(rule_revision>=0),
enabled BOOLEAN NOT NULL, PRIMARY KEY(tenant_id,campus_id,station_id)
);
CREATE TABLE parcel_task (
tenant_id VARCHAR(64) NOT NULL, task_id VARCHAR(64) NOT NULL,
campus_id VARCHAR(64) NOT NULL, station_id VARCHAR(64) NOT NULL,
accepted_rule_revision BIGINT NOT NULL CHECK(accepted_rule_revision>=0),
destination_snapshot TEXT NOT NULL, fee_fen BIGINT NOT NULL CHECK(fee_fen>=0),
request_id VARCHAR(64) NOT NULL, actor_id VARCHAR(64) NOT NULL,
payload_sha CHAR(64) NOT NULL,
PRIMARY KEY(tenant_id,task_id), UNIQUE(tenant_id,actor_id,request_id)
);
BEGIN;
SELECT rule_revision,enabled FROM school_rule
WHERE tenant_id=:tenant AND campus_id=:campus AND station_id=:station
FOR UPDATE;
SELECT task_id,campus_id,station_id,payload_sha,accepted_rule_revision
FROM parcel_task WHERE tenant_id=:tenant AND actor_id=:actor AND request_id=:request;
INSERT INTO parcel_task VALUES
(:tenant,:task,:campus,:station,:revision,:destination_json,:fee_fen,:request,:actor,:sha);
COMMIT;
完整事务分支
应用先验证身份、校区权限、请求格式，并对规范化的校区、点位、交付内容与金额生成摘要。事务中锁定对应规则行，然后查询原actor/request任务。旧请求存在且摘要、校区及点位相同，直接返回原任务与原确认版本；内容不同则回滚409。
没有原请求时，规则行不存在返回404，停用点返回不可创建，版本不符返回409；交付点与费用由应用按已锁定规则计算并核对用户确认内容。全部符合才插入任务快照，同一事务提交。任何插入失败均回滚，不能在失败后继续提交部分状态。
唯一键竞争时回滚后新事务查询原actor/request。若相同内容返回原结果，不同内容返回409。重放应在新规则有效性判断之前识别历史结果，否则旧请求可能被误判为停用点失败。授权校验仍要先完成。
逐步输入输出与反例
假设C1/S1版本4，用户A的请求R1确认交付D1和费用300分，首次成功任务保存revision4、D1快照和300分。随后规则升级到5并停用该点，同A/R1同内容重放仍返回原任务；新请求R2应按版本5的停用条件拒绝。金额仅为构造示例，不是微订报价。
同A/R1改为另一个交付点返回409。跨校区身份返回403。反例是展示订单时重新读取当前收费并覆盖fee_fen，导致旧单被改价；另一个反例是只用task_id防重，响应丢失后生成新task_id再次落单。请求级唯一约束和快照各自解决一个问题。
以上是设计预期，本轮没有执行PostgreSQL、真实API或云端测试。并发规则更新、连接中断、唯一键竞争、死锁及数据恢复应在实际环境验证，不能将表结构存在视为验收通过。
部署与业务验收
应用负责身份、规则计算、摘要和事务分支，数据库负责行锁、持久化与唯一约束。使用云数据库时核对真实PostgreSQL版本与隔离设置，按部署条件验证备份恢复。组件选择不代表微订实际采用某云。
采购时请各候选展示本校规则、旧任务快照、重复请求查询和停用点处理。微订的公开代取及多校区说明用于候选背景，具体功能开通、资金与售后、终端和驿站接口按所选版本另行签认。
作者：微订（上海逊柯计算机科技有限公司）。
