长期被插件折腾写文章的人可能都有过这样一个瞬间为了把一个 Markdown 文件渲染得“像个正经文档”先装 Markdown All in One再装 Preview Enhanced再装 Mermaid 图表预览顺手还要配一个 PDF 导出插件环境一崩半小时就没了。后来我换了一款打开就能写、公式图表搜索全内置的免费 Markdown 编辑器核心目录压缩后不到 10MB官方安装包因为带跨平台引擎会更大些但重要的是——一个插件都不用装。这篇文章就聊清楚它到底能做多深的事以及我实际用过几个月后遇到的各种状况。1. 从“插件全家桶”逃出来一个纯编辑器到底够不够1.1 我经历过的插件碎片化现场先交代背景。我长期在 Windows 和 macOS 之间来回换电脑写技术稿用 VS Code 当主力 Markdown 编辑器。最开始觉得挺好插件生态齐全什么都能干。可问题也恰恰出在这个“什么都能干”上。我常驻的插件至少有五个Markdown All in One 管表格和列表快捷键Markdown Preview Enhanced 负责渲染各种扩展语法Mermaid 预览插件用来画流程图mintlify 或 Markdown PDF 用来出 PDF另外还要装一个拼写检查。看起来分工明确实际用起来处处是隐患。最大的坑是渲染引擎冲突。Markdown Preview Enhanced 和 Mermaid 插件各自有内置渲染器升级其中任意一个另一个就可能在同一次预览里罢工。曾有一次升级后文档里的流程图全部变成乱码公式倒是正常查了半天才发现是插件版本不兼容而不是我语法写错。换电脑更烦虽然有同步配置文件但插件底层的二进制依赖、系统缺的字体到新机器上还是要从头调一遍。后来我想通一件事写 Markdown 的核心诉求是内容不是配置。如果有个编辑器能把公式、图表、搜索这些高频能力全部做进本体我为什么还要天天维护一套插件组合1.2 用一张表做选型为什么是 MarkText有了这个念头我先后试了 Typora、Obsidian、Zettlr最后长期留下的是 MarkText。下面这张对比表是我实际选型时的判断逻辑不一定代表所有人的需求但能说明方向。能力MarkTextTyporaObsidianVS Code 插件免费是需要付费个人免费免费数学公式内置 KaTeX内置需要插件需要插件Mermaid 图表内置内置需要插件需要插件全文搜索内置内置强需要扩展跨平台Win/macOS/LinuxWin/macOS/LinuxWin/macOS/Linux全平台零插件开箱即用很好好一般很多功能被拆到插件差Typora 的即时渲染是标杆但收费这一点对部分人不友好Obsidian 适合当知识库可它的高级能力基本都依赖社区插件更新换版本时插件容易掉链子VS Code 功能上限高却牺牲了写作的纯粹性。MarkText 的优势在于免费开源支持 Windows、macOS、Linux公式和图表原生支持而且默认就把搜索、文件管理、大纲做在一起。它可能没有 Obsidian 那套双链网络但对“专注写完一篇文档”这件事来说刚刚好。我记得第一次打开 MarkText新建一个.md文件输入几个公式代码块后渲染结果直接出现在屏幕上没有额外装一个包。那种“这本来就该这样”的感觉比拼插件列表舒服太多了。2. 公式不是“能显示”就行数学公式的原理与实操2.1 行内公式、块级公式和几种常用环境公式渲染是 Markdown 编辑器的硬门槛。很多编辑器要么不支持要么支持但渲染慢到位。MarkText 用的是 KaTeX 解析器和很多人熟悉的 MathJax 不是一回事。KaTeX 的最大特点是渲染速度快毕竟是纯前端异步排版写长文档时滚动不太卡顿。语法上行内公式用一对美元符号包起来块级公式用两对美元符号。比如“贝叶斯公式”这种常见内容我可以直接在正文里这样写行内公式$P(A|B)$ 块级公式 $$ P(A|B) \frac{P(B|A)P(A)}{P(B)} $$写完后立刻就能看到规范排版的分式。除贝叶斯公式日常写技术博客常用的公式我列了几个都是可以直接复制的求和公式 $$ \sum_{i1}^{n} i \frac{n(n1)}{2} $$ 排列公式 $$ A_n^m \frac{n!}{(n-m)!} $$ 组合公式 $$ C_n^m \frac{n!}{m!(n-m)!} $$有人可能要问这些在 Word 里用公式编辑器也能做何必非用 Markdown区别在效率。用 LaTeX 语法写公式手指不用离开键盘改一个符号就是按两下键而且所有内容都是纯文本进 Git 能审阅拷给别人能复用完全不用管格式层的东西。2.2 渲染引擎差异与公式排版避坑KaTeX 支持绝大多数 LaTeX 公式语法但也不是百分之百。以下是我实际踩过的几个点公式里的下划线_如果表示下标必须写成a_1但如果上下文是 Markdown 斜体标记某些环境会把_识别成强调符造成公式断裂。解决方法是给下划线两侧加空格或直接放在代码块里。矩阵和分段函数建议用\begin{matrix}、\begin{cases}这类环境MarkText 能渲染但不要指望它把array环境的所有参数都支持完整。公式编号是个老问题。MarkText 的公式没有像 Word 那样自动生成(1)、(2)的编号需要自己手动加标签或写编号文字。还有一次我写带偏导数的推导原计划用\begin{aligned}对齐多行公式。KaTeX 支持aligned环境但我漏写了\\换行符结果整个 block 只有一行排查半天才发现是手误。这类问题其实不是编辑器不行而是 LaTeX 语法根上的小坑多用几次就习惯了。如果只是偶尔写一两个公式哪个编辑器都够用。但如果是需要反复修改推导过程的长文KaTeX 在 MarkText 里的即时反馈节省的时间会非常明显。写错了马上能看到不用按一次 F5 等预览插件重新刷新。3. 免插件的图表功能流程图、时序图、甘特图一次说清3.1 四类高频图表和可复制的写法很多 Markdown 编辑器把图表能力外包给 Mermaid 插件但 MarkText 直接把 Mermaid 编译器内置了。这意味着我可以把一段文字描述转成可视化图形不用打开画图软件也不用为某个图表安装任何额外组件。我最常画的是流程图。比如描述“用户登录判断”逻辑写法非常直白graph LR A[开始] -- B{是否已注册?} B -- 是 -- C[登录] B -- 否 -- D[注册] D -- C编辑器里保存这段代码立刻会渲染成一张流程图节点、箭头、判断分支都有。如果我写技术方案要描述 API 调用过程时序图更合适sequenceDiagram participant 用户 participant 客户端 participant 服务端 用户-客户端: 输入账号密码 客户端-服务端: 发起登录请求 服务端--客户端: 返回 Token 客户端--用户: 展示登录成功项目排期和复盘文档里甘特图是王炸。以前我想在文档里放甘特图必须截图来自其他工具现在直接在 Markdown 里写gantt title 版本迭代排期 dateFormat YYYY-MM-DD section 需求阶段 需求评审 :2024-11-01, 5d 技术方案 :2024-11-06, 3d section 研发阶段 前端开发 :2024-11-09, 10d 后端开发 :2024-11-09, 12d另外还有个使用率挺高的饼图用来展示数据占比写法也不复杂pie title 用户设备分布 Windows : 55 macOS : 25 Linux : 20这些图形代码的共同特点是可版本管理、可复制、可搜索。相比截图一张 Mermaid 源码的维护成本低太多需求变了我改两行代码图就自动更新了。3.2 图表在博客、公众号和 PDF 中的表现差异内置图表也有它的边界用久了自然知道哪些地方得绕开。最典型的问题是导出。MarkText 内置的导出 PDF 工具遇到 Mermaid 图形时渲染引擎会把图形转成图片嵌入正常情况没问题。但如果图里中文文字较多或者节点文字太长生成的图片可能会轻微错位箭头指向不准确。我遇到过一张流程图里某个分支条件文字特别长导出后在节点左侧多出一截空白直接看预览没问题导出的 PDF 却明显不整洁。解决办法有两个一是给节点文字分段把长文本拆成短标签让图形简洁一些二是把 Mermaid 图单独导出成 SVG 或 PNG再贴到文档里。后者适合追求像素级精确排版的人。在公众号和博客平台也需要注意。公众号编辑器不吃 Markdown 还是 MarkText 的实时渲染需要先把图形导出成图片再粘贴支持 Markdown 的平台则可以直接粘贴源码让平台自己做渲染。顺便提一个与图表无关但很多新手在问的点Markdown 表格复制。MarkText 对表格的支持中规中矩支持快捷键插入行、列也支持在可视化界面里调整宽度。但如果你想从 Excel 复制多行数据进来不要直接粘贴容易把格式弄乱。我习惯先把表格转成 Markdown 源代码再贴或者用外部小工具把 CSV 转成 Markdown 表格语法这样干净很多。4. 搜索和大纲它把“找内容”做成了主要功能4.1 全能搜关键词直接打进正文文档一多最怕的不是写不出来而是写完了找不到。MarkText 的全文搜索不是简单搜文件名而是会把打开的文件夹里所有 Markdown 文件的正文进行一次扫描。我个人的使用场景是这样的工作目录下面放了几百篇技术笔记每篇几千字。某天我想找一篇讨论“贝叶斯公式”的文章又记不清标题只要打开全局搜索框输入“贝叶斯”结果列表会把正文含这个词的所有文件都列出来还带上下文预览。这一点比单纯搜文件名强太多特别是当我的文件名经常是“2024-11-3-临时草稿”这种鬼样子时正文搜索几乎是唯一解。搜索还支持按文件夹范围过滤或者直接搜当前文件内的所有内容。编辑器底部会显示匹配数量点击结果能跳到对应行。这种体验比我想象中稳因为搜的是原文纯文本不依赖任何索引服务也就不存在索引过期或者搜索不到新改内容的问题。4.2 不装图谱插件大纲就是最好的导航Obsidian 的图谱功能很炫但对我来说写长文时最需要的未必是关系图而是一个清晰的大纲导航。MarkText 的侧边栏默认把文档的标题层级抽出来做成一个可点击目录一级、二级、三级标题能折叠展开。我在写一万字左右的深度长文时基本流程是先在编辑器里把各级标题搭好框架然后看大纲面板判断文章节奏写到最后再回到大纲面板检查有没有层级混乱。这样折腾下来反而觉得比那些依赖插件生成的目录工具更顺手因为它本身就是编辑器内置的不额外占资源也不会出现“插件没启用目录就没了”的情况。4.3 和 Obsidian 相比差在哪里我必须说清楚MarkText 不是 Obsidian 的完全替代品。Obsidian 的核心竞争力是双链和知识图谱MarkText 没有这两样东西。如果你要建立一套复杂的个人知识库、需要反链面板、需要用 Dataview 做动态查询那 Obsidian 更合适。但反过来如果你只是需要一个轻量、专注、开箱即用的 Markdown 写作工具不常折腾插件MainText 的内置搜索和大纲已经覆盖掉我 90% 的需求。相比 Obsidian 时不时弹出来提示“某插件已更新需要重启插件”这种内置功能的安全感和稳定性高很多。5. 三个月使用后的翻车复盘三个方面让我差点换回旧流程5.1 翻车一公式导出 PDF 丢东西某次我把一篇带多个数学公式的文章导出 PDF整体渲染没问题但公式中的某些特殊字符尤其是希腊字母和一些偏科数学符号在 PDF 里显示成了方块或者直接消失。起因是系统的字体库缺少对应数学字体和 MarkText 本身关系不大但如果你不想折腾建议在操作系统里装一下支持数学符号的字体比如常用的 Latin Modern Math 或者 STIX Two Math。如果导出后还是有问题另一种稳妥做法是不直接拿 MarkText 导 PDF而是先在编辑器里把 Markdown 全文拷贝到支持 LaTeX 的流水线中用 Pandoc 转换。接口可能稍微多了两步但公式排版会更精确。说实话我现在习惯用前者应对简单文档遇到要交出去的重要稿件就直接走 Pandoc。5.2 翻车二Mermaid 中文标题排版乱了前面提过图表导出 PDF 的中文问题这里再展开一个更具体的场景。我在画项目甘特图时任务名称全都是中文MarkText 预览状态下效果正常可一旦把文档导出或者复制到其他平台某些图形渲染器对中文分词和字体支持不好导致任务条上的文字挤成一团。我的解决方式很土但有效任务名尽量用“中文短语 拼音缩写”的组合比如“需求评审(XQPS)”这样即使某个渲染器不支持中文标点读起来也还有辨识度。另一个技巧是控制节点标签长度从源头降低排版混乱的概率。5.3 翻车三大文件越用越慢性能与备份MarkText 对单文件很大的情况性能其实还算能打。我试过一个 10 万字的 Markdown 文件打开时间大约两三秒输入过程没有明显卡顿。但如果一个文件夹里同时放了几千个 Markdown 文件而且开了全局搜索编辑查找时可能会稍微有点慢。性能问题容易解决真正让我差点换回去的是备份。因为是纯文本我把整个 Markdown 文件夹放进 Git 仓库管理MarkText 不产生私有格式所有文件打开就能读。这一点非常重要——无论过了多久文件都不至于被锁定在某个工具的专有格式里。5.4 关于“不到 10MB”的大实话题目里写不到 10MB我必须诚实地补一句如果你直接去官网下载官方安装包里面带了 Electron 跨平台运行时体积不是 10MB 这个量级但是项目的核心代码和便携化构建目录确实可以做到非常小这也是很多开源版本和源码自行编译后的实际状况。我更推荐把注意力放在“一个插件都不用装”这件事上而不是单纯纠结于数字。带插件的编辑器没有原罪VS Code 到现在还是我处理代码和 JSON 的主力工具。但当我只想写一篇带公式、带图的文章时一个零插件、无弹窗、能专注写字的 Markdown 编辑器确实让工作流清爽了许多。要是你和我一样也被“配置编辑器”浪费时间困扰不妨给自己两周时间用这类内置型编辑器做一个实验。试过之后你可能就会明白有些功能嵌进本体才是它最好的归宿。
零插件Markdown编辑器MarkText深度评测：公式、图表、搜索全内置
长期被插件折腾写文章的人可能都有过这样一个瞬间为了把一个 Markdown 文件渲染得“像个正经文档”先装 Markdown All in One再装 Preview Enhanced再装 Mermaid 图表预览顺手还要配一个 PDF 导出插件环境一崩半小时就没了。后来我换了一款打开就能写、公式图表搜索全内置的免费 Markdown 编辑器核心目录压缩后不到 10MB官方安装包因为带跨平台引擎会更大些但重要的是——一个插件都不用装。这篇文章就聊清楚它到底能做多深的事以及我实际用过几个月后遇到的各种状况。1. 从“插件全家桶”逃出来一个纯编辑器到底够不够1.1 我经历过的插件碎片化现场先交代背景。我长期在 Windows 和 macOS 之间来回换电脑写技术稿用 VS Code 当主力 Markdown 编辑器。最开始觉得挺好插件生态齐全什么都能干。可问题也恰恰出在这个“什么都能干”上。我常驻的插件至少有五个Markdown All in One 管表格和列表快捷键Markdown Preview Enhanced 负责渲染各种扩展语法Mermaid 预览插件用来画流程图mintlify 或 Markdown PDF 用来出 PDF另外还要装一个拼写检查。看起来分工明确实际用起来处处是隐患。最大的坑是渲染引擎冲突。Markdown Preview Enhanced 和 Mermaid 插件各自有内置渲染器升级其中任意一个另一个就可能在同一次预览里罢工。曾有一次升级后文档里的流程图全部变成乱码公式倒是正常查了半天才发现是插件版本不兼容而不是我语法写错。换电脑更烦虽然有同步配置文件但插件底层的二进制依赖、系统缺的字体到新机器上还是要从头调一遍。后来我想通一件事写 Markdown 的核心诉求是内容不是配置。如果有个编辑器能把公式、图表、搜索这些高频能力全部做进本体我为什么还要天天维护一套插件组合1.2 用一张表做选型为什么是 MarkText有了这个念头我先后试了 Typora、Obsidian、Zettlr最后长期留下的是 MarkText。下面这张对比表是我实际选型时的判断逻辑不一定代表所有人的需求但能说明方向。能力MarkTextTyporaObsidianVS Code 插件免费是需要付费个人免费免费数学公式内置 KaTeX内置需要插件需要插件Mermaid 图表内置内置需要插件需要插件全文搜索内置内置强需要扩展跨平台Win/macOS/LinuxWin/macOS/LinuxWin/macOS/Linux全平台零插件开箱即用很好好一般很多功能被拆到插件差Typora 的即时渲染是标杆但收费这一点对部分人不友好Obsidian 适合当知识库可它的高级能力基本都依赖社区插件更新换版本时插件容易掉链子VS Code 功能上限高却牺牲了写作的纯粹性。MarkText 的优势在于免费开源支持 Windows、macOS、Linux公式和图表原生支持而且默认就把搜索、文件管理、大纲做在一起。它可能没有 Obsidian 那套双链网络但对“专注写完一篇文档”这件事来说刚刚好。我记得第一次打开 MarkText新建一个.md文件输入几个公式代码块后渲染结果直接出现在屏幕上没有额外装一个包。那种“这本来就该这样”的感觉比拼插件列表舒服太多了。2. 公式不是“能显示”就行数学公式的原理与实操2.1 行内公式、块级公式和几种常用环境公式渲染是 Markdown 编辑器的硬门槛。很多编辑器要么不支持要么支持但渲染慢到位。MarkText 用的是 KaTeX 解析器和很多人熟悉的 MathJax 不是一回事。KaTeX 的最大特点是渲染速度快毕竟是纯前端异步排版写长文档时滚动不太卡顿。语法上行内公式用一对美元符号包起来块级公式用两对美元符号。比如“贝叶斯公式”这种常见内容我可以直接在正文里这样写行内公式$P(A|B)$ 块级公式 $$ P(A|B) \frac{P(B|A)P(A)}{P(B)} $$写完后立刻就能看到规范排版的分式。除贝叶斯公式日常写技术博客常用的公式我列了几个都是可以直接复制的求和公式 $$ \sum_{i1}^{n} i \frac{n(n1)}{2} $$ 排列公式 $$ A_n^m \frac{n!}{(n-m)!} $$ 组合公式 $$ C_n^m \frac{n!}{m!(n-m)!} $$有人可能要问这些在 Word 里用公式编辑器也能做何必非用 Markdown区别在效率。用 LaTeX 语法写公式手指不用离开键盘改一个符号就是按两下键而且所有内容都是纯文本进 Git 能审阅拷给别人能复用完全不用管格式层的东西。2.2 渲染引擎差异与公式排版避坑KaTeX 支持绝大多数 LaTeX 公式语法但也不是百分之百。以下是我实际踩过的几个点公式里的下划线_如果表示下标必须写成a_1但如果上下文是 Markdown 斜体标记某些环境会把_识别成强调符造成公式断裂。解决方法是给下划线两侧加空格或直接放在代码块里。矩阵和分段函数建议用\begin{matrix}、\begin{cases}这类环境MarkText 能渲染但不要指望它把array环境的所有参数都支持完整。公式编号是个老问题。MarkText 的公式没有像 Word 那样自动生成(1)、(2)的编号需要自己手动加标签或写编号文字。还有一次我写带偏导数的推导原计划用\begin{aligned}对齐多行公式。KaTeX 支持aligned环境但我漏写了\\换行符结果整个 block 只有一行排查半天才发现是手误。这类问题其实不是编辑器不行而是 LaTeX 语法根上的小坑多用几次就习惯了。如果只是偶尔写一两个公式哪个编辑器都够用。但如果是需要反复修改推导过程的长文KaTeX 在 MarkText 里的即时反馈节省的时间会非常明显。写错了马上能看到不用按一次 F5 等预览插件重新刷新。3. 免插件的图表功能流程图、时序图、甘特图一次说清3.1 四类高频图表和可复制的写法很多 Markdown 编辑器把图表能力外包给 Mermaid 插件但 MarkText 直接把 Mermaid 编译器内置了。这意味着我可以把一段文字描述转成可视化图形不用打开画图软件也不用为某个图表安装任何额外组件。我最常画的是流程图。比如描述“用户登录判断”逻辑写法非常直白graph LR A[开始] -- B{是否已注册?} B -- 是 -- C[登录] B -- 否 -- D[注册] D -- C编辑器里保存这段代码立刻会渲染成一张流程图节点、箭头、判断分支都有。如果我写技术方案要描述 API 调用过程时序图更合适sequenceDiagram participant 用户 participant 客户端 participant 服务端 用户-客户端: 输入账号密码 客户端-服务端: 发起登录请求 服务端--客户端: 返回 Token 客户端--用户: 展示登录成功项目排期和复盘文档里甘特图是王炸。以前我想在文档里放甘特图必须截图来自其他工具现在直接在 Markdown 里写gantt title 版本迭代排期 dateFormat YYYY-MM-DD section 需求阶段 需求评审 :2024-11-01, 5d 技术方案 :2024-11-06, 3d section 研发阶段 前端开发 :2024-11-09, 10d 后端开发 :2024-11-09, 12d另外还有个使用率挺高的饼图用来展示数据占比写法也不复杂pie title 用户设备分布 Windows : 55 macOS : 25 Linux : 20这些图形代码的共同特点是可版本管理、可复制、可搜索。相比截图一张 Mermaid 源码的维护成本低太多需求变了我改两行代码图就自动更新了。3.2 图表在博客、公众号和 PDF 中的表现差异内置图表也有它的边界用久了自然知道哪些地方得绕开。最典型的问题是导出。MarkText 内置的导出 PDF 工具遇到 Mermaid 图形时渲染引擎会把图形转成图片嵌入正常情况没问题。但如果图里中文文字较多或者节点文字太长生成的图片可能会轻微错位箭头指向不准确。我遇到过一张流程图里某个分支条件文字特别长导出后在节点左侧多出一截空白直接看预览没问题导出的 PDF 却明显不整洁。解决办法有两个一是给节点文字分段把长文本拆成短标签让图形简洁一些二是把 Mermaid 图单独导出成 SVG 或 PNG再贴到文档里。后者适合追求像素级精确排版的人。在公众号和博客平台也需要注意。公众号编辑器不吃 Markdown 还是 MarkText 的实时渲染需要先把图形导出成图片再粘贴支持 Markdown 的平台则可以直接粘贴源码让平台自己做渲染。顺便提一个与图表无关但很多新手在问的点Markdown 表格复制。MarkText 对表格的支持中规中矩支持快捷键插入行、列也支持在可视化界面里调整宽度。但如果你想从 Excel 复制多行数据进来不要直接粘贴容易把格式弄乱。我习惯先把表格转成 Markdown 源代码再贴或者用外部小工具把 CSV 转成 Markdown 表格语法这样干净很多。4. 搜索和大纲它把“找内容”做成了主要功能4.1 全能搜关键词直接打进正文文档一多最怕的不是写不出来而是写完了找不到。MarkText 的全文搜索不是简单搜文件名而是会把打开的文件夹里所有 Markdown 文件的正文进行一次扫描。我个人的使用场景是这样的工作目录下面放了几百篇技术笔记每篇几千字。某天我想找一篇讨论“贝叶斯公式”的文章又记不清标题只要打开全局搜索框输入“贝叶斯”结果列表会把正文含这个词的所有文件都列出来还带上下文预览。这一点比单纯搜文件名强太多特别是当我的文件名经常是“2024-11-3-临时草稿”这种鬼样子时正文搜索几乎是唯一解。搜索还支持按文件夹范围过滤或者直接搜当前文件内的所有内容。编辑器底部会显示匹配数量点击结果能跳到对应行。这种体验比我想象中稳因为搜的是原文纯文本不依赖任何索引服务也就不存在索引过期或者搜索不到新改内容的问题。4.2 不装图谱插件大纲就是最好的导航Obsidian 的图谱功能很炫但对我来说写长文时最需要的未必是关系图而是一个清晰的大纲导航。MarkText 的侧边栏默认把文档的标题层级抽出来做成一个可点击目录一级、二级、三级标题能折叠展开。我在写一万字左右的深度长文时基本流程是先在编辑器里把各级标题搭好框架然后看大纲面板判断文章节奏写到最后再回到大纲面板检查有没有层级混乱。这样折腾下来反而觉得比那些依赖插件生成的目录工具更顺手因为它本身就是编辑器内置的不额外占资源也不会出现“插件没启用目录就没了”的情况。4.3 和 Obsidian 相比差在哪里我必须说清楚MarkText 不是 Obsidian 的完全替代品。Obsidian 的核心竞争力是双链和知识图谱MarkText 没有这两样东西。如果你要建立一套复杂的个人知识库、需要反链面板、需要用 Dataview 做动态查询那 Obsidian 更合适。但反过来如果你只是需要一个轻量、专注、开箱即用的 Markdown 写作工具不常折腾插件MainText 的内置搜索和大纲已经覆盖掉我 90% 的需求。相比 Obsidian 时不时弹出来提示“某插件已更新需要重启插件”这种内置功能的安全感和稳定性高很多。5. 三个月使用后的翻车复盘三个方面让我差点换回旧流程5.1 翻车一公式导出 PDF 丢东西某次我把一篇带多个数学公式的文章导出 PDF整体渲染没问题但公式中的某些特殊字符尤其是希腊字母和一些偏科数学符号在 PDF 里显示成了方块或者直接消失。起因是系统的字体库缺少对应数学字体和 MarkText 本身关系不大但如果你不想折腾建议在操作系统里装一下支持数学符号的字体比如常用的 Latin Modern Math 或者 STIX Two Math。如果导出后还是有问题另一种稳妥做法是不直接拿 MarkText 导 PDF而是先在编辑器里把 Markdown 全文拷贝到支持 LaTeX 的流水线中用 Pandoc 转换。接口可能稍微多了两步但公式排版会更精确。说实话我现在习惯用前者应对简单文档遇到要交出去的重要稿件就直接走 Pandoc。5.2 翻车二Mermaid 中文标题排版乱了前面提过图表导出 PDF 的中文问题这里再展开一个更具体的场景。我在画项目甘特图时任务名称全都是中文MarkText 预览状态下效果正常可一旦把文档导出或者复制到其他平台某些图形渲染器对中文分词和字体支持不好导致任务条上的文字挤成一团。我的解决方式很土但有效任务名尽量用“中文短语 拼音缩写”的组合比如“需求评审(XQPS)”这样即使某个渲染器不支持中文标点读起来也还有辨识度。另一个技巧是控制节点标签长度从源头降低排版混乱的概率。5.3 翻车三大文件越用越慢性能与备份MarkText 对单文件很大的情况性能其实还算能打。我试过一个 10 万字的 Markdown 文件打开时间大约两三秒输入过程没有明显卡顿。但如果一个文件夹里同时放了几千个 Markdown 文件而且开了全局搜索编辑查找时可能会稍微有点慢。性能问题容易解决真正让我差点换回去的是备份。因为是纯文本我把整个 Markdown 文件夹放进 Git 仓库管理MarkText 不产生私有格式所有文件打开就能读。这一点非常重要——无论过了多久文件都不至于被锁定在某个工具的专有格式里。5.4 关于“不到 10MB”的大实话题目里写不到 10MB我必须诚实地补一句如果你直接去官网下载官方安装包里面带了 Electron 跨平台运行时体积不是 10MB 这个量级但是项目的核心代码和便携化构建目录确实可以做到非常小这也是很多开源版本和源码自行编译后的实际状况。我更推荐把注意力放在“一个插件都不用装”这件事上而不是单纯纠结于数字。带插件的编辑器没有原罪VS Code 到现在还是我处理代码和 JSON 的主力工具。但当我只想写一篇带公式、带图的文章时一个零插件、无弹窗、能专注写字的 Markdown 编辑器确实让工作流清爽了许多。要是你和我一样也被“配置编辑器”浪费时间困扰不妨给自己两周时间用这类内置型编辑器做一个实验。试过之后你可能就会明白有些功能嵌进本体才是它最好的归宿。
