最近几个月我一直被一件事折腾得够呛为了写 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 几款编辑器的实测记录下面是基于我手头版本的实际感受安装包体积会随版本变化只做大致参考编辑器安装包大小约免费公式图表全文搜索我的评价Typora20~25MB收费好支持 Mermaid支持体验好但不符合“免费”要求MarkText70MB 以上免费开源好支持 Mermaid支持体积偏大启动稍慢Zettlr80MB 以上免费开源好支持多种图表强学术向功能重Joplin80MB 以上免费开源好需插件强本质是笔记软件Obsidian80MB 以上个人免费好多数靠插件强插件生态大但违背初衷Ghostwriter10~20MB免费开源好支持 Mermaid支持最接近我的需求3.3 最终选择为什么留下这一款几轮测试下来我留在本地的是Ghostwriter。它的安装包不大在 Linux 上用 AppImage 版本20MB 上下Windows 便携版更苗条一些。免费开源没有付费墙公式直接支持 KaTeX 渲染Mermaid 图表也能在预览里直接出图还带全文搜索。最让我满意的是界面极其克制没有任何多余面板打开就是一块干净的写作区域。当然这并不意味着其他软件不好。Typora 的界面优雅程度至今没有对手如果能接受付费它依然是很多人心中的首选。MarkText 的 Markdown 实时预览也很舒服只是体积确实大。我需要的是一台普通办公本上能快速打开、长期不折腾的纯 Markdown 编辑器Ghostwriter 刚好卡在我的需求点上。4. 把“全内置”用到极致写作流程、模板与导出4.1 我的日常写作工作流工具确定后整个写作流程变得非常简单建立一个纯文本目录作为笔记库每个主题一个文件夹。用编辑器打开这个目录写文档时随时插入公式和 Mermaid 图表。需要查以前写的内容时直接调用编辑器内置搜索输入关键词就能定位到具体文件。需要对外分享或提交作业时用内置的导出功能或者配合 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 语法里公式边界符$与中文之间的空格处理。很多解析器会把“中文$公式$中文”这种连续写法当作普通文本而不是公式。比较稳妥的写法是在公式两侧保留一个空格这个公式 $Emc^2$ 是质能方程。如果还是不对齐可以试试用\(...\)包裹这属于 LaTeX 原生数学环境兼容性更好这个公式 \(Emc^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 的插件体系依然有不可替代的价值——但对单纯想安静写点东西的人来说“全内置、零插件”真的很香。工具这东西本质上是为了让写作更高效而不是让我们花更多时间维护工具本身。