Word转Markdown保留图片与格式：Pandoc实战指南

1. Word 转 Markdown 的难点格式迁移的本质是保留“文档骨架”做内容迁移的朋友应该都有感触Word 文档躺在本地盘里时没什么存在感一旦你想把它挪进博客、知识库、Wiki 或者 Git 仓库问题就来了——Markdown 是纯文本标记语言Word 是富文本排版工具两者之间不存在“无损复制粘贴”这条路。我接手过一批产品手册的迁移几十份 docx里面布满技术截图、表格和公式。当时我试过最原始的办法打开 Word全选复制粘贴到 Markdown 编辑器。结果图片全部变成了一堆data:image/png;base64或者直接丢失表格排版散架公式变成乱码。这种状态别说发布自己看着都想砸键盘。所以“Word 转 Markdown”这件事核心痛点从来不是“怎么把文字弄出来”而是三个关键问题图片能不能完整保存下来并正确引用、标题和列表的层次结构能不能保留、公式表格这类特殊元素能不能继续被人看懂。这三个问题就是我接下来要展开的全部内容。1.1 docx 到底是什么一个装着图片和 XML 的压缩包很多人不知道docx 本质上是一个 ZIP 压缩包。你把后缀改成.zip解压开就能看到一堆文件夹word/document.xml是正文内容word/media/目录下存放着所有嵌入图片word/styles.xml是样式定义word/numbering.xml是编号规则。这解释了一件很重要的事Word 转 Markdown 的过程本质上不是“翻译排版”而是“解析 XML 结构重构 Markdown 语法树”。图片也不是“导出”出来的而是从压缩包里“提取”出来的。我当时意识到这个原理后对整个转换流程的信心立刻就不一样了——因为我知道图片一定在某个地方等着我问题的关键只是怎么把它提取出来并建立正确的引用关系。1.2 为什么直接复制粘贴总是翻车复制粘贴走的是剪贴板剪贴板只保留两类东西文本和富文本 HTML。Word 会把内容转成一段极其臃肿的 HTML 塞给编辑器Markdown 编辑器一般会把它转成原生 Markdown 或者保留 HTML 片段。问题出在图片上。剪贴板里的图片如果不经过特殊处理要么被转成 base64 内嵌字符串要么干脆丢弃。你贴在 Typora 里看到的图片换一个平台或者换个编辑器可能就完全加载不出来。更别提表格的边框、合并单元格、公式的 OMML 结构在剪贴板里早就支离破碎了。所以如果只是偶尔转一篇简单文档复制粘贴还能凑合一旦涉及批量、涉及图片、涉及公式就必须换成真正的文档转换工具让程序去解析 docx 的文件结构而不是依赖剪贴板。1.3 你不只是在转格式而是在重新组织文档结构我后来总结了一个观点Word 转 Markdown 的核心不是“保留 Word 格式”而是“保留文档骨架”。所谓骨架就是标题层级、段落结构、列表嵌套、表格行列、图片引用、链接、脚注这些语义化元素。为什么这么说因为 Markdown 本来就不可能做到像素级还原 Word。它有它自己的排版哲学用#表示层级用-表示列表用|表示表格。你在 Word 里调过的行距、缩进、段前段后间距转到 Markdown 里一概不存在也不需要存在。真正需要保留的是那些“就算换一种排版方式也不能丢”的信息结构。把这个想通了你在转换时就不容易钻牛角尖——某条下划线丢失了不重要但某个三级标题变成了正文这就很要命。2. 转换前的文档体检样式、图片嵌入和公式必须提前修复转换工具再强大也扛不住源文件本身风控。我见过太多人跳过这一步结果转出来的 Markdown 惨不忍睹还以为工具不行。实际上大部分问题出在 Word 文档的质量上。转换前花十分钟体检能省下来两小时的清理时间。2.1 检查标题是否用了“样式”而不是手动调大字号这是最容易被忽略、又影响最大的一点。Pandoc 这类工具识别标题靠的是 Word 样式中的“标题 1”“标题 2”等内置样式而不是看字号大小。如果原文是用“选中文字把字号改成 20 磅加粗”这种方式模拟标题那么在转换工具眼里它就是一个普通段落会被转换成纯文本标题层级全没了。体检方法很简单在 Word 里打开“开始”工具栏看文档左侧是否有对应的标题样式块。如果发现文章里的“标题”都是手调格式那么最省事的修复方式是选中文字直接点击“标题 1”“标题 2”样式哪怕字号暂时不理想也别管Markdown 输出后用 CSS 或主题去控制实际展示效果。2.2 图片嵌入、浮动和缺失引用的排查在 Word 里图片有两种存在方式嵌入型inline和浮动型floating。嵌入型图片跟文字在同一个段落流里转换工具容易定位浮动型图片比如设置了文字环绕有时候会被当作 drawing canvas 处理转换后位置会漂移甚至会脱离上下文。还有一个常见隐患是图片不可见。有人习惯用“显示标记”功能但 Word 文档里可能出现这样一种情况图片被设置成了“嵌入”到文本框或形状里表面看是一张图实际是一个 OLE 对象或浮动画布。这种图用 Pandoc 严格意义上也能提出来但引用位置往往对不上。转换前建议快速翻一遍文档把重要的图都检查一遍是否正常显示。如果发现某张图显示为空白框或者灰色占位多半是嵌入方式有问题需要先在 Word 里重新插入一次。这个步骤很繁琐但确实能避免转换完发现关键截图缺失的尴尬。2.3 公式的三种存在形式OMML 公式、MathType 对象和图片公式做技术文档的人对数学公式肯定不陌生。Word 里的公式有三种“前世今生”原生公式用 Word 的“插入→公式”创建的 OMML 结构这是转换工具最喜欢的形式可完整转成 LaTeX。MathType 公式如果是老文档公式可能是 MathType 对象本质是 OLE 嵌入Pandoc 识别不了会被当成嵌入对象处理输出基本等于丢失。图片公式从 PDF 或网页里截图粘贴进来的公式本质就是一张图片转出来的就是没有任何可编辑性。体检时看文档里公式是否能直接用鼠标光标选中并编辑。MathType 公式通常会在双击时弹出 MathType 编辑器。如果遇到大量 MathType 公式最靠谱的补救方案是在 Word 里逐个双击进入 MathType然后用其自带的转换功能把公式转成 Word 原生公式OMML再执行转换。这个环节虽然费时但对那些公式含量极高的文档这是唯一能保住“可编辑公式”的路。2.4 清理空行、手动编号与表格的合并单元格Word 文档里最常见的坏习惯是用回车键打出一堆空行来表示段落间距。转换后这些空行会变成 Markdown 里的多余空行虽然不致命但读起来非常松散。用查找替换把^p^p连续两个段落标记换成^p可以快速清理。另一个坑是手动编号。很多人不用 Word 的自动编号列表而是手动输入“1、2、3、”。这种列表在转换后不会被识别成 Markdown 的有序列表而是变成普通段落“1、 内容”。遇到这种情况要么在原文里改成自动编号列表要么接受转换后手动给 Markdown 加1.前缀没有别的捷径。表格的合并单元格也值得提前观察。Pandoc 对合并单元格的支持是有限度的跨行合并rowspan有时会被拆开或者变成空单元格跨列合并稍微好一些但输出为 Markdown 的 pipe table 时列数可能对不齐。我的建议是如果表格结构特别复杂比如多层表头、多重合并在 Word 里尽量简化或者在转换后改用 HTML 表格区块嵌进 Markdown 里。3. 工具选型对比Pandoc 为什么是保留图片和格式的最佳选择在正式动手前先把工具选明白。市面上能处理 Word 转 Markdown 的工具不少但定位差异很大选错了容易白折腾。工具优点缺点适合场景Pandoc开源免费、跨平台、支持 word/media 图片提取、公式能转 LaTeX命令行初学者略有门槛批量转换、复杂文档、需要稳定输出的场景mammoth专门面向 docx 解析输出的 Markdown 干净无垃圾标签公式支持弱、复杂表格容易丢细节纯文本为主的文档追求“干净”Typora 粘贴所见即所得简单快捷图片会转成 base64 或需要手动设置批量能力差临时转换、单篇短文在线转换网站不用安装操作简单隐私风险高、图片路径不可控、转换质量参差不齐不涉密、不追求细节的应急场景python-docx 定制脚本可完全控制逻辑需要编程工作量较大有特殊格式需求且愿意投入开发成本3.1 Pandoc一个命令解决 90% 的问题Pandoc 是文档转换界的瑞士军刀。它支持 docx 转 Markdown并且默认就能把嵌入图片提取到指定目录把 Word 内置标题映射成对应层级的 ATX 标题把有序列表、无序列表、表格、链接、脚注都转换成标准 Markdown 语法。更关键的是它的转换逻辑基于 Pandoc AST抽象语法树这意味着你不只是在“粘规则”而是在“映射语义”。Word 里标记为“标题 1”的文本一定会变成#绝不会因为字号变化而判断失误。在公式方面Pandoc 默认会把 Word 原生 OMML 公式转换成 LaTeX 数学语法行内公式用$...$块公式用$$...$$。这一步对我来说是决定性的——我做技术迁移时最怕公式变成图片而 Pandoc 恰恰能保住公式的可编辑性。3.2 mammoth追求干净的另类方案mammoth 是一个专门解析 Word 文档的库它也有命令行工具目标很纯粹把 docx 转成干净的 HTML 或 Markdown。它的理念是“关注语义忽略排版”所以输出里很少出现垃圾标记标题、段落、列表这些基础结构处理得很干净。但 mammoth 有两个明显短板一是公式支持不完整二是表格处理能力有限。我实测过带公式的工程文档mammoth 对 OMML 基本无解输出出来公式就是原始 XML 或者干脆消失。相比之下Pandoc 的处理要成熟得多。所以我的判断是mammoth 适合“文章型”文档不适合“手册型”文档适合做在线预览的轻量转换不适合做需要长期维护的知识库迁移。3.3 在线转换与 Typora 粘贴适合应急但不适合批量在线转换网站的痛点很明显你永远不知道它把你文件传到哪个服务器了图片提取的逻辑也不透明包下载下来经常是一堆哈希命名的图片路径对不上。Typora 的粘贴功能虽然方便但它在“复制粘贴”场景下不容易保留原始图片文件更多的是把图片放到本地相对路径最终发布时还得重新配置。这两个方案不是不能用而是不适合当作主力。诚实的建议是应急用一次可以批量迁移就算了别给自己留后患。3.4 我的工具组合策略当我真正处理那批产品手册时采用的组合是Pandoc 为主力转换python-docx 做前置体检和自定义修复最后人工过一遍渲染结果。这样既拿到了标准的 Markdown 结构又能针对特殊情况写脚本来兜底。接下来要讲的实操过程基本都是围绕这套组合展开的。4. Pandoc 实操从 docx 到 markdown 的完整命令与图片路径处理在折腾过各种工具之后我可以负责任地说Pandoc 是当前把“保留图片”和“保留格式”做得最平衡的方案。下面是从零开始的完整操作。4.1 安装 Pandoc 和基本命令安装 Pandoc 很简单。Windows 上可以用 wingetwinget install --id JohnMacFarlane.PandocmacOS 上可以用 Homebrewbrew install pandocLinux 上Ubuntu 系直接用 aptsudo apt-get install pandoc装好之后在命令行里进到 docx 所在的目录执行这条最基本的转换命令pandoc 示例文档.docx -t markdown --extract-media./assets -o 示例文档.md说下参数含义-t markdown指定输出格式为 Markdown。如果不指定Pandoc 会默认输出 HTML。--extract-media./assets关键参数。它会把 docx 内嵌的所有图片提取到./assets/media/目录并把 Markdown 中的图片引用路径改成相对路径。-o 示例文档.md指定输出文件名。转换完成后打开 Markdown 文件你会看到类似这样的引用这是一段文字下面是一张架构图 图片确实被提取出来了毫发无损。这个方案比任何“复制粘贴再转存”都靠谱。4.2 --extract-media 参数图片是如何被提取和引用的如果你好奇图片为什么能这么“乖”我解释一下内部的逻辑docx 是 ZIP 包里面所有图片都集中在word/media/目录。Pandoc 在解析 document.xml 时一旦发现图片引用关系就会把对应文件从压缩包里抽取出来按顺序命名——通常就是image1.png、image2.png这样的编号。然后把 document.xml 里的r:embed引用替换成 Markdown 图片语法。这里有一个需要注意的地方图片的编号顺序不是按你在 Word 里看到的顺序来的而是按文档内部的引用 ID 排序。比如文档里先插入了图三再插入图一提取出来的名字可能是image1、image2但具体哪张是哪张只能通过图片内容去对应。所以如果对图片文件名有强制要求比如博客平台要求命名成architecture-overview最好转换后再做一次批量重命名。另外一个不知道算不算技巧的经验--extract-media跟-sstandalone没有强绑定关系但如果想要一个带完整元数据的 Markdown比如带有 Frontmatter建议加-s。这个参数会让 Pandoc 把标题、作者、日期等信息写入 YAML 元数据块后面接到博客系统时很省事。4.3 表格类型选择pipe table 还是 grid tablePandoc 的 Markdown 输出里表格有两种主要形态pipe table 和 grid table。pipe table 就是我们最常见的| 列1 | 列2 |这种紧凑写法兼容性好GitHub 和大多数 Markdown 编辑器都支持。grid table 是 Pandoc 自定义的“网格表格”用---画边框能表达更复杂的单元格结构但兼容性差很多换到别的平台可能渲染异常。实际上Pandoc 在默认-t markdown时会根据表格的复杂度自动选择表格类型。遇到带合并单元格或者多行表头的它可能会选择输出 grid table而标准行列表格则输出 pipe table。如果你的目标是 GitHub、知乎或者公司 Wiki多半希望强制使用 pipe table。有两个方式加-t gfmGitHub 风格 Markdown 会强制输出 pipe table。加-t markdown-pipe_tables可以让 Pandoc 尽量输出 pipe 表格但复杂表格它依然只能退回到网格表格。我的实际建议是分两步走。第一步用默认-t markdown转换看看主要表格都是什么形态如果绝大多数表格可以用 pipe table 表达那就把目标定为 pipe table无法表达的部分单独在 HTML 区块里兜底。4.4 用 gfm 还是 markdown 格式目标平台决定参数这个选项看起来很细但影响很大。-t gfm生成 GitHub 风格的 Markdown。它强制 pipe table对任务列表复选框、删除线、自动链接等有更明确的输出。缺点是某些 Pandoc 扩展比如 raw HTML 内嵌在 gfm 里会被限制适合以 GitHub/GitLab 为主要托管平台的场景。-t markdown生成 Pandoc 最完整的 Markdown 方言。它能输出更丰富的结构比如脚注、definition list 等也允许内嵌 HTML。缺点是有些语法在目标平台尤其是知乎这种对 Markdown 支持残缺的平台上可能不生效。如果目标平台是备案良好的 Wiki 或者静态博客我偏爱-t markdown因为它保留了更多信息。如果文档要进 GitHub那直接-t gfm更干净省去后续手动调整表格的麻烦。5. 难处理的特殊情况公式转 LaTeX、复杂表格、批注与页眉页脚基础结构转换顺利之后真正的硬骨头才露出水面。公式、复杂表格、批注、页眉页脚每一个都够你折腾一阵。5.1 Word 公式转 LaTeX 的默认行为与 MathType 遗留问题Pandoc 会把 Word 原生公式转成 LaTeX 数学语法。行内公式形如根据牛顿第二定律 $Fma$可以推导出动量变化量。块公式形如$$ \int_0^t F(\tau) \, d\tau mv_t - mv_0 $$这个转换是基于 OMML→TeX 的映射大部分标准数学结构都可以正确转换包括分数、积分、矩阵、上下标。我测试过包含求和符号、极限、分段函数的工程公式基本都能还原。但如果你是老文档公式是用 MathType 输入的情况就不妙了。MathType 公式在 docx 中是一个 OLE 对象Pandoc 默认把它当作嵌入对象输出的结果可能是这样的也就是说公式变成了一张普通图片。更麻烦的是MathType 对象在部分解压流程中可能不会出现在word/media/里而是被封装在word/embeddings/下除非安装专门的 OLE 处理工具否则普通提取根本拿不到。处理方法我在前面体检那节已经提过在 Word 里打开文档用 MathType 的“Convert Equations”功能把整个文档公式统一转换成 Word 原生 OMML然后再交给 Pandoc。如果文档量很大别嫌麻烦这一步是保住公式可编辑性的唯一现实路径。5.2 复杂表格合并单元格转换后容易漏行漏列Pandoc 对表格的处理比复制粘贴强得多但复杂表格依然是转化质量的重灾区。多层表头、跨行合并、跨列合并、单元格内嵌列表这些结构在 pipe table 里绝大多数无法表达。实测下来Pandoc 在处理带rowspan的表格时会把空白合并单元格输出为一个空单元格看起来格式还在但渲染出来就是缺了一格。如果原文的合并关系比较复杂最终 Markdown 表格的列数会错乱导致内容对不上行。针对这种情况我有三条实用建议如果目标平台支持 HTML 表格转换后手工把那些复杂表格重写成 HTMLtable区块直接塞进 Markdown 文件中。Markdown 本身支持内嵌 HTML这是最稳妥的兜底方案。如果目标是纯 Markdown 渲染环境那只能在 Word 里重建简化表格结构把跨行合并尽量改成跨列合并或者干脆拆分成多个小表。如果表格里还有第二层内容比如单元格里嵌了列表或图片一次转换很难完美我一般会写一个 python-docx 脚本读取每个单元格的完整内容再生成对应的 Markdown 表格字符串。5.3 批注、页眉页脚和目录哪些内容注定要舍弃或重做这里说一个可能会让你失望的事实Pandoc 默认不会保留 Word 批注。批注在 document.xml 里是独立的 comment 节点Pandoc 的 docx reader 虽然能识别但默认不输出到 Markdown。如果批注的内容对你有价值唯一的办法是先用 Word 导出批注文本再单独处理。页眉页脚则完全不在转换范围之内。这倒不是 Pandoc 偷懒而是 Markdown 的文档模型里根本没有“页眉页脚”的概念。你把这些信息放进标题主体里也怪怪的。我的建议是把页眉中的文档标题、版本号、页码之类的内容迁移到 Markdown 的元数据区Frontmatter或正文开头的说明文字里。目录这东西Word 里的域代码生成的目录转换前后变成普通列表或直接被忽略。正确做法是转换完用 Markdown 编辑器的目录功能自动生成或者交给渲染框架比如 VuePress、Docsify自动提取标题生成侧边栏。千万别把 Word 目录硬迁移过来那样排版会非常丑。5.4 脚注与尾注Pandoc 处理得很好的部分好消息是脚注这块 Pandoc 是加分项。Word 的原生脚注会被转成 Markdown 脚注语法这里有一段引用[^1]。 [^1]: 这里是脚注内容。脚注的顺序、编号、正文引用位置都能正确保留。这个特性在做学术类、说明类文档迁移时非常有用会让最终文档的严谨性好很多。尾注的处理逻辑类似只是编号位置可能不同转换后建议人工检查一遍对应关系。6. 转换后的清理工程让 Markdown 从“能看”变成“能用”Pandoc 出品的 Markdown 结构很规整但离“能直接发布”还有距离。清理工作是整个流程里最费时间的一步但也是决定成品质量的一步。6.1 图片路径规范化统一到一个 assets 目录转换完的 Markdown 里图片引用可能是assets/media/image1.png。这个路径在本地能打开但一旦你要发布到博客或托管平台最好把图片统一整理到assets/img/或images/这样更常规的目录下。我常用的做法是两步先移动文件再全局替换路径。移动可以用命令行mkdir -p assets/img mv assets/media/* assets/img/替换路径时如果你用的是 VS Code直接全局搜索assets/media/替换成assets/img/非常快。如果图片特别多也可以写一个 Python 脚本统一处理顺便把文件名替换成语义化的名字。还需要留意如果目标平台会自动给图片做 CDN 加速比如 GitHub 仓库的图片会走 jsDelivr那么路径不要写死绝对路径全部用相对路径后面接入 CDN 时会更灵活。6.2 修复嵌套列表和多余的硬换行这是 Pandoc 一个比较容易出问题的地方。Word 列表有时候会出现“同一列表项里塞了多个段落”的情况转换后就会变成松散列表loose list也就是列表项之间多出空行。空行在 Markdown 里会导致列表渲染中断看起来像是一个新列表。处理方式是全局搜索“列表项之间的空行”把它们删掉。但你无法手动删几百处所以我建议用一个小正则perl -0pi -e s/(\n- )\n/\1/g 示例文档.md如果对正则不熟用 VS Code 的“查找替换”加正则模式也行。替换完后用 Typora 或 VS Code 预览基本就能看出列表是否连贯了。6.3 核对标题层级H1 到 H4 之间的跳跃问题很多 Word 文档在标题层级上是“野路子”的正文里一会儿用标题 3一会儿用标题 1中间还穿插着一些手写强调。Pandoc 会老老实实按样式名映射但最终层级可能不符合 Markdown 发布规范比如直接从##跳到了#####。清理时重点检查两件事是否只有一个#作为文章主标题。如果多个#说明文档顶层结构不清晰。标题层级是否连续。如果出现## 二级标题后面直接跟#### 四级标题中间缺了三级建议调整一下层级或者压缩中间结构。这一步基本靠人工核对。我在处理几十份手册时就是打开终稿的目录树一个个过标题层级花的时间不少但最终发布效果非常整齐。6.4 为博客/文档站生成 Frontmatter 和目录如果你的 Markdown 要发布到静态博客或文档站那么需要在文件顶部补上 Frontmatter。Pandoc 的-s参数能带出一些基础元数据但一般不够用。我会手动补全类似这样的内容--- title: Word转Markdown(保留其中插入的图片以及Word格式) date: 2025-01-15 tags: [Word, Markdown, 文档迁移] ---如果文档很长还可以让渲染框架自动生成目录。GitHub 会自动识别标题生成锚点目录Typora 里也可以打开“侧边栏大纲”。这一步基本不用在 Markdown 文件里做额外加工交给工具就行。7. 批量转换与自动化几十个 docx 一次搞定的实操脚本一旦手头有大量 Word 文档你会发现手动一个文件一个文件转换根本不现实。这个时候批量脚本是唯一的出路。7.1 Bash 脚本一键循环转换并提取媒体文件在 Linux 或 macOS 环境中一个简单的 bash 循环就能完成全部工作for f in *.docx; do pandoc -s $f -t markdown --extract-media./media/${f%.docx} -o ${f%.docx}.md echo 已转换: $f done${f%.docx}是 bash 的变量替换用来去掉后缀名保证输出的 Markdown 文件与原文件同名。--extract-media./media/${f%.docx}会把每份文档的图片单独存到一个以当前文档名命名的子目录里避免不同文档的image1.png互相覆盖。运行前务必干一件事把所有 docx 放到一个独立的目录里面只保留需要转换的文档免得脚本误伤其他文件。7.2 PowerShell 批量处理中文文件名和编码的坑Windows 环境下推荐用 PowerShell 做批量转换但有几个大坑必须先说。第一PowerShell 5.x 的默认编码不是 UTF-8。如果你在脚本里输出的日志包含中文很容易变成乱码。建议在脚本开头加$OutputEncoding [System.Text.Encoding]::UTF8第二中文文件名本身没有问题但某些旧版 Pandoc 在 Windows 下处理含空格或全角符号的路径时可能报错。稳妥的方式是统一用Get-ChildItem获取文件对象再传$_.FullName给 Pandoc避免手写路径Get-ChildItem -Path . -Filter *.docx | ForEach-Object { pandoc -s $_.FullName -t markdown --extract-media./media_$($_.BaseName) -o $($_.BaseName).md }第三如果批量转换过程中某一份文档报错脚本默认会继续执行还是停止PowerShell 默认遇到非中断错误会继续但我想让它明显标出来所以加上try/catch或直接检查$LASTEXITCODEGet-ChildItem -Path . -Filter *.docx | ForEach-Object { pandoc -s $_.FullName -t markdown --extract-media./media_$($_.BaseName) -o $($_.BaseName).md if ($LASTEXITCODE -ne 0) { Write-Host 转换失败: $($_.Name) -ForegroundColor Red } }7.3 转换后的一致性检查清单批量转换跑完之后别急着收工按这个清单过一遍检查每个输出目录的图片数量跟 Word 原文档里的图片数量是否吻合。抽查 3-5 个文件确认标题层级、表格、公式的转换质量。用编辑器打开几个 Markdown 文件全局搜索assets/media路径确认所有图片引用都能在本机打开。如果发现某份文档有异常回到原文件检查是不是样式或嵌入方式有问题修复后重新转换。批量转换的关键在于“可重复”转换命令、清理脚本、检查清单都保留下来下次再来一批文档时直接用同一套流程跑一遍就行。8. 我踩过的几个坑以及最终的实践经验总结最后分享一些我在真实项目中踩过的坑每个都是花时间换来的。8.1 图片文件名乱序Pandoc 重命名图片的规律第一次批量转换后我兴冲冲地预览 Markdown发现图片张张都在但顺序不对——文中的第一张截图落盘文件名居然是image5.png。当时以为是 Pandoc 的问题后来才发现是 Word 内部图片对象的引用 ID 排列顺序跟视觉顺序不完全一致。解决方案分两种如果不在乎文件名那么在 Markdown 渲染层面引用顺序是正确的你看到的效果没问题如果有强迫症或者需要人工维护图片文件那就用图片管理工具统一重命名或者写脚本按出现顺序重新命名。这里我提醒一句不要试图手改 Pandoc 生成的引用路径除非你同时改了文件名否则很容易出现“文字对不上图”的尴尬。8.2 字体效果保留粗体、斜体可以下划线和颜色会丢失Word 里的加粗、斜体Pandoc 能准确转成 Markdown 的**和*。但下划线是 Markdown 标准语法里没有的东西Pandoc 转换时直接把下划线吞掉了。如果你确实需要保留下划线可以在转换后把对应文本单独替换为 HTML 标签u文字/u但这种做法在大多数 Markdown 渲染器里也能正常显示只是没法保证在所有平台统一。字体颜色、高亮、删除线这类视觉样式基本不值得刻意保留。原因我之前说过Markdown 是内容优先的格式颜色和字号应该交给渲染层去控制。如果有一处文字在 Word 里是红色强调那么转换时你更应该关注的是它是不是真的需要强调而不是强行把红色属性带到 Markdown 里。8.3 “保留 Word 格式”的正确理解保留结构而不是像素级还原这个体会我想多说几句。很多朋友问“Word 转 Markdown 能保留格式吗”我的答案是能保留的是结构格式不是视觉效果。标题层级、列表嵌套、表格结构、脚注、公式、图片引用这些是信息层面的而字体、字号、行距、缩进、页边距这些是展示层面的在 Markdown 里本来就不存在。理解了这个区别你对转换结果的期望就不会过高也不会因为一段文字没有居中对齐就觉得转换失败了。实际上居中对齐这种需求在 Markdown 里可以用div aligncenter实现但这属于特例不是常规操作。8.4 最省时间的转换工作流分享把前面所有经验压缩成一套最省时间的流程大概是这样的用 Python 或手动快速检查 docx 的样式使用情况、图片状态、公式类型。在 Word 里统一修复标题样式、MathType 公式、手动编号。用 Pandoc 批量转换每个文档单独存放媒体文件。用 VS Code 全局替换图片路径补 Frontmatter。打开 Typora 或文档站预览人工过一遍标题层级和复杂表格。有问题就改原文件再转不要直接改 Markdown。这套流程我跑了很多次从最初的一次转换要用一整天到后来平均每份文档可以控制在十分钟以内包括清理和检查。真正让我觉得踏实的不是某个工具多强大而是每一步都可以被重复、被验证、被修复。Word 转 Markdown 不是什么黑科技它就是一个“结构化文档 → 另一个结构化文档”的映射过程理解了源文件的本质选对工具剩下的就是耐心和细节了。