批量迁移场景：manifest 驱动、失败可重放与目录级幂等，避免静默丢文件
`batch-vsd-docx` 面向整库或整目录把遗留 .vsd 迁成 DOCX。真正拖垮项目的是「部分成功却无人知晓」、同名覆盖与无法单条重跑。应先冻结输入清单字段（相对路径、库版本、大小写规则），用 manifest 记录每行状态、耗时、错误码与输出哈希；批次间保留只读快照目录，禁止多人向同一 `out/` 无锁写入。对超大或含 OLE 的文件单独分桶，避免拖死整批 SLA。
批量迁移操作说明：先跑黄金样本与坏样回归，再按桶放量并每日对账 manifest
- 从各业务线各抽若干最复杂 .vsd 与若干已知坏样做试跑，固化服务端参数与并发上限；生成首版 manifest 模板字段并让数据owner签字，避免上线后各写各的 Excel。
- 正式跑批采用分段 checkpoint：每完成 N 行落盘 manifest 与失败清单，支持断点续跑；输出路径必须含库名、相对路径哈希或序号，禁止扁平化后只剩文件名。
- 对账日将 manifest 成功行数与源清单、对象存储对象数三方比对；差异行必须在工单系统登记根因（损坏、加密、超限时策略）后再关闭批次，禁止口头「差不多齐了」。
VSD 转 DOCX（批量迁移）常见问题：manifest、断点续跑、同名覆盖与坏桶隔离
夜间跑批结束后业务发现部分目录 DOCX 数量少于源 .vsd，通常最先该查 manifest 哪几列而不是先怀疑转换引擎？
先核对每行 `status`、跳过原因与输出路径是否为空；常见是路径编码、只读锁或中途被人工删输出，而非随机引擎故障。
同一相对路径在不同分支被覆盖写入共享输出桶，审计上如何证明最终 DOCX 对应哪次提交？
manifest 必须含源文件校验和、git 提交或库版本号与输出哈希；禁止无版本号的「latest」目录作为唯一证据。
少量超大 .vsd 导致整批超时，工程上应拆桶还是全局降并发，各自对 SLA 与成本的影响是什么？
应拆「大文件桶」单独队列与更长超时，主队列保持并发；全局降并发会拉长所有人等待时间且未必解决单文件根因。
重跑失败行时如何避免把已人工修补的 DOCX 再次覆盖引发二次纠纷？
对人工修补行在 manifest 标记 `manual_override` 并改输出后缀或子目录；重跑脚本默认跳过该标记除非带强制工单。
合规要求证明「某历史日期的整库快照」，仅靠当日 manifest 是否足够？
不够，应同时封存对象存储版本或只读桶快照与 manifest 文件本身哈希；单独 CSV 可被事后编辑，需成对存证。