如果你也在用 Markdown 写技术笔记大概率经历过这种场景为了在文档里插一条公式得去装一个渲染插件为了画个流程图又去装一个图表插件写完想全局搜一下某个结论发现编辑器自带的搜索弱得可怜还得再配一个。插件越装越多编辑器越来越胖最后你打开它只是为了写两段字风扇却先转了起来。上个月我被一个独立开发者朋友安利了 LiteMark——我先这么称呼它一款不到 10MB 的免费 Markdown 编辑器公式、图表、搜索全内置一个插件都不用装。我当时的第一反应是不信10MB 能干什么VS Code 光是安装包就快 100MB装完插件奔着 1GB 去。结果用下来我只能说我可能回不去了。这篇不是广告LiteMark 也不是什么大厂产品它就是一个认真做减法的小工具。如果你厌倦了折腾配置、受够了订阅制或者纯粹想要一个能双击打开、随手写完一篇带公式和流程图的文档的编辑器这篇文章应该对你有用。我会把功能原理、实测过程和踩过的坑都讲清楚。1. 我为什么卸掉了 VS Code 里的 Markdown 全家桶1.1 写作场景的刚需公式、图表、搜索、预览一个都不能少先说说我的写作场景。我平时要写三类东西技术笔记、实验报告、方案文档。技术笔记里全是数学公式实验报告里要贴数据表和分析过程方案文档里免不了要画流程时序。这就决定了我的编辑器至少要满足四件事Markdown 语法高亮、实时预览、行内和块级公式渲染、流程图绘制。如果再算上资料检索全文搜索也得能用。这些需求听起来不复杂但你挨个去实现就会发现每一件都要付出额外成本。也许你用的是 Typora那公式算是一个按钮的事但我在团队里不能要求每个人都买授权自己单独买又觉得不值。于是很长一段时间我主力用的是 VS Code。VS Code 的玩法是装插件。我装过 Markdown All in One、markdownlint、Markdown Preview Enhanced、Draw.io Integration 等等前前后后十几个。插件方案的第一个坑是配置环境不一致换台电脑重新装一遍插件版本对不上渲染效果直接变样。第二个坑是启动越来越慢吃内存越来越凶。我有一台早年间的 8GB 笔记本打开 VS Code 写个笔记基本要转圈十秒起步开完再点一下预览风扇呼呼的。1.2 插件方案和商业软件的隐性成本让我转向了全内置第三个坑是插件之间会互相打架。有些插件负责格式化有些插件负责导出它们对表格的支持、对公式符号的转义规则都不完全一样。有一次我写完一篇笔记预览是正常的导出 PDF 时公式全部变成了源码排查了半天才发现是两个插件对 LaTeX 标识符的处理逻辑冲突。算完这笔账我就明白了我需要的不是一个功能最多的编辑器而是一个把写作必备功能默认内置的编辑器。插件生态很繁荣但繁荣是有代价的。每个插件都要维护都要更新都有可能在某个版本之后改变行为。你花在选插件、调配置、修冲突上的时间早就够写完好几篇文档了。商业软件那边也让我犹豫。Typora 这类编辑器做得很完善公式、表格、目录、导出都顺滑。但它的定位越来越偏“完整文档排版工具”对快速记录场景来说稍显笨重。而且付费授权这件事本身没问题问题是我需要同时在不同设备上使用每台都要考虑授权策略。LiteMark 这种“出厂即满配”的思路恰好击中了我这个痛点免费、轻量、绿色、不把功能藏在付费墙后面。2. 9.6MB 怎么塞下公式、图表和搜索拆开看原理2.1 公式本地渲染的 KaTeX不联网也能出效果这么小的体积为什么能渲染公式我的理解是它没有自己从头造轮子而是把 KaTeX 这样一个非常成熟的本地渲染库裁剪后塞了进来。KaTeX 的完整包有几 MB去掉不常用的宏包和字体保留常用功能后可以压到很小。更重要的是它是本地渲染不是像某些在线编辑器那样把公式代码发到服务器生成图片再吐回来。离线能用没有延迟公式也不糊。我实际用下来行内公式写两个美元号包起来就能生效比如$x \frac{-b \pm \sqrt{b^2-4ac}}{2a}$这种输入完立刻在预览区看到结果。块级公式用两个美元号独占一行渲染速度几乎感觉不到迟滞。这里推荐大家用常用公式时先确认一下 KaTeX 的宏包支持范围比如\begin{aligned}这类多行对齐环境精简版不一定都支持。LiteMark 对常见教材公式基本没出现过问题但偏门物理符号偶尔会缺失。为什么强调“本地渲染”而不是“调在线接口”因为写公式是很高频的动作如果每敲一个公式都要等网络往返写作节奏会碎掉。而且在线渲染通常返回的是图片或 SVG跨端复制容易丢格式。本地渲染直接把公式当作文本的一部分导出 HTML、PDF 都很干净。这也是我认为它“懂写作”的原因。2.2 图表用文本描述流程图Mermaid 引擎内置图表方面LiteMark 内置的是 Mermaid 解析器。Mermaid 是一个用文本描述图形的工具画流程图、时序图、状态图、甘特图都可以。它不是让你用鼠标拖矩形拉箭头而是通过几行代码自动生成图形。比如你输入graph TD; A[开始] -- B[结束]预览区就会出现一张从上到下的流程图。为什么选了 Mermaid 而不是 ECharts我猜开发者考虑的是体积。ECharts 全家桶不小而且做数据可视化更偏向复杂交互图表对 Markdown 写作来说属于重装备。Mermaid 的优点是语法简单、运行轻量跟 Markdown 的文本写作习惯天然契合。我想要的是“画个流程说明一下逻辑”不是搭一个 BI 看板。Mermaid 能画的类型很多我最常用的是 graph 和 sequenceDiagram。graph 适合描述分支流程sequenceDiagram 适合描述几个角色之间的消息交互。甘特图我也偶尔用特别是做项目排期的时候直接在笔记里写上任务、时间区间预览区就能生成一张清爽的进度条。整个过程不需要打开任何画图软件也不用考虑对齐和配色这点对技术文档写作者太友好了。2.3 搜索不建数据库靠目录扫描和缓存也能秒开搜索功能最容易被人忽略但我恰恰觉得这是 LiteMark 最让人舒服的一点。它不会像笔记软件那样给你建一个大数据库而是通过扫描当前文件夹在内存里建一份轻量索引。打开一个几百篇笔记的文件夹第一次搜索可能要等一两秒之后再次搜索基本就是秒出。这种方案的好处是零维护。你不需要考虑索引损坏、重建索引、数据库文件失配之类的问题。文件夹里加了新文件它会自动感知删了文件索引也跟着消失。相比那些一定要先“导入笔记库”的软件它真正做到了“文件夹就是笔记库”的直觉体验。除了全文搜索它还带一个快速打开面板按快捷键输入文件名的一部分就能模糊匹配到对应 Markdown 文件。这个功能对写作者来说太重要了——我经常在几十个草稿里找一个上周的笔记原来要一层层点目录现在直接敲几个字符就能跳过去。配合全文搜索一个按命令面板、一个按文件查找基本覆盖了“我记过什么”和“那句话在哪个文件里”这两个高频需求。3. 我用它写完一篇带公式和流程图的笔记踩了四个坑3.1 公式写的对但预览不出来多半是放错了位置先说公式。我第一次用 LiteMark 写笔记自以为很熟练结果预览区里公式位置一片空白。排查了半天发现是我把公式写在了一个代码块里。Markdown 的代码块优先级比公式要高只要公式包围在 中间编辑器就会认为这是一段程序代码不会调用 KaTeX 去渲染。把公式挪到代码块外面马上恢复。另一个和公式相关的体验是“靠左显示”。有些 Markdown 编辑器的块级公式默认居中LiteMark 的设置里也保留了这个选项。写数学推导的时候公式居中对齐在正式论文里没毛病但做个人笔记我更喜欢靠左这样能跟正文文字轴线保持一致。在编辑器选项里把公式对齐方式改成 left 之后整个推导过程读起来顺多了。公式编号也值得说。块级公式末尾可以加\tag{1}来实现编号适合需要交叉引用的场合。比如我写实验报告时经常会写“由式(3)可知”这时候给公式手动编号就比“上面那个公式”靠谱得多。LiteMark 对\tag的支持还算稳定不过要注意它渲染的是公式右侧的标签不是像 LaTeX 那样自动维护计数器。3.2 画流程图时中文节点和线条方向的处理再说 Mermaid。第一次画流程图我发现中文节点名显示成了乱码后来才明白是字体问题。Mermaid 渲染中文需要系统有对应的中文字体而且节点文本最好用引号包起来。比如graph TD; A[开始] -- B[结束]加了引号之后文字内部的空格和特殊字符才不会被解析器当成语法。还有一个方向感的问题。graph TD 表示从上到下graph LR 表示从左到右。如果节点多了默认布局可能挤成一团我的经验是拆成多个子图或者改用 LR 方向。画时序图同理participant 的顺序决定了横轴排列搞反了读起来很别扭。好在这种调整成本很低改一行文字预览立刻重绘。我后来还发现一个关于 Mermaid 的隐藏问题如果节点里包含括号、引号、百分号这样的特殊字符一定要用双引号包住。比如A[条件(满足)] -- B[输出]不加引号解析器可能会报错或者画出错误的连线。这类问题在英文环境下同样存在只是中文文本因为字符集不同表现得会更明显。3.3 全文搜索不是万能的范围和替换这两个小细节第三个坑出现在搜索上。我打开的是一个包含子文件夹的笔记目录搜索某个关键词时结果只有当前文件里的几条子文件夹里的全没搜到。查了文档才发现LiteMark 的搜索范围需要在搜索框下面手动切换默认是“当前文件”改成“当前文件夹”才会递归搜索子目录。这是设计取舍但我第一次用确实容易漏。替换功能的坑更隐蔽。它支持正则替换正则表达式默认对大小写敏感。如果你搜索 note 想替换成“笔记”结果发现 Note 没被处理不要怀疑编辑器坏了去把大小写匹配选项关掉就行。还有一个容易被忽略的点替换会直接改写文件如果你只是想看看所有匹配的位置不要直接按替换先用搜索结果的上下文预览确认一下再动手。3.4 导出 PDF 时公式消失我是这样解决的导出方面我遇到过的最大问题是公式消失。LiteMark 导出 PDF 时走的其实是浏览器打印样式如果预览没问题导出的公式应该也能正常显示。但有一次我用了系统里一个旧版中文字体导致整个 PDF 里公式区域出现空白。解决办法很土把默认字体换成系统自带的普通中文字体再重新导出就正常了。另外导出时如果文档里有 Mermaid 图表务必先等图表渲染完成再点导出。渲染还没结束就导出极易把图表捕获成空白区块。这个小问题我碰到过好几次后来养成了等预览稳定再导出的习惯。还有一个经验是导出前先检查打印边距。LiteMark 的导出样式默认是网页打印风格如果你平时会插入很宽的表格或者较长的代码块默认边距可能把内容截断。我第一次导出实验报告时表格右侧就被切掉了一小块后来在导出设置里把页面边距调小才恢复正常。4. 横向比一圈它到底赢在哪又在哪里露怯4.1 和 VS Code插件、Typora 类工具的硬数据对比我用 LiteMark 的同时把 VS Code插件方案和 Typora 类商业编辑器放在一起做了个简单对比。这个对比不是实验室级别的严谨测试就是我自己的主观感受和实际观察但足以说明问题。维度LiteMarkVS CodeMarkdown插件Typora类商业编辑器安装包体积约9.6MB约100MB插件若干几十MB起步部分付费启动速度秒开几秒到十几秒视插件量秒开级别公式渲染内置KaTeX依赖插件需配置内置但部分功能需授权Mermaid图表内置需要额外插件部分内置或依赖主题全文搜索内置文件夹级搜索较弱需要插件完善内置但轻量版有阉割配置迁移基本零配置插件和settings需重新折腾云同步需订阅从这个表能看出LiteMark 的体积和启动速度是最大优势“零配置”对怕麻烦的人来说是降维打击。但它的扩展性确实比不上 VS Code毕竟插件体系是 VS Code 的核心竞争力。不过这里我要为“插件生态”说句公道话如果你需要的是极冷门功能比如把 Markdown 转成特定的公司内部文档格式或者对接某个私有系统那 VS Code 插件几乎无可替代。LiteMark 给出的是一个覆盖 90% 高频需求的默认方案剩下 10% 的定制需求它没有能力覆盖这也是它定位“编辑器”而不是“平台”的诚实之处。4.2 不建议拿它做的事超大文档、复杂图表和协作编辑它有明显的能力边界。如果你要写一篇超过几万字的书稿滚动和渲染会开始吃力毕竟轻量编辑器在性能优化上不会投入像大项目那么多资源。如果要做复杂的信息架构比如双链笔记、知识图谱、多人实时协同编辑LiteMark 基本帮不上忙这种需求更适合专业的笔记类应用或在线协作平台。还有一个容易被忽略的点剪藏和富文本粘贴。从网页上复制一段带格式的内容粘贴进 LiteMark 的源码视图拿到的往往只有纯文本图片也不会自动下载到本地。这和 Typora 这类商业化产品在体验上还是有差距。所以我的建议是不要拿它去做知识管理全家桶它就是干“快速记录和成稿”这一件事的把这一件事做好就已经值回票价。反过来说正因为它不做“全家桶”它的学习成本很低。我一个朋友从没用过 Markdown我用十分钟给他讲完标题、列表、加粗、代码块、公式这五样他当天就能写出像样的文档。轻量工具最大的善意就是不让用户为用不到的功能买单。5. 用了两个月的私房设置和小技巧5.1 把编辑器变成默认 .md 打开方式再加一个便携版先说最直观的一个设置把 .md 文件默认打开方式改成 LiteMark。这样我双击任何笔记文件半秒就能进入编辑状态不需要先开编辑器再去目录里找文件。这个习惯我用了两个月效率提升非常明显。我还会在 U 盘里放一份 LiteMark 的绿色版。去别的电脑临时写点东西、改个文档不用装任何东西插上 U 盘双击就能跑配置跟着文件夹走。这一点是很多大体积编辑器做不到的。有一次我去实验室的公共电脑上改实验报告现场没有安装权限就靠这个绿色版把文档弄完导出了 PDF那一刻我真心觉得轻量是对的。5.2 文件即笔记用 Git 还是网盘同步我最后的取舍LiteMark 的笔记就是一个文件夹里的普通 Markdown 文件没有私有数据库。这个设计看似原始其实对备份和同步特别友好。我用 Git 管理笔记每次写完用一个脚本自动 commit。换机器时 clone 一下仓库十几秒就恢复了。如果不想用 Git也可以直接把整个文件夹丢进坚果云或者 OneDrive 做同步。因为文件都是纯文本同步冲突的概率比笔记本软件那种私有格式低得多。我自己的做法是 Git 做主备份网盘做跨设备同步双保险。当然每个人习惯不同只要记住一点所有内容都是普通文件迁移成本几乎为零。这里有个细节如果使用网盘同步记得在同步文件夹里关掉 LiteMark 的自动生成临时文件功能或者在编辑器设置里把缓存目录改到系统临时目录避免网盘重复同步无意义的缓存文件。我第一次没注意结果网盘把一堆临时文件也传上去了白白浪费空间。5.3 公式编号、靠左显示和代码块高亮三个锦囊参考热词里经常有人问“公式编号怎么加”“Typora 公式怎么靠左”LiteMark 对这两个问题的处理方式我都试过块级公式末尾加\tag{数字}就能编号编辑器设置里的公式对齐方式改成 left 就能靠左。如果你写论文初稿公式编号基本够用不需要再开一个 LaTeX 环境。代码块高亮方面LiteMark 识别大部分主流语言只要在围栏代码块开头写上语言名就行。比如 python编辑器就会按 Python 语法高亮。支持的语言列表直接在设置里能看到C、Java、JavaScript、Go、Rust 这些常用语言都没问题。最后再说一个大忌不要在标题里用太多特殊字符。Markdown 标题中的 # 后面如果紧跟中文没加空格部分渲染器会识别失败。LiteMark 对这种情况做了容错但为了保险我还是习惯在 # 后面加一个空格这个习惯也建议你保持。类似的写列表时-后面也要留空格否则某些渲染器会把文字揉成一团。说实话我刚拿到 LiteMark 的时候以为它只是一个“小而美”的玩具用下来才发现它是真的在认真思考写作者需要什么。我现在写技术笔记的流程变得特别简单双击笔记、写、保存、导出 PDF四个动作完成一次写作。工具退到后台内容终于走到台前。如果你现在正被一堆插件折腾得心烦我愿意劝你试一下这种“一个插件都不用装”的轻量方案。最后再分享一个小技巧把编辑器的自动保存时间间隔设短一点我设的是 5 秒这样哪怕突然断电丢的内容也不过是最后一句没敲完的话。轻量工具配上一个稳当的保存习惯写作这件事真的可以变得很轻松。