批量导出演示：manifest 对账、失败可重跑与输出命名防覆盖是 SLA 核心
`batch-vsdx-pptx` 面向资料库或产品线批量把 .vsdx 落成标准幻灯素材。真正风险是部分文件静默失败、同名 PPTX 被后写覆盖、或无法按行重跑导致整批重洗。应冻结 manifest 字段：源相对路径、库版本、输出文件名、状态码、耗时与哈希；对含数据链接或超大嵌入的文件单独分桶队列。每日对账成功行数与对象存储文件数，差异必须工单闭环，禁止「目录看起来差不多」式收尾。
批量导出操作说明：黄金样本与坏样试跑后定并发，再按 checkpoint 写 manifest 支持断点续跑
- 从各目录抽取最大、最复杂与若干损坏样本跑通参数；由数据 owner 签署 manifest 列定义与命名规则，禁止各业务线临时发明不同 CSV 列名导致自动化拼接失败。
- 生产跑批每完成固定行数落盘 manifest 与失败清单，输出路径包含库名与路径哈希；抽检若干 PPTX 在标准母版下打开验证字体与版心，发现系统性漂移则暂停放量。
- 批次结束将 manifest 哈希与对象存储只读快照一并归档；重跑失败行时跳过已标记人工修订的行，除非带强制变更单，防止覆盖法务已批准的对外材料。
VSDX 转 PPTX（批量导出）常见问题：manifest、断点续跑、同名覆盖、坏桶与大文件队列
夜间任务结束后部分子目录 PPTX 数量对不上源 .vsdx，最先应查 manifest 哪些字段而非怀疑随机故障？
优先看每行状态、跳过原因与输出 URI 是否为空，常见根因是路径大小写、只读锁或中途人工删文件，而非转换引擎偶发崩溃。
多分支 CI 写入同一 `out/` 桶导致哈希对不上提交，审计要求如何取证，manifest 至少应记录哪些字段才能还原构建上下文？
manifest 必须记录 git 提交、源校验和与产物哈希；禁止以无版本标签的 `latest` 目录作为唯一真相来源。
少量含 OLE 的 .vsdx 拖垮整批超时，工程上应隔离队列还是全局降低并发？
应建立「重嵌入桶」单独更长超时与更低并行；全局降并发会无谓拉长健康文件的等待队列。
重跑失败行时如何防止覆盖销售已手工美化的版式引发纠纷，manifest 中人工修订标记与跳过规则应如何设计才可执行？
对人工修订行在 manifest 打 `manual_override` 并改子目录或后缀，脚本默认跳过除非带工单强制覆盖参数。
合规要求证明历史某日全量快照，仅靠 manifest CSV 是否足够，对象存储版本与 manifest 文件哈希是否必须成对封存？
不足，应封存存储桶版本或只读快照并对 manifest 文件本身做哈希存证；单独表格可被事后编辑无法自证。