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