你有没有遇到过这种情况——为了一个 Markdown 编辑器装了一堆插件配了一套主题最后发现真正写正文的时间还没配置时间多。我前阵子清理电脑把原来那个重得离谱的编辑器全部卸了顺手下载了一个不到 10MB 的免费 Markdown 编辑器。本来是想着临时顶一下没想到连续用了两个多月公式、图表、全文搜索全都内置一个插件都没装。这篇文章我就把这个轻量编辑器的设计思路、实操过程、以及我踩过的坑原原本本整理出来。我把它称为轻量编辑器。它解决的是一个很实在的痛Markdown 编辑器的核心任务是把纯文本编辑体验做好但市面上很多工具越做越重把大量精力耗在插件生态上。如果你只是要写文档、记笔记、写博客选一个公式图表搜索全内置的工具会省心非常多。1. 整体设计与核心思路拆解1.1 为什么会出现插件堆叠的怪圈前几年我一度很迷恋万物皆可插件的编辑器看到什么功能少了第一反应就是去搜插件。但插件装多了以后问题接踵而来插件之间版本冲突升级编辑器导致某个插件失效一个冷门插件作者不维护了功能直接荒废。最夸张的时候我的 Markdown 工作环境里塞了二十多个插件光是维护它们就够写一篇文章了。后来我复盘了一下自己真正的高频操作写 Markdown插入数学公式画流程图按关键词找历史笔记导出 PDF 或 HTML。发现这些需求其实非常标准完全可以用内置功能覆盖。与其靠一堆插件拼凑不如找一个把高频能力做进核心的编辑器。这就像手机预装电话和短信是合理的预装三十个莫名其妙的应用才是灾难。这个不到 10MB的编辑器恰好走的就是这条路。它的应用体积小是因为不背一个庞大的插件市场也不内置一堆你可能永远不会用的模块。它把公式解析、图表渲染、全文索引都编译进了主程序打开就用不需要任何联网下载或二次配置。1.2 内置和插件在底层逻辑上的区别插件化方案的价值是灵活想装什么装什么缺点也很明显每多一个插件就多一层依赖等于在编辑器外面再搭了一套小生态。内置方案正好反过来功能是产品团队或者核心开发者自己维护的跟着主版本一起发版兼容性测试是统一的不会出现编辑器升了级公式插件却还停在旧版本的情况。从性能角度看内置功能更占优势。插件通常跑在外部脚本或独立进程里每次调用都有额外开销内置功能是同一套渲染管线数据在内存里走一遍就出结果。我实测下来同样的 Mermaid 流程图在旧编辑器的插件模式下要等一两秒在这款轻量编辑器里几乎是输入完成就渲染手感差距很明显。当然内置方案也有天花板它没法覆盖长尾需求。比如你非要一个PDF 内嵌字体自定义或一键发布到某个特定平台的功能那就得看编辑器本身有没有。所以选型的时候要想清楚你需要的是一把顺手的小刀还是一个什么都能挂的瑞士军刀底座。1.3 它到底把哪些能力放进了内核就以我用的这个版本为例它内置了几块核心能力公式渲染、Mermaid 图表、全文搜索、多格式导出、主题切换。具体解释一下能力插件化编辑器常见做法全内置轻量编辑器做法公式支持安装 KaTeX 或 MathJax 插件内置 LaTeX 公式解析图表支持安装 Mermaid 插件或在外部工具画图内置 Mermaid 渲染引擎全文搜索依赖文件索引插件或系统搜索内置本地索引与搜索框PDF/HTML 导出额外装导出插件或靠 Pandoc内置常见格式导出体积与安装安装包通常百兆起步应用本体不到 10MB这组对比不是我拍脑袋写的是我自己折腾过一轮之后总结出来的。尤其搜索这一点很多编辑器默认只能搜当前打开的文件要找历史笔记必须靠系统文件搜索体验非常割裂。这个轻量编辑器把多文件全文搜索放在最显眼的工具栏里打开文件夹就能搜这一点在插件化工具里通常要额外配一个专用插件。2. 公式、图表与搜索能力实测2.1 公式从行内公式到块级公式再到自动编号我写技术笔记时最依赖的是公式功能。以前用某个编辑器写$Emc^2$这种行内公式都要先确认有没有装对应的公式扩展没装就直接显示成源代码。这个轻量编辑器拿到手之后第一件事就是打开一篇老笔记把里头那堆公式原样粘进去结果全部正常渲染。它支持常见的 LaTeX 风格语法行内公式用单个美元符号包起来独立成段的公式用两个美元符号。比如$a^2b^2c^2$渲染出来是很标准的行内数学公式。块级公式写法也直观把公式单独放一段前后各加两个美元符号例如$$\int_0^1 x^2 dx$$编辑器会把它居中显示并加大字号。除了基础公式以外它还内置公式自动编号。在设置里打开自动编号后每一个块级公式右侧会生成(1)、(2)这种编号特别适合写论文初稿或者整理题库。我经常用的多行对齐环境像aligned、cases、matrix也都能渲染不需要额外引入宏包这对轻量工具来说已经非常够用。有一点要注意行内公式里的下划线偶尔会和 Markdown 的斜体语法打架。比如写$x_i$如果解析器不够聪明_i_会被当成斜体标记。我遇到这种情况会直接改成$x\_i$来转义。还有所有公式符号必须用英文半角中文全角美元符和全角括号经常会直接让渲染失败。2.2 图表文本画图的魅力和边界图表功能是这款编辑器另一个让我意外的地方。它内置了 Mermaid 渲染支持流程图、时序图、类图、状态图、饼图、甘特图等常用类型。我不需要额外安装绘图软件也不用把图片导来导去直接在文档里写一段描述性的文本预览区就自动画好了。举一个很简单的例子写流程图时输入类似graph TD; A[开始] -- B{判断}; B --|是| C[继续]; B --|否| D[结束];这样的文本编辑器就会把它渲染成一个从上到下的流程图。因为图表本质上是字符内容会被存进.md文件里用 Git 管理时能清楚地看到每一步改动这一点比截图汇报好用太多了。时序图、甘特图也是同样的套路。写排期计划的时候我直接用一个内置的甘特图语法把任务和时间段列出来预览区就会生成进度条一样的图表非常直观。Mermaid 语法细节比较多但常用结构并不复杂学一遍就能记住。我以前总觉得画图必须打开 Visio 或者 draw.io用过这种文本画图之后再也不想回去折腾鼠标连线。不过它也不是万能的。它对 Mermaid 版本的支持可能固定在某个版本如果你从网上复制了最新语法偶尔会遇到语法解析失败的提示。这种情况我会去 Mermaid 官方文档对照一下当前支持的语法版本改成兼容写法就好了。还有图表块别塞进有序列表或者嵌套引用里缩进一旦乱了渲染很可能直接失效。2.3 全文搜索不是 CtrlF而是整个文档库搜索是我最后想重点夸的功能。以前我对 Markdown 编辑器的搜索功能要求很低能搜当前文档就行跨文件搜索直接用文件管理器。但这个编辑器打开文件夹之后右上角的搜索框可以直接对目录下所有文档做全文检索结果按文件分组展示点一下就能跳转到对应行。我目前的笔记积累了一千多份 Markdown 文件很多都是几年前的读书笔记、项目记录和会议纪要。以前靠记忆翻文件名经常想不起来那个讲数据库索引性能的笔记叫什么名字现在直接在搜索框里输入索引 性能或者B 树结果立刻出来。它还支持正则表达式搜索比如我想找所有包含复杂度但排除时间复杂度的文档可以自己写一条简单正则非常灵活。搜索功能做得好不好很大程度取决于索引策略。这个编辑器启动时会扫描当前文件夹建立一次轻量索引之后的搜索都在本地完成速度很快而且不需要联网也不会把文件内容上传到任何地方。如果你是本地优先的笔记用户这一点应该会很安心。2.4 导出与发布写作最终总要落到分享上。这个编辑器内置了 PDF、HTML、图片和常见的 Markdown 导出方式。我写博客的时候最常用的操作是导出 HTML然后复制到博客后台排版基本不用大改。公式和 Mermaid 图都会在导出时被转换成图片或者 SVG直接嵌入到 HTML 里阅读端不需要装任何公式插件。如果只是给别人看内容导出 PDF 会更稳妥。它能保留主题样式代码块、表格、公式的排版都比较干净。我不太习惯每次都折腾 Pandoc 转 Word但如果你确实需要 Word 格式先导出 HTML 再在 Word 里打开也算一个应急方案。我自己的日常工作流是Markdown 文件负责写作和版本管理导出 PDF 用来发给同事或客户导出 HTML 用来发在线博客原文件则按日期归档到本地文件夹里。这个编辑器基本一条龙覆盖。3. 实操过程用这个轻量编辑器写一篇技术笔记3.1 下载、安装与首次启动这个流程简单到让人怀疑。下载到的安装包不到 10MB解压之后是一个可执行文件双击就能跑起来不需要管理员权限也不会在系统里装一堆后台服务。我第一次启动的时候界面是干净的三栏布局左侧文件树中间编辑区右侧预览区工具栏上直接放着搜索和导出按钮。首次启动建议先做三件事第一在设置里打开自动保存这样再也不用担心断电丢稿第二把默认主题调成你看着舒服的那一个白天写作用亮色晚上写代码笔记用暗色第三把默认的编辑模式从分屏预览改成同步滚动这样长文档滚动时编辑区跳到哪预览区就跟着显示哪感官上很流畅。如果你也习惯完全无干扰的写作可以打开专注模式它会把所有面板收起来只保留正在写的段落类似沉浸写作的感觉。这个功能虽然不起眼但真的能提升效率。3.2 写一篇包含公式和流程图的文档来一个实际案例。我准备写一篇《二分查找的时间复杂度推导》的笔记会在文档里同时用到公式和流程图。第一步新建一个.md文件写标题和正文。开头先写“二分查找每次把待查找区间折半因此递推式为”然后换一行写块级公式$$T(n) T(n/2) O(1)$$这一段公式会被居中渲染看起来非常清楚。接下来我用graph TD描述二分查找的递归树结构输入一段文本预览区就直接画出一棵二叉树形状的示意图总共三层节点一目了然。这么写完保存之后整个文档是纯文本公式源码和图表源码都能被搜到。以后我想找“二分查找”相关内容直接搜索关键词标题和正文、公式、图表描述都会一起参与匹配比我之前靠截图存知识的方式强太多。3.3 用全文搜索快速定位旧笔记写完新笔记之后我给它打了几条标签二分查找、复杂度、算法。过了两周我要写另一篇关于排序的文章想找一下之前二叉搜索树相关的笔记作为参考。文件名早就忘了唯一记得文档里提到过“递归树”和“复杂度”。我直接在搜索框里输入“递归树 复杂度”结果列表里第一条就是那篇《二分查找的时间复杂度推导》点击之后自动跳转到包含关键词的段落全程不到两秒。这种体验在之前那个插件化编辑器里是不可想象的因为那时候跨文件搜索质量完全取决于我有没有装对搜索插件。如果你管理的是一个几百乃至几千篇文件的目录建议一开始就把所有 Markdown 笔记放到同一个根目录下再用子文件夹分门别类这样全文搜索的效果最好。搜索范围太散的话再好的工具也白搭。3.4 导出与把编辑器接进写作流程这篇笔记写完我需要把它分享给团队里的同事。团队里不是每个人都装了 Markdown 工具直接发.md文件他们会很痛苦。我选择导出 PDF在导出设置里选好页边距和字体大小几秒钟就生成了一份排版干净的 PDF。如果是发博客我会导出 HTML然后把 HTML 贴进博客后台。因为在预览区里公式和图表已经被处理成可展示的元素所以导出的 HTML 是所见即所得的状态不需要再额外上传图片。这个工作流让我彻底戒掉了先截一堆图再拼文章的坏习惯。对于追求极致效率的人我建议把 Markdown 源文件也纳入版本管理每次改完提交一次。因为图表是用文本描述的公式也是文本Git 的 diff 能精准显示每一次修改这在多轮文档评审中特别有用。4. 常见问题与排查技巧实录用了一个多月我也踩了一些坑这里整理成一份速查表帮大家少走弯路。现象可能原因解决办法行内公式显示成源代码美元符号写成了全角或公式里有未转义的下划线改成英文半角$下划线用\_块级公式没有自动编号设置里没打开自动编号开关去渲染设置里打开公式编号Mermaid 图表不渲染语法版本不兼容或缩进混乱对照官方文档改成当前支持的语法检查代码块缩进搜索不到中文关键词文件编码不是 UTF-8把文件统一保存为 UTF-8 编码搜索结果数量不对搜索的是正则表达式特殊字符被解释掉了切换到普通搜索模式或者反斜杠转义导出 PDF 后公式变形字体没嵌入 PDF在导出设置里勾选嵌入字体或者换内置字体4.1 公式不显示或显示乱码我遇到的第一个坑是全角符号。中文输入法环境下很容易把$$输成编辑器当然不认识。这个没什么好讲的切到英文输入法再写公式即可。第二个坑是行内公式里同时出现上下标和下划线时会被 Markdown 解析器误判。正确的做法是给下划线加反斜杠比如$a\_i$。还有如果公式里有比较长的分数建议直接改用块级公式展示行内公式的尺寸本来就小再嵌套复杂的分式会显得很拥挤阅读体验也不好。如果你发现公式和文字不在同一水平线上大概率是行高设置和公式字体尺寸不匹配。可以在编辑器设置里把行高调大一点或者在公式里临时加一个\displaystyle声明让行内公式按块级公式的样式渲染对齐问题会缓解很多。4.2 图表代码没有生效Mermaid 代码最忌讳的是被 Markdown 解释器“吃掉”。如果你把图表代码直接写在文档里不加代码块或者没有按编辑器要求的图表语法来写编辑器可能不会识别。我的经验是新建图表时先确认当前编辑器支持通过快捷键插入图表模板它会自动生成一个完整的示例我只需要替换里面的节点内容。这比从头手写语法要可靠得多。如果是复制别人文章里的 Mermaid 代码注意它可能用于不同版本的渲染器遇到报错就删掉可疑语法改成最基础的graph TD结构再逐步加内容。缩进问题也很常见。比如图表代码不小心被嵌进了列表项里多出的缩进会让 Mermaid 解析器认为整个块是一个子节点结果什么都不显示。遇到这种情况把图表块移到列表外或者取消缩进问题立竿见影。4.3 搜索不到内容先查编码和范围搜索失灵的时候我会按顺序排查三件事一是当前搜索范围是不是整个文件夹如果只是“当前文件”那跨文档内容自然搜不到二是文件编码统一用 UTF-8 保存最稳妥如果用系统默认的 GBK 或者其他本地编码中文关键词会被索引成乱码三是搜索语法如果开了正则像、(、)这些字符会被当成特殊符号这个时候可以关掉正则改用纯文本匹配。如果目录里的文件特别多可能索引没有刷新。我来回测试的解决办法是重启编辑器或者手动重建索引。有的编辑器需要右键文件夹选择“重新建立搜索索引”。如果你也遇到“明明有这个词却搜不到”的诡异情况先试试强制重建大部分都能解决。4.4 轻量带来的隐性问题体积小意味着功能聚焦但也意味着配置项可能没有那些重量级工具多。比如有些重编辑器可以给不同语言设置不同的代码高亮主题这款轻量编辑器目前只提供全局主题。如果你需要非常细致的自定义可能在设置里翻半天都找不到入口。便携版还有一个容易踩的坑可执行文件放在 U 盘或临时目录笔记文件的默认存储路径却在系统用户目录下。卸载或者删除程序目录时别以为笔记会跟着一起消失其实它们可能在另一个地方。建议一开始就在设置里手动指定笔记库路径放到你的数据盘或者同步目录下这样重装系统也不会丢。另外这类轻量工具通常更新节奏不快遇到 Bug 时不要指望靠插件绕过。我的习惯是重要文档在导出 PDF 或 HTML 后额外备份一份纯文本.md文件这样无论编辑器发生什么问题源文件始终是安全的。5. 个人使用体会和适合场景用了这段时间我对“轻量”有了新的理解轻量化不是功能少而是把功能做到刚好够用且好用。尤其是公式、图表、搜索这三个能力全部内置之后我打开编辑器就能直接投入工作不需要为环境维护分心。对一个以写作为中心的人来说这种“打开即写”的流畅感比一百个可有可无的插件更有价值。如果你也是学生、研究者、技术写作者或者博客博主主要诉求是写 Markdown、排公式、画图、找笔记那这类不到 10MB 的编辑器完全够用而且省心。如果你重度依赖第三方插件生态比如必须在编辑器里跑一套复杂任务管理插件那它可能不适合你。最后分享一个我的小习惯不管用哪个 Markdown 编辑器我都会把源文件按照“年份/项目名/日期-标题.md”的结构归档。编辑器可以换来换去但纯文本的源文件永远是我的第一资产。这也是我越来越偏爱轻量工具的原因——它不绑架我的数据也不绑架我的工作流。 不到10MB的Markdown编辑器：公式、图表、搜索全内置，告别插件堆砌
你有没有遇到过这种情况——为了一个 Markdown 编辑器装了一堆插件配了一套主题最后发现真正写正文的时间还没配置时间多。我前阵子清理电脑把原来那个重得离谱的编辑器全部卸了顺手下载了一个不到 10MB 的免费 Markdown 编辑器。本来是想着临时顶一下没想到连续用了两个多月公式、图表、全文搜索全都内置一个插件都没装。这篇文章我就把这个轻量编辑器的设计思路、实操过程、以及我踩过的坑原原本本整理出来。我把它称为轻量编辑器。它解决的是一个很实在的痛Markdown 编辑器的核心任务是把纯文本编辑体验做好但市面上很多工具越做越重把大量精力耗在插件生态上。如果你只是要写文档、记笔记、写博客选一个公式图表搜索全内置的工具会省心非常多。1. 整体设计与核心思路拆解1.1 为什么会出现插件堆叠的怪圈前几年我一度很迷恋万物皆可插件的编辑器看到什么功能少了第一反应就是去搜插件。但插件装多了以后问题接踵而来插件之间版本冲突升级编辑器导致某个插件失效一个冷门插件作者不维护了功能直接荒废。最夸张的时候我的 Markdown 工作环境里塞了二十多个插件光是维护它们就够写一篇文章了。后来我复盘了一下自己真正的高频操作写 Markdown插入数学公式画流程图按关键词找历史笔记导出 PDF 或 HTML。发现这些需求其实非常标准完全可以用内置功能覆盖。与其靠一堆插件拼凑不如找一个把高频能力做进核心的编辑器。这就像手机预装电话和短信是合理的预装三十个莫名其妙的应用才是灾难。这个不到 10MB的编辑器恰好走的就是这条路。它的应用体积小是因为不背一个庞大的插件市场也不内置一堆你可能永远不会用的模块。它把公式解析、图表渲染、全文索引都编译进了主程序打开就用不需要任何联网下载或二次配置。1.2 内置和插件在底层逻辑上的区别插件化方案的价值是灵活想装什么装什么缺点也很明显每多一个插件就多一层依赖等于在编辑器外面再搭了一套小生态。内置方案正好反过来功能是产品团队或者核心开发者自己维护的跟着主版本一起发版兼容性测试是统一的不会出现编辑器升了级公式插件却还停在旧版本的情况。从性能角度看内置功能更占优势。插件通常跑在外部脚本或独立进程里每次调用都有额外开销内置功能是同一套渲染管线数据在内存里走一遍就出结果。我实测下来同样的 Mermaid 流程图在旧编辑器的插件模式下要等一两秒在这款轻量编辑器里几乎是输入完成就渲染手感差距很明显。当然内置方案也有天花板它没法覆盖长尾需求。比如你非要一个PDF 内嵌字体自定义或一键发布到某个特定平台的功能那就得看编辑器本身有没有。所以选型的时候要想清楚你需要的是一把顺手的小刀还是一个什么都能挂的瑞士军刀底座。1.3 它到底把哪些能力放进了内核就以我用的这个版本为例它内置了几块核心能力公式渲染、Mermaid 图表、全文搜索、多格式导出、主题切换。具体解释一下能力插件化编辑器常见做法全内置轻量编辑器做法公式支持安装 KaTeX 或 MathJax 插件内置 LaTeX 公式解析图表支持安装 Mermaid 插件或在外部工具画图内置 Mermaid 渲染引擎全文搜索依赖文件索引插件或系统搜索内置本地索引与搜索框PDF/HTML 导出额外装导出插件或靠 Pandoc内置常见格式导出体积与安装安装包通常百兆起步应用本体不到 10MB这组对比不是我拍脑袋写的是我自己折腾过一轮之后总结出来的。尤其搜索这一点很多编辑器默认只能搜当前打开的文件要找历史笔记必须靠系统文件搜索体验非常割裂。这个轻量编辑器把多文件全文搜索放在最显眼的工具栏里打开文件夹就能搜这一点在插件化工具里通常要额外配一个专用插件。2. 公式、图表与搜索能力实测2.1 公式从行内公式到块级公式再到自动编号我写技术笔记时最依赖的是公式功能。以前用某个编辑器写$Emc^2$这种行内公式都要先确认有没有装对应的公式扩展没装就直接显示成源代码。这个轻量编辑器拿到手之后第一件事就是打开一篇老笔记把里头那堆公式原样粘进去结果全部正常渲染。它支持常见的 LaTeX 风格语法行内公式用单个美元符号包起来独立成段的公式用两个美元符号。比如$a^2b^2c^2$渲染出来是很标准的行内数学公式。块级公式写法也直观把公式单独放一段前后各加两个美元符号例如$$\int_0^1 x^2 dx$$编辑器会把它居中显示并加大字号。除了基础公式以外它还内置公式自动编号。在设置里打开自动编号后每一个块级公式右侧会生成(1)、(2)这种编号特别适合写论文初稿或者整理题库。我经常用的多行对齐环境像aligned、cases、matrix也都能渲染不需要额外引入宏包这对轻量工具来说已经非常够用。有一点要注意行内公式里的下划线偶尔会和 Markdown 的斜体语法打架。比如写$x_i$如果解析器不够聪明_i_会被当成斜体标记。我遇到这种情况会直接改成$x\_i$来转义。还有所有公式符号必须用英文半角中文全角美元符和全角括号经常会直接让渲染失败。2.2 图表文本画图的魅力和边界图表功能是这款编辑器另一个让我意外的地方。它内置了 Mermaid 渲染支持流程图、时序图、类图、状态图、饼图、甘特图等常用类型。我不需要额外安装绘图软件也不用把图片导来导去直接在文档里写一段描述性的文本预览区就自动画好了。举一个很简单的例子写流程图时输入类似graph TD; A[开始] -- B{判断}; B --|是| C[继续]; B --|否| D[结束];这样的文本编辑器就会把它渲染成一个从上到下的流程图。因为图表本质上是字符内容会被存进.md文件里用 Git 管理时能清楚地看到每一步改动这一点比截图汇报好用太多了。时序图、甘特图也是同样的套路。写排期计划的时候我直接用一个内置的甘特图语法把任务和时间段列出来预览区就会生成进度条一样的图表非常直观。Mermaid 语法细节比较多但常用结构并不复杂学一遍就能记住。我以前总觉得画图必须打开 Visio 或者 draw.io用过这种文本画图之后再也不想回去折腾鼠标连线。不过它也不是万能的。它对 Mermaid 版本的支持可能固定在某个版本如果你从网上复制了最新语法偶尔会遇到语法解析失败的提示。这种情况我会去 Mermaid 官方文档对照一下当前支持的语法版本改成兼容写法就好了。还有图表块别塞进有序列表或者嵌套引用里缩进一旦乱了渲染很可能直接失效。2.3 全文搜索不是 CtrlF而是整个文档库搜索是我最后想重点夸的功能。以前我对 Markdown 编辑器的搜索功能要求很低能搜当前文档就行跨文件搜索直接用文件管理器。但这个编辑器打开文件夹之后右上角的搜索框可以直接对目录下所有文档做全文检索结果按文件分组展示点一下就能跳转到对应行。我目前的笔记积累了一千多份 Markdown 文件很多都是几年前的读书笔记、项目记录和会议纪要。以前靠记忆翻文件名经常想不起来那个讲数据库索引性能的笔记叫什么名字现在直接在搜索框里输入索引 性能或者B 树结果立刻出来。它还支持正则表达式搜索比如我想找所有包含复杂度但排除时间复杂度的文档可以自己写一条简单正则非常灵活。搜索功能做得好不好很大程度取决于索引策略。这个编辑器启动时会扫描当前文件夹建立一次轻量索引之后的搜索都在本地完成速度很快而且不需要联网也不会把文件内容上传到任何地方。如果你是本地优先的笔记用户这一点应该会很安心。2.4 导出与发布写作最终总要落到分享上。这个编辑器内置了 PDF、HTML、图片和常见的 Markdown 导出方式。我写博客的时候最常用的操作是导出 HTML然后复制到博客后台排版基本不用大改。公式和 Mermaid 图都会在导出时被转换成图片或者 SVG直接嵌入到 HTML 里阅读端不需要装任何公式插件。如果只是给别人看内容导出 PDF 会更稳妥。它能保留主题样式代码块、表格、公式的排版都比较干净。我不太习惯每次都折腾 Pandoc 转 Word但如果你确实需要 Word 格式先导出 HTML 再在 Word 里打开也算一个应急方案。我自己的日常工作流是Markdown 文件负责写作和版本管理导出 PDF 用来发给同事或客户导出 HTML 用来发在线博客原文件则按日期归档到本地文件夹里。这个编辑器基本一条龙覆盖。3. 实操过程用这个轻量编辑器写一篇技术笔记3.1 下载、安装与首次启动这个流程简单到让人怀疑。下载到的安装包不到 10MB解压之后是一个可执行文件双击就能跑起来不需要管理员权限也不会在系统里装一堆后台服务。我第一次启动的时候界面是干净的三栏布局左侧文件树中间编辑区右侧预览区工具栏上直接放着搜索和导出按钮。首次启动建议先做三件事第一在设置里打开自动保存这样再也不用担心断电丢稿第二把默认主题调成你看着舒服的那一个白天写作用亮色晚上写代码笔记用暗色第三把默认的编辑模式从分屏预览改成同步滚动这样长文档滚动时编辑区跳到哪预览区就跟着显示哪感官上很流畅。如果你也习惯完全无干扰的写作可以打开专注模式它会把所有面板收起来只保留正在写的段落类似沉浸写作的感觉。这个功能虽然不起眼但真的能提升效率。3.2 写一篇包含公式和流程图的文档来一个实际案例。我准备写一篇《二分查找的时间复杂度推导》的笔记会在文档里同时用到公式和流程图。第一步新建一个.md文件写标题和正文。开头先写“二分查找每次把待查找区间折半因此递推式为”然后换一行写块级公式$$T(n) T(n/2) O(1)$$这一段公式会被居中渲染看起来非常清楚。接下来我用graph TD描述二分查找的递归树结构输入一段文本预览区就直接画出一棵二叉树形状的示意图总共三层节点一目了然。这么写完保存之后整个文档是纯文本公式源码和图表源码都能被搜到。以后我想找“二分查找”相关内容直接搜索关键词标题和正文、公式、图表描述都会一起参与匹配比我之前靠截图存知识的方式强太多。3.3 用全文搜索快速定位旧笔记写完新笔记之后我给它打了几条标签二分查找、复杂度、算法。过了两周我要写另一篇关于排序的文章想找一下之前二叉搜索树相关的笔记作为参考。文件名早就忘了唯一记得文档里提到过“递归树”和“复杂度”。我直接在搜索框里输入“递归树 复杂度”结果列表里第一条就是那篇《二分查找的时间复杂度推导》点击之后自动跳转到包含关键词的段落全程不到两秒。这种体验在之前那个插件化编辑器里是不可想象的因为那时候跨文件搜索质量完全取决于我有没有装对搜索插件。如果你管理的是一个几百乃至几千篇文件的目录建议一开始就把所有 Markdown 笔记放到同一个根目录下再用子文件夹分门别类这样全文搜索的效果最好。搜索范围太散的话再好的工具也白搭。3.4 导出与把编辑器接进写作流程这篇笔记写完我需要把它分享给团队里的同事。团队里不是每个人都装了 Markdown 工具直接发.md文件他们会很痛苦。我选择导出 PDF在导出设置里选好页边距和字体大小几秒钟就生成了一份排版干净的 PDF。如果是发博客我会导出 HTML然后把 HTML 贴进博客后台。因为在预览区里公式和图表已经被处理成可展示的元素所以导出的 HTML 是所见即所得的状态不需要再额外上传图片。这个工作流让我彻底戒掉了先截一堆图再拼文章的坏习惯。对于追求极致效率的人我建议把 Markdown 源文件也纳入版本管理每次改完提交一次。因为图表是用文本描述的公式也是文本Git 的 diff 能精准显示每一次修改这在多轮文档评审中特别有用。4. 常见问题与排查技巧实录用了一个多月我也踩了一些坑这里整理成一份速查表帮大家少走弯路。现象可能原因解决办法行内公式显示成源代码美元符号写成了全角或公式里有未转义的下划线改成英文半角$下划线用\_块级公式没有自动编号设置里没打开自动编号开关去渲染设置里打开公式编号Mermaid 图表不渲染语法版本不兼容或缩进混乱对照官方文档改成当前支持的语法检查代码块缩进搜索不到中文关键词文件编码不是 UTF-8把文件统一保存为 UTF-8 编码搜索结果数量不对搜索的是正则表达式特殊字符被解释掉了切换到普通搜索模式或者反斜杠转义导出 PDF 后公式变形字体没嵌入 PDF在导出设置里勾选嵌入字体或者换内置字体4.1 公式不显示或显示乱码我遇到的第一个坑是全角符号。中文输入法环境下很容易把$$输成编辑器当然不认识。这个没什么好讲的切到英文输入法再写公式即可。第二个坑是行内公式里同时出现上下标和下划线时会被 Markdown 解析器误判。正确的做法是给下划线加反斜杠比如$a\_i$。还有如果公式里有比较长的分数建议直接改用块级公式展示行内公式的尺寸本来就小再嵌套复杂的分式会显得很拥挤阅读体验也不好。如果你发现公式和文字不在同一水平线上大概率是行高设置和公式字体尺寸不匹配。可以在编辑器设置里把行高调大一点或者在公式里临时加一个\displaystyle声明让行内公式按块级公式的样式渲染对齐问题会缓解很多。4.2 图表代码没有生效Mermaid 代码最忌讳的是被 Markdown 解释器“吃掉”。如果你把图表代码直接写在文档里不加代码块或者没有按编辑器要求的图表语法来写编辑器可能不会识别。我的经验是新建图表时先确认当前编辑器支持通过快捷键插入图表模板它会自动生成一个完整的示例我只需要替换里面的节点内容。这比从头手写语法要可靠得多。如果是复制别人文章里的 Mermaid 代码注意它可能用于不同版本的渲染器遇到报错就删掉可疑语法改成最基础的graph TD结构再逐步加内容。缩进问题也很常见。比如图表代码不小心被嵌进了列表项里多出的缩进会让 Mermaid 解析器认为整个块是一个子节点结果什么都不显示。遇到这种情况把图表块移到列表外或者取消缩进问题立竿见影。4.3 搜索不到内容先查编码和范围搜索失灵的时候我会按顺序排查三件事一是当前搜索范围是不是整个文件夹如果只是“当前文件”那跨文档内容自然搜不到二是文件编码统一用 UTF-8 保存最稳妥如果用系统默认的 GBK 或者其他本地编码中文关键词会被索引成乱码三是搜索语法如果开了正则像、(、)这些字符会被当成特殊符号这个时候可以关掉正则改用纯文本匹配。如果目录里的文件特别多可能索引没有刷新。我来回测试的解决办法是重启编辑器或者手动重建索引。有的编辑器需要右键文件夹选择“重新建立搜索索引”。如果你也遇到“明明有这个词却搜不到”的诡异情况先试试强制重建大部分都能解决。4.4 轻量带来的隐性问题体积小意味着功能聚焦但也意味着配置项可能没有那些重量级工具多。比如有些重编辑器可以给不同语言设置不同的代码高亮主题这款轻量编辑器目前只提供全局主题。如果你需要非常细致的自定义可能在设置里翻半天都找不到入口。便携版还有一个容易踩的坑可执行文件放在 U 盘或临时目录笔记文件的默认存储路径却在系统用户目录下。卸载或者删除程序目录时别以为笔记会跟着一起消失其实它们可能在另一个地方。建议一开始就在设置里手动指定笔记库路径放到你的数据盘或者同步目录下这样重装系统也不会丢。另外这类轻量工具通常更新节奏不快遇到 Bug 时不要指望靠插件绕过。我的习惯是重要文档在导出 PDF 或 HTML 后额外备份一份纯文本.md文件这样无论编辑器发生什么问题源文件始终是安全的。5. 个人使用体会和适合场景用了这段时间我对“轻量”有了新的理解轻量化不是功能少而是把功能做到刚好够用且好用。尤其是公式、图表、搜索这三个能力全部内置之后我打开编辑器就能直接投入工作不需要为环境维护分心。对一个以写作为中心的人来说这种“打开即写”的流畅感比一百个可有可无的插件更有价值。如果你也是学生、研究者、技术写作者或者博客博主主要诉求是写 Markdown、排公式、画图、找笔记那这类不到 10MB 的编辑器完全够用而且省心。如果你重度依赖第三方插件生态比如必须在编辑器里跑一套复杂任务管理插件那它可能不适合你。最后分享一个我的小习惯不管用哪个 Markdown 编辑器我都会把源文件按照“年份/项目名/日期-标题.md”的结构归档。编辑器可以换来换去但纯文本的源文件永远是我的第一资产。这也是我越来越偏爱轻量工具的原因——它不绑架我的数据也不绑架我的工作流。