如何把 Markdown 转成 PDF——按折腾程度排序的三种方法

信息核对截至 2026 年 10 月 13 日。 Pandoc 版本、PDF 引擎与操作系统会影响命令，请在生产自动化前核对当前手册。

1. 为什么 Markdown 转 PDF 是人人迟早要做的转换

Markdown 是写文档的地方，PDF 是交付文档的地方。用 Markdown 起草的简历，最终得变成 PDF，因为招聘系统只认这个格式；客户报告要有固定的分页，因为「第 4 页」必须在每块屏幕、每台打印机上指同一页；电子书章节、要打印的会议纪要、随邮件发出去的提案，要的都是同一种确定性。Markdown 转 PDF，本质上是给「为书写设计的格式」和「为交付设计的格式」之间架一座桥——所以几乎每个写文档的人，迟早都会撞上这次转换。

这两个格式互相「为难」的方式相当固定，认清失败模式就赢了一半。Markdown 完全不携带页面几何信息：没有纸张尺寸、没有页边距、没有字体、没有分页的概念；而 PDF 恰恰全是页面几何。所以每个转换工具都在替你做排版决定，工具之间的真正区别，在于这些决定里有哪些允许你推翻。这些旋钮在哪儿、哪条路摸得到，就是第 5 节的主题。

如果你对格式本身还不熟——这套语法为什么这么设计、纯文本为什么在工具之间迁移最省事——可以先看我们写的 Markdown 入门讲解。本文默认你手里已经有一个 .md 文件，和一个必须把它变成 PDF 的理由。

2. 路径一：浏览器免安装——什么都不用装、什么都不用配

只有一份文档、还有一个截止时间的时候，为它装一整套排版工具链，是典型的用力过猛。浏览器路线把 PDF 导出当成一个渲染问题来解：Markdown 先变成排好版的页面，页面走浏览器的打印管线，PDF 从另一头出来——跟你平时用浏览器打印任何东西是同一条管线，所以这条路不需要安装，也几乎不需要学习成本。对不靠转换文档吃饭的人来说，它排第一。

具体流程是：在可信渲染器中打开 Markdown，检查预览，再使用 PDF 导出或浏览器打印。最终 PDF 仍要核对纸张、边距、链接、文字可选取性、字体、页眉页脚和分页；打印样式、字体替换与浏览器设置都可能让导出结果不同于屏幕预览。

这条路的边界也得说清楚。它一次处理一份文档，不提供脚本化能力，也永远不该被用来做「每次发版重新生成 40 份 PDF」的构建管线——那是下一节命令行的主场，任何网页都替代不了它。另外它默认你的起点是 Markdown；如果你手里其实是网页或 Word 文档，先做一次 HTML 转 Markdown，再回到这里。

3. 路径二：Pandoc 命令行——以及那个著名的坑

pandoc 是文档转换领域的参照系：一个命令行程序，读写几十种格式，多年来一直是技术写作工具箱的地基，pandoc 官方手册有它的完整文档。从 pandoc 安装页装好之后，最基本的转换就一行：

pandoc resume.md -o resume.pdf

在一台没装 TeX 的机器上，这行命令会停下来，报错说找不到 pdflatex。这就是那个坑，几乎每个人都会被咬一口。pandoc 自己并不渲染 PDF：默认路线是先生成 LaTeX，再交给 TeX 引擎去排，于是一个轻量转换器悄悄挂上了桌面出版领域最重的依赖之一。Windows 上这个依赖通常是 MiKTeX，macOS 和 Linux 上是 TeX Live 或它的精简变体。完整的 TeX 发行版以 GB 计，新装的还可能在转换中途停下来等你确认缺哪些宏包——所以干净机器上的第一次转换，常常需要盯着跑，而不是一键到底。

截至 2026 年，这个坑已经有成熟的绕法：Typst。pandoc 从 3.1.7 版起支持把 Typst 当 PDF 引擎，同一个转换可以完全不碰 TeX：

pandoc resume.md -o resume.pdf --pdf-engine=typst

Typst 是一个现代排版系统，以单个二进制分发、体积以几十 MB 计，对比以 GB 计的 TeX 路线；当前版本可在 Typst 官网下载。代价真实但有限：LaTeX 的生态仍然更深（期刊模板、各种冷门宏包），Typst 生成的文件因为完整内嵌字体会偏大。对「新机器上配一套 Markdown 转 PDF」这件事，今天我们会先装 Typst 路线。

4. 路径三：编辑器自带导出——VS Code、Obsidian 与 Typora

第三条路你可能已经有了而不自知。文件本来就开在编辑器里，就地导出比换工具划算；对那些生在编辑器、死在编辑器的草稿，这个理由就够了。要留神的是，编辑器导出是三条路里表现最不稳定的一条：效果取决于你装了哪个扩展、它打包了哪些字体。

截至 2026 年 9 月，可选项大致是：VS Code 自带 Markdown 预览，从预览走浏览器打印也能凑合，但更顺手的是装扩展——VS Code 插件市场上的开源 Markdown PDF 扩展在右键菜单里加了导出。Obsidian 从笔记菜单原生导出 PDF，不用装任何插件。Typora 边写边渲染、从文件菜单导出 PDF，不过从 1.0 版起它是一个一次性买断的付费应用。这几条路都不需要往工作流里添加新工具，这正是它们的吸引力。

毛边也足够一致，以至于在 Stack Overflow 上搜这条路径，前排全是这些问题：代码块在分页处被尴尬地切开甚至整体截断；宽表格右边缘被裁掉；非拉丁文字导出成一个个空框，因为导出字体里没有那些字形。分页控制普遍薄弱：VS Code 扩展给了样式表入口，但你要是要求「某个标题必须从新页开始」，最后多半是在跟工具搏斗，而不是在写东西。这些正是第 5 节清点的同一批保真问题——区别只在于，这条路给你的旋钮最少。

5. 格式保真：分页、表格宽度、代码换行与字体

「转出来的 PDF 不对劲」的抱怨，几乎全部来自四类缺陷：分页乱掉、表格比页面宽、代码块被切开或溢出、文字导出成空框。在怪转换器之前，先弄清哪个旋钮在哪条路上，是划算的——因为这些问题里约有一半，改 Markdown 源文件比改任何导出设置都便宜。下面的表把四类缺陷对到三条路各自给的控件上。

这张表里的规律是有意为之，不是巧合：浏览器路线继承的是网页排版行为——表格换行而不是被裁、字体来自本机；命令行继承的是印刷排版——几何固定、旋钮明确、默认值更讲究。编辑器扩展夹在中间，继承多少全看作者实现了什么，所以它们的行为差异最大。

命令行路线有两条具体配方值得收藏。带中文的文档，pandoc 的标准做法是配一个 Unicode 感知的引擎加显式中文字体——默认的 pdflatex 引擎完全处理不了 CJK：

pandoc notes.md -o notes.pdf --pdf-engine=xelatex -V CJKmainfont="Noto Sans CJK SC"

另一条是改源文件的思路：表格太宽，先在 Markdown 里砍列，或者拆成两张窄表——对照一份 Markdown 速查表重构就够了；任何导出设置对十列宽表的抢救，都不如直接重写。先修输入，是唯一在三条路上同样有效的保真旋钮。

6. 一整个文件夹的 .md：批量转换的现实检查

文档集很少以单个文件出现。一个文档目录、一个更新日志文件夹、一个季度的会议纪要——问题很快变成「把这些全转了」，而三条路在这件事上分野最大。免费好用的选项在这里撞上真实边界，命令行则老当益壮。

命令行天然会循环，而且这个循环短到可以背下来：

for f in *.md; do pandoc "$f" -o "${f%.md}.pdf"; done

这个循环会转换当前文件夹中匹配的 .md 文件。周期性任务应把命令、Pandoc 版本、引擎、字体和模板纳入版本管理，写入独立输出目录，并在任何源文件未生成有效 PDF 时让任务失败。

单文档渲染器适合从 Markdown 导出简历，但重复文件夹需要批处理。文件夹规模的 Markdown 工作流介绍清单、独立输出目录、断点续跑与验证，不把 GUI 或脚本的结果默认视为正确。

7. 结论

按折腾程度选，不要按功能上限选。一份文档、不想碰工具链：走浏览器路线，等一个 TeX 发行版解压完的功夫，活已经干完了。重复的、要写进脚本的、进版本库的转换：pandoc，除非你明确要 LaTeX 的模板生态，引擎选 Typst。草稿在编辑器里：就地导出，接受第 4 节描述的那些毛边。以及在怪任何转换器之前，先修源文件——表格窄一点、代码行短一点——因为对诚实的输入，每条路都渲染得更好；对一张过宽的表，没有哪条路救得漂亮。