Mermaid 图表转 Word 后太小或被裁切？节点、方向与页面布局优化指南
Mermaid 图表在 Markdown 预览中显示正常，转换到 Word 后却可能变得特别小、过高、模糊，甚至只显示一部分。原因可能是节点太多、标签过长，或者布局方向让图表宽度远远超出竖版页面。
这通常不是图片缺失，而是页面布局问题。Mermaid 首先要成功生成图表，然后生成结果还必须在 Word 的可打印区域内保持可读。
快速处理思路减少单张图中的节点数量，缩短节点文字，选择更适合页面的方向，把大型流程拆成概览图和细节图，减少无意义的子图嵌套，并在最终 DOCX 的正常缩放比例下检查，而不是只看 Markdown 预览。
图表语法正确，不代表它的结构一定适合 Word 页面。为什么 Mermaid 图表在 Word 中难以阅读
Markdown 预览可以使用大部分浏览器窗口，而 Word 文档具有固定页面尺寸、页边距和有限的可打印宽度。大型图表为了完整放进页面，会连同文字和箭头一起缩小。
- 同一横向流程中包含过多节点
- 节点标签使用完整长句
- 子图层级嵌套过多
- 长流程使用从左到右布局
- 很深的层级使用从上到下布局
- 一张图同时表达概览、细节、异常和责任分工
选择适合页面的布局方向
| 方向 | 适合场景 | Word 风险 |
|---|---|---|
flowchart TD |
短流程、决策树、层级结构 | 可能过高 |
flowchart LR |
紧凑流水线和短序列 | 可能过宽 |
flowchart TB |
自上而下的过程说明 | 需要检查页面高度 |
八到十个阶段的流程通常更适合从上到下排列；只有三四个阶段的紧凑流程则可以从左到右。
先缩短节点文字，不要先缩小字体
flowchart LR A[收集来自邮件和聊天的全部客户请求] B[审核请求并识别负责处理的部门] C[把请求发送给指定员工进行处理] A --> B --> C
flowchart LR A[收集请求] B[分类] C[分配负责人] A --> B --> C
读者应该先快速浏览图表，再从正文获取细节。图表不需要重复报告中的每一句话。
把复杂图拆成概览与细节
很多图表变得不可读，是因为一张图同时回答了过多问题。可以把主要阶段、内部细节、异常路径和责任分工拆成不同图表。
拆分复杂图表通常能够同时改善页面适配和理解效率。减少子图嵌套
子图适合分组，但多层嵌套会增加边框、内边距和空白。只有在分组确实能够表达责任边界、部署边界或流程范围时，才保留视觉容器。
放得下和看得清是两个标准一张图即使没有超出页边距，但必须放大到 200% 才能阅读，也不适合普通 Word 阅读或打印。
区分渲染错误与布局错误
| 现象 | 问题类型 |
|---|---|
| 完全没有生成图表 | 语法或渲染问题 |
| 只出现图表的一部分 | 渲染边界或不支持内容 |
| 图表完整但特别小 | 布局过宽或过高 |
| 打印后文字难以阅读 | 过度缩放或结构过于复杂 |
实用的 Mermaid 整理流程
- 单独渲染图表。先确认 Mermaid 语法有效。
- 统计节点和分支。判断是否表达过多内容。
- 检查布局方向。根据页面选择纵向或横向。
- 缩短标签。把解释性长句移到正文。
- 压平无意义子图。
- 拆分概览和细节。
- 转换最小 DOCX 测试。
- 在正常缩放与打印预览中检查。
先验证语法，再简化结构并测试真实 Word 页面。检查最终 DOCX
- 确认每个 Mermaid 代码块都生成了图表。
- 检查节点、标签和箭头是否被裁切。
- 在 100% 缩放比例下阅读图表。
- 使用打印预览检查页面。
- 确认题注准确解释图表用途。
- 确认概览图和细节图使用一致术语。
- 检查分页和分节符附近的图表位置。
- 条件允许时，在收件人的 Word 或 WPS 中打开。
常见问题
为什么 Mermaid 图表在 Word 中特别小？
生成后的图表可能远宽于或高于可打印区域，因此 Word 为了完整放入页面而整体缩小。
流程图应该从左到右还是从上到下？
应同时考虑流程关系和页面空间。长序列通常更适合在竖版页面中从上到下排列。
可以直接增大 Mermaid 字体吗？
可以尝试，但字体变大也会让节点和整张图变大。简化结构通常更可靠。
什么时候应该拆分 Mermaid 图表？
当一张图同时包含概览、实现细节、异常和责任分工，或者正常字号无法放进页面时，就应该拆分。
最终检查清单
- Mermaid 语法能够成功渲染。
- 布局方向适合页面和流程。
- 节点标签保持简短。
- 子图只用于有意义的分组。
- 大型流程已拆成概览和细节。
- 图表在 100% 缩放比例下可读。
- 没有内容被裁切或遗漏。
- 最终 DOCX 已使用打印预览检查。
