把 103–112 十个迁移收敛为五个,删除在「生产 102 → 当前」路径上的空操作与补丁: - 108(下线人工支出登记)与 109(隔离历史快照主体)在生产库和重建库上都是空操作, 口径注释并入 104; - 111 是给 104 自身种子打的补丁,合并后 104 直接写入 active 0 元占位; - 112 的 cost_exceptions.resolution_note 并入 104,退款表独立为 106; - 106(备用金编号可读化)与 110(积分钱包)合并为 107(人工履约资金层); - 107(履约方式列)并入 105,履约方式本就是销售事实的维度键。 配套调整: - check-sql-guard 改为以 main 为基线校验迁移字节,删除 103–114 的永久豁免; 未合并分支上的新迁移仍可重写,已发布迁移不可修改。 - 本地库原地改造脚本移入 docs/archive,禁止对新环境执行。 验证:清掉 schema_migrations 里 103–112 的记录后重跑,升级结果与全新构建的 schema 完全一致(pg_dump --schema-only 仅随机 token 不同),种子数据一致; 升级前后业务数据量不变(成本版本 713 → 712,差异来自删除占位草稿)。
历史文档归档
这里的文档只用于追溯当时的分析过程,不是现行实现说明。 代码、数据库结构与线上行为以仓库当前
main和docs/README.md中标记为「现行」的文档为准。
2026-10-08
| 文档 | 归档原因 |
|---|---|
项目分析报告-发单系统与寄售仓库.md |
基线为 ef491660,测试数、迁移数、表数与当前实现已明显不一致;由《项目全量分析报告-2026-10-17》替代 |
寄卖子系统技术分析报告.md |
同上,且部分行号已漂移;寄卖代码仍可参考,但结论需按现行代码复核 |
寄卖系统优化方案.md |
阶段性优化方案,部分事项已完成,不能作为现行路线图 |
寄卖库存优化现状与进度追踪.md |
阶段性进度追踪,完成状态已过时 |
近期性能与稳定性专项优化分析报告.md |
2026-10-01 / 10-02 的生产快照与专项复盘,保留作性能证据,不代表当前容量 |
寄卖系统迁移079上库前检查.sql |
迁移 079 的一次性上库前检查脚本,生产已执行;保留作审计追溯 |
2026-10-17
| 文档 | 归档原因 |
|---|---|
2026-10-17/载体判定与成本中心落地-复核与草案.md |
2026-10-17 第二轮复核与数据量化;现行结论已吸收进 成本中心与三块履约模型.md 与 财务系统集成方案.md,仅保留作数据与 DDL 验证追溯 |
2026-10-23
| 文档 | 归档原因 |
|---|---|
2026-10-23/2026-10-23-本地库原地改造.sql |
逐列把 carrier_type / cost_type 改成 cost_model / fulfillment_mode 的一次性脚本;迁移收敛为 103–107 后不再成立,禁止在新环境执行,仅作改造矩阵追溯 |
使用建议
- 需要当前架构与风险:看
docs/项目全量分析报告-2026-10-17.md(参考)和docs/README.md(状态索引)。 - 需要财务系统设计:看
docs/财务系统集成方案.md;实施顺序以docs/README.md§三 为准。 - 需要某个平台协议:看对应的厂商文档目录(
91卡券/、行业电子凭证/、发货平台-2/、抖音-码速达/接口API/、抖音-码速达/消息推送/)。 - 历史文档中的代码行号、测试数量、迁移数量不要直接引用。