批量迁移与目录治理场景：全量清单对账、失败分型治理、输出命名防冲突且全链路可审计
`batch-vsdx-docx` 面向一次性把库中大量 .vsdx 迁成 Word 以便统一检索或模板化。风险包括同名文件覆盖、嵌入对象拖慢队列、以及部分失败被误报为整批成功。应先拉全量清单含路径与校验和，小批试跑分型失败原因，再放大并发。对 reconciliation 报表必须列出成功哈希、跳过原因与待修复 backlog，否则业务侧无法信任「目录已迁完」的宣称。 建议把重型 OLE 与轻量流程图分池调度，避免相互挤占超时配额。
批量 VSDX 转 DOCX 操作说明：先建路径键清单与试跑分桶，再输出可对账哈希报表
- 导出库内 .vsdx 清单含相对路径、大小、版本标识与业务 owner；按产品线或站点分批并设定单批上限，禁止无清单的「全盘拖入」导致对账不可追溯。
- 首轮试跑统计损坏、加密、超限、渲染超时等错误码，为每类写修复或豁免策略；成功条目立即锁定输出文件名与哈希，手工改名须走变更单。
- 发布批次对账：成功数、跳过数、重试策略与下一窗口；增量同步用源校验和比对自动触发重转，避免 silent stale。
VSDX 转 DOCX（批量迁移）常见问题：同名键、OLE 拖慢、部分成功验收与增量 stale
不同子目录下存在同名 .vsdx 源文件时，是否会导致批量 DOCX 输出互相覆盖？
会，若输出规则忽略路径；必须以完整相对路径或内容哈希作为键，并在报表中高亮冲突项要求业务先改名。
同一迁移批次内部分转换成功、部分仍处于失败或重试状态，怎样向业务消费方严谨宣布阶段性结果？
以批次为单位冻结成功子集哈希并单独列出失败 backlog；禁止对外宣称整库完成而隐瞒缺口。
服务端队列对大型 VSDX 偶发超时，是否应采用不设上限的自动重试策略换取成功率？
应设退避上限并按错误码分型；无限重试会淹没真实根因并浪费算力，应在日志中保留首次失败栈供分析。
批量迁移完成后企业全文检索仍搜不到关键设备编号或机柜位，最可能的技术与流程原因是什么？
可能编号被栅格进图或位于 Alt 文本未写入正文；需回源 Visio 将关键编号同步到可搜索文本层或表格后再转。
主导批量迁移的同事离职或调岗时，接手人最少应拿到哪些材料才能继续安全运维与审计？
应交参数版本、黄金样本、对账脚本、跳过字典与未清 backlog；缺少书面材料则后续审计无法解释历史豁免。