如果你也经历过一边嫌 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 为主具体体验分三种情况行内公式在文本中间输入$Emc^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 的编辑器阵营里算是异类。首次启动后界面很干净左侧是文件目录树中间是编辑区右侧可以展开预览面板。默认状态是源码模式和预览模式并存也可以一键切到纯写作模式或者只读预览模式。基本设置里我建议做三件事开启自动保存避免忘记 Ctrl/Cmd S 导致内容丢失。把字体换成等宽字体写代码或公式时对齐更舒服。开启目录大纲长文档的标题结构会显示在侧边栏方便快速跳转。这三件事设置完基本就不用再动任何配置了这就是“内置”带来的省心。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 一张表看清局面为了不显得我是在“无脑吹”我拿它和市面上主流的三个选择做了个横向对比。对比维度本文主角10MB 轻量编辑器TyporaVS Code Markdown 插件Obsidian安装包体积5MB 左右150MB 级别100MB 以上100MB 以上价格免费开源收费免费个人免费公式支持内置 KaTeX内置需插件内置图表支持内置 Mermaid内置需插件内置插件依赖无少重中离线可用是是是是学习成本低低中高中知识库管理深度基础基础中高跨平台看具体产品全平台全平台全平台这张表能说明一个核心差异在“打开即用、内置公式图表”这件事上它和 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”每次新建文档时直接复制。因为编辑器不提供复杂的模板变量和自动化脚本但通过复制目录文件这种原始方式反而比插件模板更稳定、更可控。
