不到10MB免费Markdown编辑器：内置公式图表搜索，无需插件

如果你也经历过一边嫌 Typora 收费、一边嫌 VS Code 要配一堆插件才能舒服写 Markdown 的阶段，应该能理解我今天的选题：我找到了一款不到 10MB 的免费 Markdown 编辑器，公式、图表、搜索全部内置，一个插件都不用装。它最适合三类人：需要频繁写数学公式的学生、把 Markdown 当主力笔记格式的工程师、以及不想折腾插件只想打开就写的博客作者。这篇文章会把选型逻辑、功能实测、实际操作和踩坑记录完整写出来，不是广告，纯粹是我用了大半个月后的复盘。

1. 先从“为什么不用插件”说起：轻量编辑器的生存逻辑

1.1 大多数人的 Markdown 使用场景，根本不需要插件市场

先复盘一下我自己是怎么被“插件化”劝退的。最早我用 Typora，确实开箱即用，但它后来进入付费阶段，而且某些版本体积越来越大、启动明显变慢。后来我切到 VS Code，准备走“Markdown 全能工作流”，结果装插件就花了一下午：主题要装、预览要装、格式化要装、目录生成要装，连在 Markdown 里画个表格对齐都得找扩展。

装完还不算完，插件之间的快捷键冲突、界面风格不一致、部分插件长期不更新造成的兼容性问题，才是真正让人头大的地方。我并不是说插件生态不好，VS Code 的最大优势就是插件生态，但它的目标用户是开发者，而不是“想安安静静写点技术笔记和博客的人”。

对绝大多数人来说，Markdown 编辑器只需要满足三件事：写起来顺手、渲染准确、文件找得着。换算成功能就是：一个靠谱的编辑区、一个支持数学公式和图表的预览区、一个能按文件名和内容搜索的入口。这三种能力恰恰可以完全内置，不需要任何扩展。

1.2 从安装包体积反推产品思路：原生应用 vs Electron 壳

很多人看到 10MB 这个数字，第一反应是“功能一定很简陋”。这是被动辄几百 MB 的编辑器惯出来的错觉。动辄上百 MB 的编辑器，有相当一部分体积是运行时撑起来的，比如 Electron 里打包了整套 Chromium 浏览器内核，不管你是打开一个几十万字的文档还是只写一句话，这些底层的 JavaScript 引擎、渲染进程、GPU 进程都要跟着一起跑。

10MB 以内的编辑器通常走的是原生应用路线。以我在 macOS 上用的这类开源轻量编辑器为例，它的主体框架由原生语言编写，预览区域调用系统自带的 WebView，而不是把整个 Chromium 塞进安装包。系统 WebView 的好处是系统本来就有，不用重复打包；坏处是如果你的代码里调用了 WebView 不支持的新特性，就得做降级处理。所以这类编辑器如果要支持复杂公式和图表，必须在 Markdown 解析和渲染层做得足够聪明。

还有一个容易被忽略的认知：编辑器体积小不等于渲染能力差。公式渲染本质上是把 LaTeX 语法交给 KaTeX 或 MathJax 这样的库去解析，图表渲染是把 Mermaid 语法交给对应解析器。这些库本身都是纯前端脚本，体积并不大，完全可以打包进一个几 MB 的应用里。真正体积大的，从来都是那些通用 UI 框架、语言服务器、调试器、插件管理基础设施。

1.3 编辑器内置公式、图表究竟靠什么实现

拆开看，这类轻量 Markdown 编辑器内部至少有四层协作：

• Markdown 解析层：负责把.md文本解析成文档结构，通常基于 CommonMark 规范并兼容 GitHub Flavored Markdown 的扩展语法，比如任务列表、删除线、表格。
• 公式渲染层：识别$...$和$$...$$标记，把内部表达式交给 KaTeX 或 MathJax 渲染成带样式的 HTML。KaTeX 的特点是渲染速度快，MathJax 的特点是命令兼容性更好。
• 图表渲染层：识别代码块中mermaid开头的内容，读取后续文本并交给 Mermaid 引擎转换成 SVG。这也是为什么你不需要画图软件，只要会写几行类代码就能画流程图。
• 检索索引层：编辑器在打开文件夹时会扫描所有.md文件，建立一张“文件名 + 文件路径 + 内容摘要”的轻量索引，搜索时在这个索引里做全文匹配。

这套架构本身并不神秘，真正难的是把四层融合在一个界面里，而且保持启动速度快、内存占用低。具体到用户体验上，就是我能边输入 LaTeX 公式边看到结果，能在一篇上千行的笔记里秒搜关键词，整个过程不需要去插件市场安装任何东西。

2. 拆箱实测：公式、图表、搜索这三把刷子够不够用

2.1 数学公式：从输入 LaTeX 到渲染成型的真实手感

我日常写博客和笔记时会用到不少数学公式，这也是我对编辑器最挑剔的一点。这类编辑器对公式支持的底层方案以 KaTeX 为主，具体体验分三种情况：

• 行内公式：在文本中间输入$E=mc^2$，渲染结果会直接嵌在段落里，不单独占行。
• 块级公式：用$$包裹公式，比如$$\int_{0}^{1} x^2 dx = \frac{1}{3}$$，渲染后会单独成行并居中。
• 复杂环境：矩阵、分段函数、多行对齐等，通过\begin{matrix}、\begin{cases}、\begin{aligned}这类 LaTeX 环境实现。

比如我写矩阵分解笔记时会用$$\mathbf{A} = \mathbf{Q}\boldsymbol{\Lambda}\mathbf{Q}^{-1}$$这样的写法，在编辑器中它显示为源文本，切换到预览模式后就会变成排版好的公式。整个过程是离线的，不联网也能用，这比很多在线 LaTeX 编辑器强在隐私性和稳定性上。

一个小提醒：KaTeX 和 MathJax 的命令集并不完全一致。如果你以前用 Jupyter 或者 Obsidian，习惯了\bm、\text{}这类命令，换到 KaTeX 环境时偶尔会遇到个别命令不识别的问题。常用的解法是换成基础命令，比如用\mathbf{}代替\bm，或者用\mathrm{}代替\text{}。

2.2 画流程图和时序图：Mermaid 语法在编辑器里的实战

公式只是其中一个内置项，图表是更让我惊喜的部分。在代码块里标记成mermaid，内部写graph TD、sequenceDiagram、gantt这类声明式语法，预览区就会直接渲染成矢量图。

举个例子。我最近写一篇关于数据清洗流程的笔记，画了一个很简单的流程：收集数据，然后做缺失值处理，再做异常值检测，接着做特征工程，最后建模。对应的 Mermaid 语法核心就是节点定义和箭头连接，差不多三行就能搞定。写完切到预览模式，一张清晰的流程图就出来了，不用去画图软件拖框和连线。

除了基础流程图，时序图和甘特图也比较常用。比如描述一次接口调用的流程，用sequenceDiagram可以画出调用方、服务端、数据库之间的消息传递；项目排期用gantt可以画出任务时间轴。这些在过去都要靠专门的画图工具才能完成，现在和 Markdown 正文写在同一个文件里，最大的好处是版本可控：内容变了，语法跟着改，图形自动更新，而不是每次都要重新截图替换图片。

2.3 全文搜索：不只是搜文件名，而是内容也一起检

搜索是这类编辑器的隐藏加分项。很多人在 Markdown 编辑器里找内容，第一反应是“用系统文件搜索”，但这种搜索只能按文件名匹配，旧笔记里写过的某个概念往往找不到。内置搜索会针对目录下所有.md文件做内容检索，输入“傅里叶变换”直接能把三个月前一篇技术笔记里的相关段落找出来。

实测下来，它的搜索是基于“文件名 + 文件内容”的轻量索引，搜索关键词时会高亮命中位置，点结果直接跳转到对应文档。标签功能也值得一提，如果我在文件名或者正文元信息里打了标签，搜索#算法这种关键词会把所有带该标签的文档列出来。对个人知识库来说，文件量在几千个以内时搜索速度基本是即时的，没有卡顿感。

当然，它的搜索还是比较朴素的全文匹配，不支持复杂的布尔检索和正则表达式。真要用到这些高级能力，说明已经进入知识库管理阶段，那就应该考虑功能更重的笔记工具了。不过单就“找到一段话”这个刚需来说，它已经做得足够好。

3. 我用它完整写完一篇技术笔记的实操复盘

3.1 安装、首屏和基本设置

说回实际流程。这类编辑器安装包普遍就在 5MB 左右，从下载到打开几乎没有等待感，这在动辄上百 MB 的编辑器阵营里算是异类。首次启动后界面很干净：左侧是文件目录树，中间是编辑区，右侧可以展开预览面板。默认状态是源码模式和预览模式并存，也可以一键切到纯写作模式或者只读预览模式。

基本设置里我建议做三件事：

1. 开启自动保存，避免忘记 Ctrl/Cmd + S 导致内容丢失。
2. 把字体换成等宽字体，写代码或公式时对齐更舒服。
3. 开启目录大纲，长文档的标题结构会显示在侧边栏，方便快速跳转。

这三件事设置完，基本就不用再动任何配置了，这就是“内置”带来的省心。

3.2 写一篇带公式和流程图的笔记：操作步骤回顾

为了测试它到底能不能作为主力写作工具，我用它重写了一篇“矩阵特征值分解”的复习笔记。流程大致是：

• 先新建一个项目目录，把相关.md文件都放进去；
• 在开头写文档标题和一段摘要，顺手在正文中放了一个行内公式；
• 插入一个块级公式，展示特征值分解的表达式；
• 在“算法流程”一节用 Mermaid 语法画了一张流程图，描述特征值分解在 PCA 降维中的位置；
• 最后在文末加了几个标签，方便后续检索。

全程没有打开任何一个插件商店，也没有写任何一行 CSS。切到预览模式后，公式显示正确、流程图渲染清晰、标题层级完整，整体观感和我以前用 Typora 时的差别已经很小。认真体会下来，唯一的差异是主题数量较少，默认主题之外的风格需要手动从社区导入。

3.3 导出 PDF 或 HTML 时的方法与坑

写完笔记后，常见需求是导出分享。这类轻量编辑器一般提供两种导出路径：

第一种是直接打印预览页为 PDF。优点是操作快，缺点是 PDF 的分页效果依赖打印样式，长文档偶尔会出现表格被切断、公式跨页显示不美观的问题。我的习惯是先在预览中缩小页面宽度，再通过打印窗口手动调整缩放比例。

第二种是导出或拷贝成 HTML，拿到浏览器或博客平台发布。这种做法兼容性最好，公式已经渲染成 HTML/CSS，图表已经是 SVG，粘贴到支持富文本的编辑器里基本不用二次处理。

如果你需要更高级的排版，比如自定义纸张大小、页眉页脚、交叉引用，那就得借助 Pandoc 这类外部转换工具了。在这类轻量编辑器里通常不支持直接安装 Pandoc 插件，但你可以把.md文件用命令行交给 Pandoc 处理，编辑器只负责“产出内容”这一层，排版交给更专业的工具，各司其职其实更清爽。

4. 和 Typora、VS Code、Obsidian 这类选手掰扯一下差距

4.1 一张表看清局面

为了不显得我是在“无脑吹”，我拿它和市面上主流的三个选择做了个横向对比。

这张表能说明一个核心差异：在“打开即用、内置公式图表”这件事上，它和 Typora、Obsidian 是同一梯队的，区别只在体积、平台和付费策略。

4.2 不同使用场景该选谁

如果你只是想快速写一篇带公式的技术笔记或学生作业，选它最省心；如果你已经用 Obsidian 搭起了双链知识库，那就没必要换，Obsidian 的深度管理功能确实是轻量编辑器给不了的；如果你日常还要写代码，VS Code 仍然是更合理的主力，Markdown 只是它的“副业”；如果你愿意付费且需要跨 Android、iOS、Windows、macOS 一套统一的笔记方案，Typora 的移动端路径和整体一致性也有自己的优势。

必须承认，插件化本身不是缺点。对开发者来说，插件是“按需组合”，是不被大一统软件绑架的自由。但对普通用户而言，“插件”往往意味着选择困难和维护成本。选择轻量内置方案的人，买的就是“不需要做选择题”的自由。这种产品取舍没有绝对对错，只看你更想用编辑器，还是更想折腾编辑器。

5. 讲点没人爱听的坏话：这套方案的边界和避坑清单

5.1 我在实践中踩过的几个坑

先说最现实的问题：平台。这类轻量编辑器并非全平台统一。以这类 macOS 上比较常见的开源编辑器为例，Windows 或 Linux 上要么没有官方版本，要么得通过其他方式运行。如果你需要在公司 Windows 电脑和个人 Mac 之间无缝切换，选型前一定要先确认编辑器有没有对应的跨平台版本。

其次是 Mermaid 图表的高级语法兼容性问题。基础流程图、时序图、甘特图没问题，但类图、状态图、饼图这类不太常用的图表类型，在新版 Mermaid 里的语法变化较大，轻量编辑器内置的 Mermaid 库如果没跟上，就会出现“本地渲染失败，但拿到在线编辑器却正常”的尴尬。解决方案是在正文里标注使用的 Mermaid 版本，或者先查一下编辑器内置版本对应支持的语法范围。

第三个坑是公式环境的限制。我在前面提到过，KaTeX 追求渲染速度，对部分 LaTeX 宏包和自定义命令支持有限。比如\boldsymbol系列的个别变体、\begin{empheq}这种扩展环境就不一定支持。遇到以后不要死磕，直接等价替换成基础命令即可。

第四个坑在搜索设计上。它的全文搜索是基于文件名和正文内容的简单匹配，不区分复杂条件。文档变多以后，如果不主动给标题和标签做规范命名，搜索结果会越来越难用。我的习惯是在每篇笔记的元信息区写上发布日期和关键词标签，例如在文章开头写tags: [算法, 线代]，这样搜索时能大幅提高命中率。

5.2 别指望它干这几件事

轻量编辑器最大的美德是克制，最大的缺点也是克制。碰到下面这些需求，我建议果断换工具，不要为难它：

• 多人实时协同编辑。它不是在线文档，没有基于 WebSocket 的多人同步能力。
• 复杂文档排版。学术论文、毕业论文的页眉、脚注、目录定制，需要 LaTeX 或 Word 这种重工具。
• 大型知识库的深度组织。笔记超过几千篇、需要探索双链关系和图谱时，Obsidian 或思源笔记这类工具更合适。
• 复杂自动化。比如批量处理多个文件的元数据、自动生成 API 文档，它没有脚本扩展能力。

6. 写到最后：我对这类“小而全”工具的真实看法

要我把话说得更直白一点：如果你以前一直用着大软件、插件堆里活下来的 Markdown 工作流，换了这种不到 10MB 的编辑器后，第一周会觉得“这也太素了”；但用满一个月，大概率会产生依赖感。因为写作时真正重要的永远是内容本身，而不是调试预览主题、更新插件兼容性、纠结快捷键冲突。

我现在的工作流已经变成：用轻量编辑器写一切 Markdown 内容，包括技术笔记、博客初稿、合同沟通摘要，再把每一个项目目录绑定到一个 Git 仓库或网盘同步目录，实现低成本的多设备延续。需要出 PDF 时用打印功能或 Pandoc 兜底；需要长期维护的知识库，再单独沉淀到 Obsidian 里。这一套拆下来的感觉是，工具服务内容，而不是内容适应工具。

最后分享一个小技巧：如果你也决定长期用这类编辑器，建议把“模板片段”做成标准 Markdown 文件存到固定目录里，比如“读书笔记模板.md”“技术复盘模板.md”，每次新建文档时直接复制。因为编辑器不提供复杂的模板变量和自动化脚本，但通过复制目录文件这种原始方式，反而比插件模板更稳定、更可控。