先说个背景我平时写技术文章、项目文档、课程笔记基本都靠 Markdown 打底。早年用 Typora 确实舒服但后来它收费了转去 VS Code 写了一阵子没装插件的时候和记事本差不多装完插件又要配主题、配预览、配同步一个文档编辑器愣是玩成了 IDE。前几天整理 U 盘翻出一个不到 10MB 的绿色版 Markdown 编辑器公式、图表、全文搜索全内置一个插件都不用装。我把它拷到新电脑上用了两天体验意外地顺手。今天就把这个“轻量到极致”的写作方案拆开讲讲适合学生记笔记、博主写稿、程序员写 README以及所有不想折腾工具、打开就想写的人。1. 先说痛点我是怎么被“重编辑器”逼疯的1.1 从 Typora 收费到 VS Code 插件地狱先说 Typora。它的所见即所得排版确实漂亮写 Markdown 的时候基本感觉不到在写标记语言光标一按加粗、标题、表格都实时渲染出来。但后来 Typora 开始收费倒不是说 89 块钱买断多贵而是我始终觉得一个写纯文本的工具付费点应该在于服务、云同步或者协作单纯为了本地渲染就收费总让我不太想掏钱。更关键的是Typora 的安装包并不小加上主题、自定义 CSS整个目录体积会明显膨胀。对于我这种喜欢把写作工具随身带在 U 盘里的人它并不算轻。再说 VS Code。VS Code 写 Markdown 的体验上限很高但下限也很低。刚装完的 VS Code 连 Markdown 预览都要手动开快捷键也没有针对写作优化。想达到 Typora 那种“边写边渲染”的体验至少得装一套 Markdown All in One、Markdown Preview Enhanced、Paste Image 之类的插件。插件一多问题就来了启动速度肉眼可见地变慢快捷键偶尔冲突插件更新后预览样式变了又得花时间调。更要命的是VS Code 默认是面向代码工程的一个工作区里塞了代码、配置、插件缓存写作这件事反而被稀释了。如果你跟我一样只是想把脑子里的话倒进文档里VS Code 的配置成本确实有点高。中间我也试过 Joplin、Obsidian、思源笔记这类“笔记应用”。它们其实更接近知识库带有数据库、同步、插件市场、双链关系图谱功能很强但这也意味着学习成本。为了写一篇周报去学一套双链系统怎么看都不划算。而且它们大多基于 Electron安装包动辄上百 MB启动到能输入文字要等一阵子和我想要的“双击即写”完全是两个方向。1.2 我真正需要的其实是“打开就能写”被这些工具来回折腾之后我把自己的需求重新列了一遍发现其实非常朴素免费最好开源不想为基本功能付费体积小安装包不超过 10MB启动快最好免安装、能放 U 盘支持 Markdown 基础语法标题、加粗、斜体、列表、代码块、表格这些必须有支持数学公式渲染毕竟写技术文章经常会碰到 LaTeX 公式支持流程图、时序图之类的图表至少要有 Mermaid 语法能全文搜索笔记积累到一定量之后搜不到等于白写离线可用不依赖网络导出 PDF 或 HTML 要方便。列完这份清单之后我才意识到很多时候我们并不是“需要”功能而是“被功能绑架”。VS Code 就像一把瑞士军刀什么功能都有但每次拧颗螺丝都得先翻出对应工具头而我要的其实是一把趁手的菜刀切菜直接上手不需要研究刀柄上那排配件怎么用。轻量 Markdown 编辑器能解决的就是这个“打开就能写”的场景。2. 轻量 Markdown 编辑器到底把哪些能力做到了“内置”2.1 公式LaTeX 语法直接渲染不用装任何数学插件数学公式是很多人选 Markdown 编辑器时最容易忽略、但用到时最头疼的功能。如果你只是写普通文档确实用不上可一旦要写带有公式的笔记、论文草稿或者技术方案少了公式支持就等于要另开一个工具。这类轻量编辑器内置的公式方案大多基于 KaTeX 或 MathJax 渲染引擎支持用美元符号包裹 LaTeX 语法。行内公式用单个$比如写$Emc^2$会渲染成行内的 Emc²块级公式用双美元$$会单独占一行并居中。比如常见的积分公式$$ \int_0^\infty e^{-x^2} dx \frac{\sqrt{\pi}}{2} $$矩阵、分段函数、希腊字母、求和符号这些也都能写。我写机器学习笔记的时候最常用到的是矩阵公式$$ \begin{pmatrix} a b \ c d \end{pmatrix} $$编辑器会在输入过程中实时渲染基本不用等离线也能用。为什么能做到这一点原因很简单渲染引擎被打包进了编辑器本体不需要额外安装 MathJax 插件或者联网调用 CDN。很多在线 Markdown 编辑器需要联网才能显示公式就是因为它们把渲染放在云端而本地内置引擎的编辑器断网照常工作隐私性也更好。这里有个细节值得注意公式语法和 Markdown 语法混排时偶尔会有冲突。比如美元符号在普通文本里也偶尔会用到如果你写的是货币金额$100编辑器可能会误判成行内公式。遇到这种情况我一般会在美元符号前加反斜杠转义或者直接改用全角符号“”问题就没了。2.2 图表流程图、时序图、甘特图靠 Mermaid 语法“画”出来图表功能是这类轻量编辑器另一个让我惊喜的地方。以往想在 Markdown 文档里插入流程图要么用 Visio 画完截图贴进来要么用代码画图再导出图片麻烦不说图片还没法跟着文字一起做版本管理。而这几年 Markdown 社区流行起一种“用文本描述图表”的方案名字叫 Mermaid简单说就是你用一段特殊语法描述图的节点和连线编辑器自动帮你渲染成矢量图。比如我想画一个简单的“写文档要不要画图”的判断流程只需要写一段这样的源码flowchart TD A[写文档] -- B{要不要画图?} B -- 要 -- C[Mermaid 语法] B -- 不要 -- D[纯 Markdown] C -- E[自动渲染成图表]编辑器会把它渲染成一个清晰的流程图左边“写文档”指向判断节点然后分叉到“要”和“不要”两条路径。重点是这张图不是图片文件而是一段纯文本。好处非常直接改文字就能改图不涉及拖拽、对齐、导出图片那些操作放到 Git 仓库里别人能直接 diff 出图的改动复制到别的支持 Mermaid 的平台也能原样渲染。除了流程图Mermaid 还支持时序图、状态图、甘特图、饼图等。写项目周报的时候我常画甘特图来排期写接口文档的时候用时序图描述调用关系。内置 Mermaid 的编辑器相当于把画图工具直接塞进了写作环境省去了“切换软件—画图—导出—贴进文档”这一整条链路。需要提醒的是不同编辑器内置的 Mermaid 版本不一样如果一段 Mermaid 语法在这个编辑器里渲染正常换一个编辑器却报错大概率是版本差异导致语法不兼容。遇到这种情况我一般会去看一下编辑器用的是哪个 Mermaid 版本然后尽量用该版本支持的语法特征。2.3 搜索全文搜索、文件树、高亮定位一个不少轻量不代表功能残缺。很多人以为体积小的编辑器只能编辑单个文件实际上这类编辑器通常也支持以文件夹为单位打开工作区左边显示文件树右边是编辑区和预览区。搜索能力是我很看重的一点。笔记攒到上千篇之后如果编辑器没有全文搜索最后只能靠文件名找那基本等于灾难。内置全文搜索的编辑器按一下CtrlShiftF输入关键词就能在所有 Markdown 文件里搜出包含这个关键词的所有地方点击结果直接跳转到对应文件、对应行。搜索结果里关键词还会高亮显示方便快速定位上下文。我自己的使用习惯是专门建一个“notes”目录所有 Markdown 文件都扔进去用日期或者主题命名。需要找内容时直接全文搜比任何分类体系都靠谱。这也是我放弃某些在线 Markdown 工具的原因——它们把文件存在云端本地没有全文索引搜索体验受网络影响而本地轻量编辑器搜起来非常快额外还有一个好处你的所有数据都在自己手里不存在平台关闭导致笔记丢失的风险。2.4 顺带讲清楚“编译器和编辑器的区别”有一个高频搜索词是“编译器和编辑器的区别”很多刚接触 Markdown 的人会把这两个概念搞混。这里我用自己的理解讲一次编辑器Editor是让你输入和修改文本的地方编译器Compiler是把人写的代码翻译成机器能执行的程序的工具。那 Markdown 属于什么呢Markdown 本身是一种轻量级标记语言它既不是 Word 那样的富文本也不是 C 语言那样的编程语言而是“用简单符号标记文本结构”的格式。你写的是纯文本只不过这个文本里带了#、**、这种标记符号。要让这些符号变成带格式的标题、加粗、代码块就需要一个渲染引擎把 Markdown 转换成 HTML。这个过程其实非常接近“编译”输入是 Markdown 源码输出是排版后的内容。所以你会发现很多 Markdown 编辑器的预览按钮本质上就是在做一次即时编译。明白这一点你就能理解为什么有些编辑器需要装插件才能预览——因为它们本身没有内置渲染引擎。而这类不到 10MB 的轻量编辑器等于把编辑器和渲染器两件事打包在一起完成左边写 Markdown 源码右边立即显示渲染结果不需要任何插件介入。它做的不是“减少功能”而是把功能提前编译进了绿色软件包里。3. 实操体验从下载到写完一篇带公式图表的文档3.1 安装与首次启动不到 10MB 意味着什么拿到绿色版压缩包之后我做的第一件事是解压到一个专门放便携软件的目录然后直接双击运行主程序。没有安装向导、没有注册表、没有开机启动项解压即用。整个操作系统里没有留下多余痕迹换电脑时把整个目录拷走就行。放到 U 盘里更合适到了别的电脑上插上 U 盘就能打开自己熟悉的写作环境工作区、偏好设置全都在。首次启动的速度基本是“秒开”。我粗略估算了一下从双击到出现编辑界面不到一秒钟。对比 VS Code 冷启动常常要三四秒这个差距在日常使用中非常明显。很多人觉得启动慢那半秒无所谓但写作是个高频动作有时候灵感来了就想立刻记下来如果编辑器开半天还在转圈那点灵感可能就没了。首次打开后我建议你做三件事不要多多了就违背轻量原则。第一在设置里打开“自动保存”除非你特别喜欢手动按CtrlS否则自动保存是写作工具最重要的保命功能第二选择一个让自己舒服的主题浅色深色都行重点是不刺眼第三把默认字体改成等宽字体比如 JetBrains Mono、Cascadia Code 或者更直接的中文等宽字体“思源宋体等宽”类等宽字体能让代码块和表格的对齐更整齐。3.2 完整实操写一篇包含公式、流程图、表格的示例笔记光说不练没什么用我带你走一遍完整流程假设我们现在要写一篇“模型评估笔记”。第一步新建一个 Markdown 文件命名成model-evaluation-notes.md存进自己的笔记目录。开头先写标题和一段摘要# 模型评估笔记 本文记录模型评估过程中常用的指标计算公式和评估流程方便后续查阅。第二步插入一个块级公式描述准确率公式。这里我需要用到 LaTeX 语法准确率定义为 $$ Accuracy \frac{TP TN}{TP TN FP FN} $$输入双美元符号后编辑器会立刻把这段源码渲染成居中的公式块。注意要在公式里用半角符号全角等号或括号会导致渲染失败。第三步插入一个 Mermaid 流程图描述“训练—验证—测试”的标准流程。我输入text flowchart LR A[原始数据] -- B[训练集] A -- C[验证集] A -- D[测试集] B -- E[模型训练] C -- F[超参调优] E -- G[最终模型] D -- G[最终模型评估]编辑器会把它渲染成一张清晰的数据流向图。整个过程没有打开任何画图软件也没有截图、贴图。 第四步插入一个表格列出几个常用指标。Markdown 表格的写法是 text | 指标 | 公式 | 说明 | | ---- | ---- | ---- | | 精确率 | TP/(TPFP) | 预测为正例中真的为正例的比例 | | 召回率 | TP/(TPFN) | 真实正例中被正确找出的比例 | | F1 | 2*P*R/(PR) | 精确率和召回率的调和平均 |表格会自动对齐并且支持实时预览。写完这四步一篇同时包含文字、公式、图表、表格的文档就成型了。最后一步是导出。大多数这类编辑器支持导出 PDF 和 HTML。导出 PDF 适合交作业、发给人看导出 HTML 则方便直接贴到博客或者在线文档里。导出时注意如果正文包含中文必须确保编辑器导出设置里指定了中文字体否则 PDF 里的中文可能变成方框这个坑我后面细说。3.3 几个高频操作和效率技巧用这类轻量编辑器写作有几个高频操作值得记住。首先是 Markdown 换行的问题这是被搜索最多的坑之一。Markdown 语法里普通的单个回车并不会换行而是被当做一个空格处理。想让文字真正换行要么在上一行末尾敲两个空格再回车要么干脆空一行。很多新手以为编辑器坏了其实是 Markdown 本身的规矩。其次是快捷键。虽然不同编辑器的快捷键略有差异但几个基础操作基本是行业通用的CtrlB加粗、CtrlI斜体、CtrlK插入链接、CtrlShiftK插入代码块。全局搜索通常是CtrlShiftF当前文件内搜索是CtrlF。我的建议是不用刻意背写的时候手放在键盘上按一次菜单看提示就记住了。还有一个小技巧是关于 Markdown 表格复制到别处乱掉的问题。很多人在 Word、公众号后台、企业微信里粘贴 Markdown 表格发现表格变成了一坨竖线和横线。这是因为目标平台根本不识别 Markdown 表格语法。遇到这种情况我更建议先在编辑器里导出 HTML打开浏览器后从网页复制表格再粘贴到目标平台绝大多数场景下能保留表格结构。如果你经常需要把表格转成 Word 格式还可以用 Pandoc 这类批量转换工具把 Markdown 整个转成 docx那就不只是表格图片、样式、目录都能一并搞定。4. 常见问题排查与避坑实录4.1 公式显示不出来先检查这三点公式不渲染是轻量编辑器里最常遇到的问题。我排查思路一般是三步走。第一步看符号行内公式必须用一对英文半角的$包住块级公式用一对$$包住。很多人输入法开着中文全角打出来的“”不是美元符号编辑器自然无法识别。第二步看成对公式两侧的美元符号必须严格成对出现少一个都不行如果写完发现整篇文档后面的内容都变成了公式基本都是漏写结束符。第三步看命令LaTeX 语法虽然普及但不同渲染引擎支持的宏包范围不一样个别冷门命令比如\begin{aligned}或者某些特殊箭头旧版本引擎可能不支持。遇到渲染不出来的公式先改成最基础的 LaTeX 表达能力能兜底。4.2 Mermaid 图表渲染成代码了图表问题里最常见的是 Mermaid 代码没有被渲染而是以纯文本代码块的形式显示出来。出现这种情况第一个要检查的是代码块的标注语言。Markdown 里插入代码块需要在开头写语言标识画图必须写mermaid如果写成了text或者干脆不写编辑器就不知道这段代码要渲染成图自然只当普通代码展示。第二个检查点是是否需要切换视图。有些编辑器默认在“源码模式”下Mermaid 也显示为源码切换到预览模式才会渲染成图。如果你在源码模式里写了半天发现图像没出来别慌先看右上角是不是有个“预览”或“渲染”开关。第三个点比较冷门Mermaid 的节点文本里如果包含特殊字符最好用引号把节点文字包起来否则可能解析失败。比如节点想显示“判断是否通过”写成B{判断是否通过}通常没问题但如果文本带英文括号、冒号这类符号容易出问题这时候用B{判断是否通过}这种引号包裹的写法更稳。4.3 中文乱码、PDF 导出字体问题中文乱码的问题尤其在 Windows 上导出 PDF 时非常常见。我遇到过两次比较典型的场景。一是文件名用中文编辑器能正常打开但导出 PDF 时文件名变成乱码这通常和系统编码有关把文件名改成英文再导一次就正常了。二是文档里中文内容在导出 PDF 后变成方框、问号或者一团空白这基本可以确定是字体问题编辑器导出 PDF 时默认使用的字体不支持中文字符需要在导出设置里指定一个中文字体比如“微软雅黑”“思源黑体”“宋体”等。如果你想把设置固化下来可以在编辑器设置里把默认 PDF 字体改成中文字体或者配置自定义 CSS 指定字体族这样以后导出就不用每次手动选了。另外保存文档时建议统一使用 UTF-8 编码。大部分现代 Markdown 编辑器默认就是 UTF-8没有太多需要担心的但如果编辑过别人发来的文件发现中文显示成“鈥滄祻瑙”这类乱码先把文件另存为 UTF-8再重新打开基本能恢复。4.4 常见问题速查表现象可能原因解决办法表格复制到 Word 后错位Word 不支持 Markdown 表格语法先导出 HTML再从浏览器复制表格粘贴或用 Pandoc 转 docx按回车不换行Markdown 语法规则如此行尾敲两个空格或空一行公式显示成源码美元符号不全角、或缺少结束符使用半角$确保成对出现Mermaid 图显示成代码代码块语言没有标注 mermaid把代码块开头改成mermaid导出 PDF 中文乱码缺少中文字体设置在导出设置中指定微软雅黑等中文字体打开别人发的文件乱码文件编码不是 UTF-8另存为 UTF-8 后再打开左边文件树看不到文件可能打开的是单文件而不是文件夹用“打开文件夹”方式加载笔记目录4.5 一个我踩过的比较深的坑说一个我自己真实踩过的坑。有一次我用编辑器写一篇长文写了大概四千多字中途有事离开顺手把窗口关掉了。当时我以为“关了再打开没保存的内容会问我要不要恢复”结果这个不太普及的轻量工具没有弹恢复提示等我回来打开文件发现只保存到上一次手动保存的内容中间几百字全没了。从此之后我给自己定下规矩第一任何写作工具到手第一件事就是开自动保存第二每隔十几分钟手指自然按一下CtrlS已经成为肌肉记忆第三便携版最好把工作目录放在自己专门的数据盘不要默认放在临时目录里。工具再轻数据也不能轻。5. 这类轻量编辑器适合谁不适合谁5.1 推荐场景与人群我试用下来轻量 Markdown 编辑器最合适的场景是“单人、本地、纯文本写作”。学生拿它记课堂笔记非常合适尤其是理工科课程公式可以随手写流程图可以随手画导出 PDF 交作业也方便。技术博主可以拿它打草稿先写完 Markdown 正文再统一贴到博客后台或者公众号编辑器里比在网页里写稿流畅得多。程序员写 README、技术方案、会议纪要也很顺手因为这类文本本身就以 Markdown 为主一个轻量编辑器足够应付。还有一类人是“工具洁癖患者”——不喜欢装一堆插件、不喜欢软件体积越来越大、不喜欢启动时要等进度条。如果你看到安装包体积超过 100MB 就不想动那这种几 MB 的编辑器简直就是为你准备的。它把 80% 情况下最刚需的能力都内置好了剩下的 20% 偶尔需要就用其他工具临时补一下完全不需要让编辑器本身变得臃肿。5.2 什么时候你还是需要“重”工具但我也要说清楚轻量编辑器不是万能的。它不适合做大型知识库。如果你要构建一个几千条笔记互相关联的个人知识体系带双链关系的 Obsidian 会更有优势它强大的插件生态和图谱视图能让你在笔记之间建立复杂引用网络这是轻量编辑器做不到的。它也不适合写代码场景。如果你本来就要在 VS Code 里开发那顺便看 Markdown 是顺理成章的事没必要多开一个编辑器。VS Code 的优势在于插件生态完整Markdown Preview Enhanced 这些插件能提供比内置预览更丰富的展示效果配合 Git 集成、AI 代码补全在工程化写作场景里依然是首选。多人协作也不是轻量编辑器的强项。要团队实时编辑、评论、权限管理去用 Notion、语雀、飞书文档这些在线协作工具更合适。它们本质是“协作平台”而轻量编辑器本质是“个人写作工具”两者解决的不是同一个问题。选工具要看场景而不是看谁功能多。5.3 我的最终配置与个人体会用了一段时间之后我现在的工作流是日常写草稿、记学习笔记、写技术博客初稿都优先用这个不到 10MB 的轻量编辑器打开快、不吵闹、表单公式图表都顺手遇到要构建长期知识库的题目我才会打开 Obsidian 去搭结构写代码项目里的 README 或者需要 Git 管理的技术方案我会在 VS Code 里处理。根据我个人经验我觉得最理想的状态不是“找到一个全能的编辑器”而是“让每个工具都只做它最擅长的事”。轻量编辑器负责“写”重工具体系负责“管”协作平台负责“传”各司其职反而比指望一个工具解决所有问题更高效。这款轻量编辑器最大的价值不是它功能有多全面而是它让我重新找回了“打开编辑器立刻开始写”的专注感。如果你也厌倦了折腾插件和配置想安安静静写点东西不妨试试这种几 MB 的开箱即用方案说不定你也会喜欢上这种不被工具绑架的感觉。 轻量级Markdown编辑器：免安装、内置公式图表、打开即写
先说个背景我平时写技术文章、项目文档、课程笔记基本都靠 Markdown 打底。早年用 Typora 确实舒服但后来它收费了转去 VS Code 写了一阵子没装插件的时候和记事本差不多装完插件又要配主题、配预览、配同步一个文档编辑器愣是玩成了 IDE。前几天整理 U 盘翻出一个不到 10MB 的绿色版 Markdown 编辑器公式、图表、全文搜索全内置一个插件都不用装。我把它拷到新电脑上用了两天体验意外地顺手。今天就把这个“轻量到极致”的写作方案拆开讲讲适合学生记笔记、博主写稿、程序员写 README以及所有不想折腾工具、打开就想写的人。1. 先说痛点我是怎么被“重编辑器”逼疯的1.1 从 Typora 收费到 VS Code 插件地狱先说 Typora。它的所见即所得排版确实漂亮写 Markdown 的时候基本感觉不到在写标记语言光标一按加粗、标题、表格都实时渲染出来。但后来 Typora 开始收费倒不是说 89 块钱买断多贵而是我始终觉得一个写纯文本的工具付费点应该在于服务、云同步或者协作单纯为了本地渲染就收费总让我不太想掏钱。更关键的是Typora 的安装包并不小加上主题、自定义 CSS整个目录体积会明显膨胀。对于我这种喜欢把写作工具随身带在 U 盘里的人它并不算轻。再说 VS Code。VS Code 写 Markdown 的体验上限很高但下限也很低。刚装完的 VS Code 连 Markdown 预览都要手动开快捷键也没有针对写作优化。想达到 Typora 那种“边写边渲染”的体验至少得装一套 Markdown All in One、Markdown Preview Enhanced、Paste Image 之类的插件。插件一多问题就来了启动速度肉眼可见地变慢快捷键偶尔冲突插件更新后预览样式变了又得花时间调。更要命的是VS Code 默认是面向代码工程的一个工作区里塞了代码、配置、插件缓存写作这件事反而被稀释了。如果你跟我一样只是想把脑子里的话倒进文档里VS Code 的配置成本确实有点高。中间我也试过 Joplin、Obsidian、思源笔记这类“笔记应用”。它们其实更接近知识库带有数据库、同步、插件市场、双链关系图谱功能很强但这也意味着学习成本。为了写一篇周报去学一套双链系统怎么看都不划算。而且它们大多基于 Electron安装包动辄上百 MB启动到能输入文字要等一阵子和我想要的“双击即写”完全是两个方向。1.2 我真正需要的其实是“打开就能写”被这些工具来回折腾之后我把自己的需求重新列了一遍发现其实非常朴素免费最好开源不想为基本功能付费体积小安装包不超过 10MB启动快最好免安装、能放 U 盘支持 Markdown 基础语法标题、加粗、斜体、列表、代码块、表格这些必须有支持数学公式渲染毕竟写技术文章经常会碰到 LaTeX 公式支持流程图、时序图之类的图表至少要有 Mermaid 语法能全文搜索笔记积累到一定量之后搜不到等于白写离线可用不依赖网络导出 PDF 或 HTML 要方便。列完这份清单之后我才意识到很多时候我们并不是“需要”功能而是“被功能绑架”。VS Code 就像一把瑞士军刀什么功能都有但每次拧颗螺丝都得先翻出对应工具头而我要的其实是一把趁手的菜刀切菜直接上手不需要研究刀柄上那排配件怎么用。轻量 Markdown 编辑器能解决的就是这个“打开就能写”的场景。2. 轻量 Markdown 编辑器到底把哪些能力做到了“内置”2.1 公式LaTeX 语法直接渲染不用装任何数学插件数学公式是很多人选 Markdown 编辑器时最容易忽略、但用到时最头疼的功能。如果你只是写普通文档确实用不上可一旦要写带有公式的笔记、论文草稿或者技术方案少了公式支持就等于要另开一个工具。这类轻量编辑器内置的公式方案大多基于 KaTeX 或 MathJax 渲染引擎支持用美元符号包裹 LaTeX 语法。行内公式用单个$比如写$Emc^2$会渲染成行内的 Emc²块级公式用双美元$$会单独占一行并居中。比如常见的积分公式$$ \int_0^\infty e^{-x^2} dx \frac{\sqrt{\pi}}{2} $$矩阵、分段函数、希腊字母、求和符号这些也都能写。我写机器学习笔记的时候最常用到的是矩阵公式$$ \begin{pmatrix} a b \ c d \end{pmatrix} $$编辑器会在输入过程中实时渲染基本不用等离线也能用。为什么能做到这一点原因很简单渲染引擎被打包进了编辑器本体不需要额外安装 MathJax 插件或者联网调用 CDN。很多在线 Markdown 编辑器需要联网才能显示公式就是因为它们把渲染放在云端而本地内置引擎的编辑器断网照常工作隐私性也更好。这里有个细节值得注意公式语法和 Markdown 语法混排时偶尔会有冲突。比如美元符号在普通文本里也偶尔会用到如果你写的是货币金额$100编辑器可能会误判成行内公式。遇到这种情况我一般会在美元符号前加反斜杠转义或者直接改用全角符号“”问题就没了。2.2 图表流程图、时序图、甘特图靠 Mermaid 语法“画”出来图表功能是这类轻量编辑器另一个让我惊喜的地方。以往想在 Markdown 文档里插入流程图要么用 Visio 画完截图贴进来要么用代码画图再导出图片麻烦不说图片还没法跟着文字一起做版本管理。而这几年 Markdown 社区流行起一种“用文本描述图表”的方案名字叫 Mermaid简单说就是你用一段特殊语法描述图的节点和连线编辑器自动帮你渲染成矢量图。比如我想画一个简单的“写文档要不要画图”的判断流程只需要写一段这样的源码flowchart TD A[写文档] -- B{要不要画图?} B -- 要 -- C[Mermaid 语法] B -- 不要 -- D[纯 Markdown] C -- E[自动渲染成图表]编辑器会把它渲染成一个清晰的流程图左边“写文档”指向判断节点然后分叉到“要”和“不要”两条路径。重点是这张图不是图片文件而是一段纯文本。好处非常直接改文字就能改图不涉及拖拽、对齐、导出图片那些操作放到 Git 仓库里别人能直接 diff 出图的改动复制到别的支持 Mermaid 的平台也能原样渲染。除了流程图Mermaid 还支持时序图、状态图、甘特图、饼图等。写项目周报的时候我常画甘特图来排期写接口文档的时候用时序图描述调用关系。内置 Mermaid 的编辑器相当于把画图工具直接塞进了写作环境省去了“切换软件—画图—导出—贴进文档”这一整条链路。需要提醒的是不同编辑器内置的 Mermaid 版本不一样如果一段 Mermaid 语法在这个编辑器里渲染正常换一个编辑器却报错大概率是版本差异导致语法不兼容。遇到这种情况我一般会去看一下编辑器用的是哪个 Mermaid 版本然后尽量用该版本支持的语法特征。2.3 搜索全文搜索、文件树、高亮定位一个不少轻量不代表功能残缺。很多人以为体积小的编辑器只能编辑单个文件实际上这类编辑器通常也支持以文件夹为单位打开工作区左边显示文件树右边是编辑区和预览区。搜索能力是我很看重的一点。笔记攒到上千篇之后如果编辑器没有全文搜索最后只能靠文件名找那基本等于灾难。内置全文搜索的编辑器按一下CtrlShiftF输入关键词就能在所有 Markdown 文件里搜出包含这个关键词的所有地方点击结果直接跳转到对应文件、对应行。搜索结果里关键词还会高亮显示方便快速定位上下文。我自己的使用习惯是专门建一个“notes”目录所有 Markdown 文件都扔进去用日期或者主题命名。需要找内容时直接全文搜比任何分类体系都靠谱。这也是我放弃某些在线 Markdown 工具的原因——它们把文件存在云端本地没有全文索引搜索体验受网络影响而本地轻量编辑器搜起来非常快额外还有一个好处你的所有数据都在自己手里不存在平台关闭导致笔记丢失的风险。2.4 顺带讲清楚“编译器和编辑器的区别”有一个高频搜索词是“编译器和编辑器的区别”很多刚接触 Markdown 的人会把这两个概念搞混。这里我用自己的理解讲一次编辑器Editor是让你输入和修改文本的地方编译器Compiler是把人写的代码翻译成机器能执行的程序的工具。那 Markdown 属于什么呢Markdown 本身是一种轻量级标记语言它既不是 Word 那样的富文本也不是 C 语言那样的编程语言而是“用简单符号标记文本结构”的格式。你写的是纯文本只不过这个文本里带了#、**、这种标记符号。要让这些符号变成带格式的标题、加粗、代码块就需要一个渲染引擎把 Markdown 转换成 HTML。这个过程其实非常接近“编译”输入是 Markdown 源码输出是排版后的内容。所以你会发现很多 Markdown 编辑器的预览按钮本质上就是在做一次即时编译。明白这一点你就能理解为什么有些编辑器需要装插件才能预览——因为它们本身没有内置渲染引擎。而这类不到 10MB 的轻量编辑器等于把编辑器和渲染器两件事打包在一起完成左边写 Markdown 源码右边立即显示渲染结果不需要任何插件介入。它做的不是“减少功能”而是把功能提前编译进了绿色软件包里。3. 实操体验从下载到写完一篇带公式图表的文档3.1 安装与首次启动不到 10MB 意味着什么拿到绿色版压缩包之后我做的第一件事是解压到一个专门放便携软件的目录然后直接双击运行主程序。没有安装向导、没有注册表、没有开机启动项解压即用。整个操作系统里没有留下多余痕迹换电脑时把整个目录拷走就行。放到 U 盘里更合适到了别的电脑上插上 U 盘就能打开自己熟悉的写作环境工作区、偏好设置全都在。首次启动的速度基本是“秒开”。我粗略估算了一下从双击到出现编辑界面不到一秒钟。对比 VS Code 冷启动常常要三四秒这个差距在日常使用中非常明显。很多人觉得启动慢那半秒无所谓但写作是个高频动作有时候灵感来了就想立刻记下来如果编辑器开半天还在转圈那点灵感可能就没了。首次打开后我建议你做三件事不要多多了就违背轻量原则。第一在设置里打开“自动保存”除非你特别喜欢手动按CtrlS否则自动保存是写作工具最重要的保命功能第二选择一个让自己舒服的主题浅色深色都行重点是不刺眼第三把默认字体改成等宽字体比如 JetBrains Mono、Cascadia Code 或者更直接的中文等宽字体“思源宋体等宽”类等宽字体能让代码块和表格的对齐更整齐。3.2 完整实操写一篇包含公式、流程图、表格的示例笔记光说不练没什么用我带你走一遍完整流程假设我们现在要写一篇“模型评估笔记”。第一步新建一个 Markdown 文件命名成model-evaluation-notes.md存进自己的笔记目录。开头先写标题和一段摘要# 模型评估笔记 本文记录模型评估过程中常用的指标计算公式和评估流程方便后续查阅。第二步插入一个块级公式描述准确率公式。这里我需要用到 LaTeX 语法准确率定义为 $$ Accuracy \frac{TP TN}{TP TN FP FN} $$输入双美元符号后编辑器会立刻把这段源码渲染成居中的公式块。注意要在公式里用半角符号全角等号或括号会导致渲染失败。第三步插入一个 Mermaid 流程图描述“训练—验证—测试”的标准流程。我输入text flowchart LR A[原始数据] -- B[训练集] A -- C[验证集] A -- D[测试集] B -- E[模型训练] C -- F[超参调优] E -- G[最终模型] D -- G[最终模型评估]编辑器会把它渲染成一张清晰的数据流向图。整个过程没有打开任何画图软件也没有截图、贴图。 第四步插入一个表格列出几个常用指标。Markdown 表格的写法是 text | 指标 | 公式 | 说明 | | ---- | ---- | ---- | | 精确率 | TP/(TPFP) | 预测为正例中真的为正例的比例 | | 召回率 | TP/(TPFN) | 真实正例中被正确找出的比例 | | F1 | 2*P*R/(PR) | 精确率和召回率的调和平均 |表格会自动对齐并且支持实时预览。写完这四步一篇同时包含文字、公式、图表、表格的文档就成型了。最后一步是导出。大多数这类编辑器支持导出 PDF 和 HTML。导出 PDF 适合交作业、发给人看导出 HTML 则方便直接贴到博客或者在线文档里。导出时注意如果正文包含中文必须确保编辑器导出设置里指定了中文字体否则 PDF 里的中文可能变成方框这个坑我后面细说。3.3 几个高频操作和效率技巧用这类轻量编辑器写作有几个高频操作值得记住。首先是 Markdown 换行的问题这是被搜索最多的坑之一。Markdown 语法里普通的单个回车并不会换行而是被当做一个空格处理。想让文字真正换行要么在上一行末尾敲两个空格再回车要么干脆空一行。很多新手以为编辑器坏了其实是 Markdown 本身的规矩。其次是快捷键。虽然不同编辑器的快捷键略有差异但几个基础操作基本是行业通用的CtrlB加粗、CtrlI斜体、CtrlK插入链接、CtrlShiftK插入代码块。全局搜索通常是CtrlShiftF当前文件内搜索是CtrlF。我的建议是不用刻意背写的时候手放在键盘上按一次菜单看提示就记住了。还有一个小技巧是关于 Markdown 表格复制到别处乱掉的问题。很多人在 Word、公众号后台、企业微信里粘贴 Markdown 表格发现表格变成了一坨竖线和横线。这是因为目标平台根本不识别 Markdown 表格语法。遇到这种情况我更建议先在编辑器里导出 HTML打开浏览器后从网页复制表格再粘贴到目标平台绝大多数场景下能保留表格结构。如果你经常需要把表格转成 Word 格式还可以用 Pandoc 这类批量转换工具把 Markdown 整个转成 docx那就不只是表格图片、样式、目录都能一并搞定。4. 常见问题排查与避坑实录4.1 公式显示不出来先检查这三点公式不渲染是轻量编辑器里最常遇到的问题。我排查思路一般是三步走。第一步看符号行内公式必须用一对英文半角的$包住块级公式用一对$$包住。很多人输入法开着中文全角打出来的“”不是美元符号编辑器自然无法识别。第二步看成对公式两侧的美元符号必须严格成对出现少一个都不行如果写完发现整篇文档后面的内容都变成了公式基本都是漏写结束符。第三步看命令LaTeX 语法虽然普及但不同渲染引擎支持的宏包范围不一样个别冷门命令比如\begin{aligned}或者某些特殊箭头旧版本引擎可能不支持。遇到渲染不出来的公式先改成最基础的 LaTeX 表达能力能兜底。4.2 Mermaid 图表渲染成代码了图表问题里最常见的是 Mermaid 代码没有被渲染而是以纯文本代码块的形式显示出来。出现这种情况第一个要检查的是代码块的标注语言。Markdown 里插入代码块需要在开头写语言标识画图必须写mermaid如果写成了text或者干脆不写编辑器就不知道这段代码要渲染成图自然只当普通代码展示。第二个检查点是是否需要切换视图。有些编辑器默认在“源码模式”下Mermaid 也显示为源码切换到预览模式才会渲染成图。如果你在源码模式里写了半天发现图像没出来别慌先看右上角是不是有个“预览”或“渲染”开关。第三个点比较冷门Mermaid 的节点文本里如果包含特殊字符最好用引号把节点文字包起来否则可能解析失败。比如节点想显示“判断是否通过”写成B{判断是否通过}通常没问题但如果文本带英文括号、冒号这类符号容易出问题这时候用B{判断是否通过}这种引号包裹的写法更稳。4.3 中文乱码、PDF 导出字体问题中文乱码的问题尤其在 Windows 上导出 PDF 时非常常见。我遇到过两次比较典型的场景。一是文件名用中文编辑器能正常打开但导出 PDF 时文件名变成乱码这通常和系统编码有关把文件名改成英文再导一次就正常了。二是文档里中文内容在导出 PDF 后变成方框、问号或者一团空白这基本可以确定是字体问题编辑器导出 PDF 时默认使用的字体不支持中文字符需要在导出设置里指定一个中文字体比如“微软雅黑”“思源黑体”“宋体”等。如果你想把设置固化下来可以在编辑器设置里把默认 PDF 字体改成中文字体或者配置自定义 CSS 指定字体族这样以后导出就不用每次手动选了。另外保存文档时建议统一使用 UTF-8 编码。大部分现代 Markdown 编辑器默认就是 UTF-8没有太多需要担心的但如果编辑过别人发来的文件发现中文显示成“鈥滄祻瑙”这类乱码先把文件另存为 UTF-8再重新打开基本能恢复。4.4 常见问题速查表现象可能原因解决办法表格复制到 Word 后错位Word 不支持 Markdown 表格语法先导出 HTML再从浏览器复制表格粘贴或用 Pandoc 转 docx按回车不换行Markdown 语法规则如此行尾敲两个空格或空一行公式显示成源码美元符号不全角、或缺少结束符使用半角$确保成对出现Mermaid 图显示成代码代码块语言没有标注 mermaid把代码块开头改成mermaid导出 PDF 中文乱码缺少中文字体设置在导出设置中指定微软雅黑等中文字体打开别人发的文件乱码文件编码不是 UTF-8另存为 UTF-8 后再打开左边文件树看不到文件可能打开的是单文件而不是文件夹用“打开文件夹”方式加载笔记目录4.5 一个我踩过的比较深的坑说一个我自己真实踩过的坑。有一次我用编辑器写一篇长文写了大概四千多字中途有事离开顺手把窗口关掉了。当时我以为“关了再打开没保存的内容会问我要不要恢复”结果这个不太普及的轻量工具没有弹恢复提示等我回来打开文件发现只保存到上一次手动保存的内容中间几百字全没了。从此之后我给自己定下规矩第一任何写作工具到手第一件事就是开自动保存第二每隔十几分钟手指自然按一下CtrlS已经成为肌肉记忆第三便携版最好把工作目录放在自己专门的数据盘不要默认放在临时目录里。工具再轻数据也不能轻。5. 这类轻量编辑器适合谁不适合谁5.1 推荐场景与人群我试用下来轻量 Markdown 编辑器最合适的场景是“单人、本地、纯文本写作”。学生拿它记课堂笔记非常合适尤其是理工科课程公式可以随手写流程图可以随手画导出 PDF 交作业也方便。技术博主可以拿它打草稿先写完 Markdown 正文再统一贴到博客后台或者公众号编辑器里比在网页里写稿流畅得多。程序员写 README、技术方案、会议纪要也很顺手因为这类文本本身就以 Markdown 为主一个轻量编辑器足够应付。还有一类人是“工具洁癖患者”——不喜欢装一堆插件、不喜欢软件体积越来越大、不喜欢启动时要等进度条。如果你看到安装包体积超过 100MB 就不想动那这种几 MB 的编辑器简直就是为你准备的。它把 80% 情况下最刚需的能力都内置好了剩下的 20% 偶尔需要就用其他工具临时补一下完全不需要让编辑器本身变得臃肿。5.2 什么时候你还是需要“重”工具但我也要说清楚轻量编辑器不是万能的。它不适合做大型知识库。如果你要构建一个几千条笔记互相关联的个人知识体系带双链关系的 Obsidian 会更有优势它强大的插件生态和图谱视图能让你在笔记之间建立复杂引用网络这是轻量编辑器做不到的。它也不适合写代码场景。如果你本来就要在 VS Code 里开发那顺便看 Markdown 是顺理成章的事没必要多开一个编辑器。VS Code 的优势在于插件生态完整Markdown Preview Enhanced 这些插件能提供比内置预览更丰富的展示效果配合 Git 集成、AI 代码补全在工程化写作场景里依然是首选。多人协作也不是轻量编辑器的强项。要团队实时编辑、评论、权限管理去用 Notion、语雀、飞书文档这些在线协作工具更合适。它们本质是“协作平台”而轻量编辑器本质是“个人写作工具”两者解决的不是同一个问题。选工具要看场景而不是看谁功能多。5.3 我的最终配置与个人体会用了一段时间之后我现在的工作流是日常写草稿、记学习笔记、写技术博客初稿都优先用这个不到 10MB 的轻量编辑器打开快、不吵闹、表单公式图表都顺手遇到要构建长期知识库的题目我才会打开 Obsidian 去搭结构写代码项目里的 README 或者需要 Git 管理的技术方案我会在 VS Code 里处理。根据我个人经验我觉得最理想的状态不是“找到一个全能的编辑器”而是“让每个工具都只做它最擅长的事”。轻量编辑器负责“写”重工具体系负责“管”协作平台负责“传”各司其职反而比指望一个工具解决所有问题更高效。这款轻量编辑器最大的价值不是它功能有多全面而是它让我重新找回了“打开编辑器立刻开始写”的专注感。如果你也厌倦了折腾插件和配置想安安静静写点东西不妨试试这种几 MB 的开箱即用方案说不定你也会喜欢上这种不被工具绑架的感觉。