轻量级Markdown编辑器实测：公式、图表、搜索全内置，告别插件折腾

最近几个月，我一直被一件事折腾得够呛：为了写 Markdown 文档，电脑上装了一堆插件。VS Code 里塞了 Markdown All in One、Paste Image、Markdown Preview Enhanced，又专门装了 Mermaid 预览插件；写带公式的技术文档时还得再开一个公式预览窗口。结果就是每次打开编辑器都要等半天，插件之间偶尔还会互相打架，渲染出的效果一个样。后来我给自己定了一个很“变态”的目标：找一款不到 10MB 的免费 Markdown 编辑器，公式、图表、搜索全部内置，一个插件都不装。这篇就是我实际筛选、测试、使用下来的完整记录。

1. 起因：我从“插件全家桶”逃回“全内置”

1.1 那台被插件拖垮的旧电脑

我手头有一台前几年的办公本，配置不算差，但也不算新。VS Code 装上一堆 Markdown 相关插件之后，启动时间从原来的两三秒直接飙到十几秒。最离谱的是有一次 Markdown Preview Enhanced 更新后，我之前写的某个 Mermaid 流程图渲染方式全变了，图里中文乱码，样式也完全不对。那篇文章急着交，我硬是用截图工具重新画了一张图才搞定。

从那之后我就意识到：插件生态虽然灵活，但它的代价是持续的维护成本。每个插件都可能在某次更新后不再兼容，插件之间的关系也需要你自己兜底排查。对于写作这种本来应该很专注的事情，这太不划算了。

1.2 插件给你的，内置同样能给你

有人可能会说，VS Code 插件多是因为功能需要啊。但仔细想一下，Markdown 写作里高频用到的核心能力其实就那么几项：写公式、画图表、做全文搜索、导出 PDF。这几个需求在 VS Code 里要靠好几个插件配合才能完成，但在一些特意做“全内置”的编辑器里，它们是开箱即用的基础能力。

“内置”和“插件”的最大区别是：内置功能经过开发者的统一调校，相互之间的兼容性是已经验证过的；而插件之间是否兼容，得靠你自己试错。我这次找工具的原则就是：能内置解决的，绝不额外加插件。

2. 轻量编辑器怎么装下公式、图表和搜索？——技术实现拆解

2.1 公式：KaTeX 与 MathJax 之争

很多轻量级 Markdown 编辑器之所以能同时保持体积小和公式渲染流畅，关键在选用了KaTeX或MathJax这类纯前端公式引擎。

KaTeX 是轻量级选手，渲染速度极快，适合文档中公式数量较多的场景。大多数编辑器内置的是 KaTeX，这也是为什么一些体积很小的编辑器打开公式文档时依然能秒开。MathJax 则更强调整体兼容性，支持更多 LaTeX 宏包和语法，比如一些复杂的分组、矩阵环境，但渲染速度相对慢一点。

从用户视角，我不需要知道内部用的哪个引擎，只需要知道它支持标准的 LaTeX 语法就够了。比如行内公式用$...$包裹，块级公式用$$...$$包裹：

行内公式示例：$\alpha^2 + \beta^2 = \gamma^2$ 块级公式示例： $$ \int_{-\infty}^{+\infty} e^{-x^2} \, dx = \sqrt{\pi} $$

大多数支持公式的轻量编辑器都能正确渲染这些语法。如果你的文档里公式特别多，比如毕业论文、理工科讲义，建议选 KaTeX 引擎的编辑器，滚动长文档时会更跟手。

2.2 图表：Mermaid 和其他轻量方案

图表是另一个容易被插件绑架的功能。很多人为了画流程图、时序图、甘特图，专门装 draw.io 或各种图表软件。但实际上，Mermaid 语法通过 Markdown 代码块就能完成大部分图表绘制。

常见用法是在 Markdown 里写这样的代码块：

graph TD A[开始写文章] --> B{需要公式?} B -->|否| C[直接输出 Markdown] B -->|是| D[插入 LaTeX 公式] D --> E[编译渲染] C --> F[导出 PDF] E --> F

再比如很多课程作业里要画 ER 图，描述图书馆借阅系统的数据模型，用 Mermaid 也很方便：

erDiagram READER ||--o{ BORROW : "借阅" READER { string reader_id PK string name string phone } BOOK ||--o{ BORROW : "包含" BOOK { string book_id PK string title string author }

完全文本化意味着什么？意味着改图只需改几个字符，不用拖动鼠标反复调节方块位置。修改完保存刷新，一张新图就出来了。而且文本化的图表可以直接放进 Git 做版本管理，写技术方案时特别方便。

2.3 搜索：小体积不等于小能力

全文搜索这一项，很多轻量编辑器做得很到位。它们不需要像 Windows 系统搜索那样建立磁盘级索引，因为 Markdown 文档本质上是纯文本文件，字符串匹配的效率非常高。

我刚开始也很怀疑，一个不到 10MB 的编辑器，搜索能力能有多强？实际用下来发现，对于几百篇 Markdown 文档的笔记库，全库搜索几乎是瞬间出结果。有些编辑器还能同时搜索文件名和文件内容，也支持正则表达式。也就是说，只要文档量级在“个人知识库”范围内，轻量编辑器的搜索完全够用。

3. 实测：我筛了几款主流免费 Markdown 编辑器

3.1 测试维度

为了不盲目下结论，我给自己列了一个明确的测试标准：

• 安装包大小：越接近 10MB 越好
• 是否免费：必须免费或满足个人使用免费
• 公式支持：能否渲染行内/块级 LaTeX 公式
• 图表支持：能否直接渲染 Mermaid 或类似文本图表
• 全文搜索：能搜当前文档还是能搜整个目录
• 离线可用：不联网能不能正常渲染公式和图表

按这个标准，我实际装了以下几款软件来测试：Typora、MarkText、Zettlr、Joplin、Obsidian，以及一款体积特别小的开源编辑器 Ghostwriter。

3.2 几款编辑器的实测记录

下面是基于我手头版本的实际感受，安装包体积会随版本变化，只做大致参考：

3.3 最终选择：为什么留下这一款

几轮测试下来，我留在本地的是Ghostwriter。它的安装包不大，在 Linux 上用 AppImage 版本，20MB 上下；Windows 便携版更苗条一些。免费开源，没有付费墙，公式直接支持 KaTeX 渲染，Mermaid 图表也能在预览里直接出图，还带全文搜索。最让我满意的是界面极其克制，没有任何多余面板，打开就是一块干净的写作区域。

当然，这并不意味着其他软件不好。Typora 的界面优雅程度至今没有对手，如果能接受付费，它依然是很多人心中的首选。MarkText 的 Markdown 实时预览也很舒服，只是体积确实大。我需要的是一台普通办公本上能快速打开、长期不折腾的纯 Markdown 编辑器，Ghostwriter 刚好卡在我的需求点上。

4. 把“全内置”用到极致：写作流程、模板与导出

4.1 我的日常写作工作流

工具确定后，整个写作流程变得非常简单：

1. 建立一个纯文本目录作为笔记库，每个主题一个文件夹。
2. 用编辑器打开这个目录，写文档时随时插入公式和 Mermaid 图表。
3. 需要查以前写的内容时，直接调用编辑器内置搜索，输入关键词就能定位到具体文件。
4. 需要对外分享或提交作业时，用内置的导出功能，或者配合 Pandoc 转成 PDF 或 Word。

这套流程里，我不需要费心维护任何插件，所有的操作都在一个窗口里完成。

注意一点：目录结构一定要清晰。我习惯把图片单独放一个assets子目录，每篇文章的图片只归放到该文章对应的目录下，避免以后迁移时图片互相覆盖。

4.2 导出 PDF 时公式和图表不乱的秘诀

Markdown 编辑器里预览得再好，导出 PDF 时也容易出现两个经典问题：公式突然变成一行源码，图表排版错乱。

第一个问题的常见原因，是导出时没有启用对应数学渲染引擎。大多数“全内置”编辑器的导出功能会自动调用内置引擎处理公式，但如果用的是混合式的编辑器，就需要确认一下导出设置里的“数学渲染”是否开启。

第二个问题，我在实际使用中总结了一个比较稳妥的操作：导出 PDF 前，先在预览界面让所有公式和图表都渲染一遍，再执行导出。这一步听起来多余，但确实能避免很多编辑器在导出时跳过尚未渲染内容的 bug。

中文文档导出 PDF 时，还要注意字体设置。部分轻量编辑器默认字体不支持中文字符，导出的 PDF 中文部分全是方框。解决方案也很简单：在导出模板或 CSS 里指定一个系统中文字体，比如“Noto Sans CJK SC”或“Microsoft YaHei”。

4.3 图片与附件怎么管理

写作过程中难免要贴截图。VS Code 时代我用过 Paste Image 插件，它能自动把剪贴板里的图片存到指定目录并插入相对路径。而换到全内置编辑器后，我发现很多编辑器自带这个能力，只是入口比较隐蔽。

基本的逻辑是：先在设置里找到“图片保存位置”，设置为“相对于当前文件”的某个目录，之后往编辑器里粘贴截图时，它就会自动保存并生成正确的引用路径。这样移动整个项目文件夹时，图片和文档的关联依然不会断。

5. 常见坑与我的排查经验

5.1 公式显示不对齐？多半是空格和标点的问题

之前有朋友问我，行内公式接在中文后面时，总感觉公式和文字挤在一起，怎么调都别扭。这个问题的根源其实不在编辑器，而在 Markdown 语法里公式边界符$与中文之间的空格处理。

很多解析器会把“中文$公式$中文”这种连续写法当作普通文本而不是公式。比较稳妥的写法是在公式两侧保留一个空格：

这个公式 $E=mc^2$ 是质能方程。

如果还是不对齐，可以试试用\(...\)包裹，这属于 LaTeX 原生数学环境，兼容性更好：

这个公式 \(E=mc^2\) 是质能方程。

另外，公式片段里不要混入中文标点，比如全角逗号、句号，它们会直接导致渲染失败或错位。

5.2 全文搜索找不到内容？先检查索引和排除目录

有一次我在笔记库里搜“二叉搜索树”这个关键词，明明有一篇笔记里反复提到了，编辑器却死活搜不出来。排查了半天发现，那篇笔记放在一个以.开头的隐藏目录里，而编辑器的默认搜索规则会跳过隐藏目录。

遇到这种情况，优先检查几个地方：

• 搜索设置里是否勾选了“包含隐藏文件”
• 是否设置了太多排除目录，比如把整个assets目录排除掉了
• 如果是需要索引的编辑器，索引是否已经重建

还有一个容易被忽略的坑：部分编辑器的搜索默认只搜文件名，不搜文件内容，需要在搜索框前手动切换“内容搜索”模式。第一次使用某个编辑器时，先花一分钟把搜索模式弄明白，能省很多事。

5.3 图表在 PDF 里渲染成一坨乱码？先确认预览状态

Mermaid 图表的本质是前端 JavaScript 渲染出的 SVG 图像。预览时正常，不代表导出 PDF 时也能正常。导出时如果编辑器没有预先执行渲染脚本，PDF 里出现的很可能就是一坨原始代码或者空白框。

我的经验是：导出之前先在预览模式里强制刷新一次，看到图表完整显示后再导出。如果你的编辑器提供“导出前执行渲染”选项，一定要勾上。另外，如果图表内容特别复杂，比如层层嵌套的流程图，建议拆分成两张小图，导出成功率更高，阅读体验也更好。

6. 关于“体积”的执念，说点大实话

回到最初的问题：真的必须“不到 10MB”吗？

严格来说，满足“公式、图表、搜索全内置且一个插件都不用装”的工具，不一定都能卡在 10MB 线以内。Ghostwriter 的 AppImage 版在我的机器上大概 20MB 左右，便携版相对瘦一点。Typora 也是二十几MB的量级，因为它内置了自己的渲染引擎，体积自然压不到 10MB。

但话说回来，“小体积”其实是一种产品哲学。它代表开发者愿意花功夫做减法，不让用户为了一个公式渲染功能就背上几十上百 MB 的运行时环境和一堆第三方库。10MB 这个数字只是一个具象化的筛选条件，背后真正的需求是：启动快、占用低、别折腾、随开随写。

我现在的办公本上，写作工具就只剩一个便携版编辑器和 Pandoc。写技术博客、整理课程笔记、画流程图时序图，全在这一套里面完成。不再天天盯着插件更新列表，整个人轻松很多。

如果你也经常被插件生态折腾得够呛，我建议你给自己定一条规矩：多一个功能宁可换工具，也不要再加插件。这套思路不一定适合所有场景——比如你需要复杂的自定义脚本和联动工作流时，VS Code 和 Obsidian 的插件体系依然有不可替代的价值——但对单纯想安静写点东西的人来说，“全内置、零插件”真的很香。工具这东西，本质上是为了让写作更高效，而不是让我们花更多时间维护工具本身。