01 / CONTEXT
跑一半断了，然后呢
这条链路要跨七个阶段：取图、校验、生成、审核、上传、登记、通知。中间任何一步都可能断 —— 网盘超时、工作流排队、Excel 被人占用、机器重启。真正的问题出现在断掉之后：直接重跑会不会把已经完成的目录删掉，会不会给业务群把同一条通知再发一遍。
而且它操作的是共享盘，多人可见，删除不可逆。所以这个项目的目标不是「跑通」，是让它在任何时刻被打断，都能安全地从断点继续。
02 / MY ROLE
我的工作：让每一步都可以放心重跑
状态设计
用带文件指纹的 manifest 记录每个阶段做到哪，原子写入，续跑时据此判断而不是靠目录是否存在。
破坏性操作兜底
凡是删除、覆盖、替换，先验证前置阶段真的完成；内容不一致时阻断，绝不覆盖。
副作用去重
通知这类不可撤销的外部动作单独记状态，成功后回传 ID 确认，续跑不重复触发。
公共能力收敛
把网盘认证、限流、重试收进一个公共模块，给 Token 与重试都设明确上限。
03 / PROCESS
七个阶段，任一失败即阻断后续
- 01
取图与校验
先生成待取清单，再按清单取图包，两者必须完全一致。源图包全程只读，不在原地做任何修改。
- 02
指纹入库
副本先落暂存区，逐文件算 SHA-256 指纹并记进 manifest，状态齐全之后才允许登记数据库。
- 03
生成与审核
调用工作流批量出图，产出进入待审目录；需要重做的走重生链路，复用同一套执行核心与需求表口径。
- 04
删除前置校验
要删除已完成的搭配款目录时，先回头确认上一阶段的 manifest 全部完成 —— 不确认就不删。
- 05
上传与登记
网盘认证、限流与重试收在同一个公共模块里，Token 和网络重试都有明确上限，不做无限重试。
- 06
通知去重
通知成功后把返回的通知 ID 回传登记。续跑时据此判断这条是否已经发过，避免重复打扰业务群。
- 07
月表安全更新
汇总工作簿走下载校验 → 暂存上传 → 并发复核 → 备份替换 → 再下载校验；任一步失败就恢复旧月表。
批处理最怕的不是失败，而是失败后不知道跑到哪了、重跑会不会删掉已完成的。
04 / SCALE
链路规模
- 串行阶段
- 7
- 行 Python
- 23,247
- 全程文件校验
- SHA-256
数据源：仓库内该子项目的代码统计与流程说明文档。本页描述链路结构与规模，不列业务运营数据。
05 / REVIEW
幂等不是写完再补的，是设计时就得定
已经解决
任意阶段中断后可以直接重跑，不会重复发通知、不会删掉未确认完成的目录、不会覆盖内容不一致的汇总表。
代价
为此多出了一整层状态记录与前置校验，代码量和调试成本都比「直接跑」高出不少。
下一步
把这套 manifest 与续跑机制抽成可复用组件 —— 仓库里其他链路仍在各写各的。