DS随心转
Word 至今没有内置的 Markdown 解析能力。你可以用 Word 打开一个 .md 文件，但它只会当纯文本处理——满屏的 # 和 ** 原样躺在那儿。
所以这件事一定需要一个转换工具。下面五种方法，先看对比：
| 方法 | 转换引擎 | 需要装环境 | 公式可编辑 | Mermaid 流程图 | 中文字体 |
|---|---|---|---|---|---|
| 在线转换工具 | Pandoc | 否 | 是 | 自动渲染 | 已配好 |
| Pandoc 命令行 | Pandoc | 是 | 是 | 需另配过滤器 | 要自己配 |
| Typora 导出 | Pandoc（需另装） | 是 | 是 | 视版本而定 | 要自己配 |
| VS Code 插件 | 多为 Pandoc 封装 | 是 | 视插件而定 | 通常不支持 | 要自己配 |
| 手工整理 | 无 | 否 | 手工处理 | 手工截图 | — |
看这张表会发现一件事：除了手工整理，几乎所有方法底层都是 Pandoc——包括 DS随心转，它的转换引擎就是 Pandoc。所以真正的差别不在转换质量，而在谁来维护那套环境。
方法一：在线转换工具
不装任何东西，粘贴即转。
用 DS随心转：把 Markdown 粘进编辑区，右侧实时预览 A4 分页效果，选 Word 格式下载。
转换过程中处理掉的：标题层级映射到 Word 的样式层级（这决定了能不能自动生成目录）、表格变成带边框的真实表格、LaTeX 公式转成可编辑的 Word 公式对象、代码块保留等宽字体、Mermaid 流程图渲染成图形嵌入。
它和你自己装 Pandoc 的关系：引擎是同一个，公式转 OMML、标题层级、表格这些底层行为完全一致。区别在于下面三件 Pandoc 用起来最花时间的事，在线版已经替你处理好了：
- 中文字体：不用再准备 reference-doc 去调各级样式的中文字体；
- Mermaid 流程图：Pandoc 原生不认 mermaid，命令行要额外装过滤器，在线版直接渲染成图；
-
公式的边界情况：行内公式被写成
$$、正文里落单的$、公式里的中文，这些在转换前就做了处理。
适合：不想在本机维护一套转换环境；内容里有流程图、公式这类需要额外处理的元素。
局限：一次处理一篇；需要联网。
方法二：Pandoc 命令行
文档转换领域的通用工具，也是很多其他工具背后实际在用的引擎。
最简单的用法：
pandoc input.md -o output.docx
Pandoc 原生支持把 LaTeX 公式转成 OMML，所以公式在 Word 里是可编辑的。
控制样式：Pandoc 不接受 CSS，它靠一个"参考文档"来决定样式。做法是先导出一个默认的模板，改好里面的样式（字体、字号、行距、标题样式），之后每次转换都引用它：
pandoc --print-default-data-file reference.docx > custom.docx
# 用 Word 打开 custom.docx，修改各级样式后保存
pandoc input.md --reference-doc=custom.docx -o output.docx
中文字体：这是 Pandoc 路线最常见的坑。默认模板的正文字体不是中文字体，转出来的文档中文显示可能不理想。解决办法就是在上面的参考文档里，把"正文"和各级标题样式的中文字体设置好。
批量：命令行的真正长处在这里——本地一批 .md 文件、或者要把转换接进脚本和 CI 流程时，只有命令行做得到。
for f in *.md; do pandoc "$f" --reference-doc=custom.docx -o "${f%.md}.docx"; done
局限：要安装；Mermaid 流程图不会被渲染，需要额外的过滤器；命令行参数有学习成本。
适合：有技术基础、需要批量或接进自动化流程、对样式有精细要求。
方法三：Typora 等编辑器导出
如果你本来就在用 Typora 写作，文件 → 导出 → Word 是最顺手的。
需要注意的是，Typora 的 Word 导出依赖本地安装的 Pandoc，没装的话这个菜单项会提示报错。装好 Pandoc 之后，效果和方法二基本一致，只是省掉了敲命令。
Obsidian、Marktext 等编辑器的情况类似，大多也是调用 Pandoc。
方法四：VS Code 插件
在 VS Code 里写 Markdown 的话，市场里有若干转 Word 的插件，多数同样是对 Pandoc 的封装。装之前留意两点：是否需要另外安装 Pandoc、公式转出来是对象还是图片。
方法五：手工整理
内容极短、只有标题和段落时，直接在 Word 里重新排一遍反而最快。但凡有表格、公式或者超过两屏，就别这么干了。
格式保留对照表
不同方法的具体表现会有差异，但大致规律是一致的：
| Markdown 元素 | 转换后的表现 | 需要留意 |
|---|---|---|
标题 # ## |
映射到 Word 标题样式 | 保住样式才能自动生成目录 |
| 加粗、斜体 | 正常保留 | — |
| 有序 / 无序列表 | 正常保留 | 多级缩进偶尔需要手工调 |
| 表格 | 带边框的 Word 表格 | 合并单元格无法自动实现 |
| 代码块 | 等宽字体独立区域 | 语法高亮是否保留看工具 |
| LaTeX 公式 | Word 公式对象（OMML） | 部分工具产出的是图片 |
| 图片 | 嵌入文档 | 相对路径必须正确 |
| 链接 | 超链接 | — |
| 脚注 | Word 脚注 | 部分简易工具会丢 |
| Mermaid 流程图 | 渲染成图形 | Pandoc 默认不处理 |
| HTML 内嵌标签 | 视工具而定 | 复杂 HTML 大概率丢失 |
四个常见坑
一、标题层级跳级
# 直接跳到 ###，转出来的 Word 目录会缺一层。写的时候按顺序用，别跳。
二、图片路径
Markdown 里的  是相对路径。转换工具要能按这个路径找到文件才能嵌入。用在线工具时，本地图片一般需要另外上传；网络图片则要求转换时能访问到那个地址。
三、公式里的中文
LaTeX 里的中文必须包在 \text{} 里，否则容易转换失败或者中文被吞。这一条在公式那篇里有更详细的说明。
四、正文里落单的 $
写"预算 $50 万"时，这个 $ 会被当成公式的起点，可能吞掉后面一大段内容。改成"美元"或者写成 \$。内容越长这个问题越严重，长文档导出失败那篇里有完整的排查方法。
怎么选
引擎都是 Pandoc，所以别按转多少篇来选，按这份转换要接进什么流程来选：
- 手边就要一份能交付的 Word → 在线工具。中文字体、Mermaid、公式边界情况都已处理好，粘贴即得；
- 要把转换接进脚本、CI 或定时任务 → Pandoc 命令行，这是它不可替代的地方；
- 本地有一整批 .md 文件要一次转完 → Pandoc 命令行，配好 reference-doc 后循环处理；
- 对模板有精细到样式级的要求（比如公司统一的公文格式）→ Pandoc 命令行，自己维护 reference-doc；
- 已经在用 Typora 写作 → 装个 Pandoc 用它的导出，省掉敲命令；但 Mermaid 和中文字体仍要自己解决。
一句话：在线工具省的是环境维护，命令行换来的是可编程。 两者的转换质量本身没有差别。
常见问题
Word 能直接打开 .md 文件吗？
Word 能把 .md 文件当纯文本打开，但不会解析 Markdown 语法——你会看到满屏的 # 和 *。Word 至今没有内置的 Markdown 解析能力。
Markdown 转 Word 后公式还能编辑吗？
取决于工具。Pandoc 和 DS随心转都会把 LaTeX 公式转成 Word 原生公式对象（OMML），双击可以继续编辑。而截图或者部分简易转换器产出的是图片，不能编辑。
Pandoc 和在线工具该选哪个？
DS随心转的转换引擎就是 Pandoc，两者的转换质量没有差别，选择取决于你要不要可编程能力。要把转换接进脚本、CI，或批量处理本地一批 .md 文件，用 Pandoc 命令行；只是要一份能直接交付的 Word，用在线工具——中文字体、Mermaid 流程图、公式的边界情况都已经配好，不用自己维护环境。
转换后中文字体不对怎么办？
这是自己跑 Pandoc 时的经典问题，需要准备一个设置好中文字体的参考文档，用 --reference-doc 参数指定。在线工具用的是同一个引擎，但中文模板已经配好，不需要额外处理。
图片会一起带过去吗？
本地图片需要保证相对路径正确，转换工具才能找到并嵌入。网络图片要求转换时能访问到该地址。路径错误时图片会变成一个占位符或直接丢失。