说起 Markdown我和它的关系大概比大多数同事和朋友都要深一些。日常的笔记、技术文档、博客草稿、项目 Readme、甚至会议纪要我几乎全部用 Markdown 完成。每天早上打开电脑第一个碰到的工具就是编辑器晚上合上电脑前最后关掉的也是它。但就是这样一个每天相处超过八小时的工具我在很长一段时间里都处于一种勉强能用但总觉得哪里别扭的状态有的编辑器界面好看但功能太弱有的功能齐全但丑得让人不想打开有的既好看又强大却偏偏要联网或者收费订阅。用了一圈下来我决定干脆自己动手开发一款既好看又彪悍的 Markdown 编辑器。这篇文章就把我的开发动机、核心功能设计、技术选型思路以及实际开发中踩过的那些坑完整记录下来给同样折腾过 Markdown 工具的朋友一个参考。我自己对这款编辑器的定位很明确它不是一个玩具而是能真正扛住重度日常使用的生产力工具。所谓好看不是指皮肤多、动效炫而是指排版舒服、视觉层次清晰、长时间盯屏幕不累所谓彪悍是指 Markdown 里那些让人头疼的痛点——表格编辑、图片路径管理、数学公式、导出 PDF、大文档性能——都要有让人满意的解法。这篇文章既是我的项目复盘也是一个面向同类需求的完整参考。1. 为什么要自己动手市面编辑器解决不了的问题1.1 我和 Markdown 的日常一天八小时的使用场景先说一下我实际的使用场景。白天上班我会用 Markdown 写技术方案、接口文档、复盘记录这部分大概占两到三小时。晚上和周末我会把自己的一些想法整理成博客文章或者维护开源项目的文档这部分工作几乎全部依赖 Markdown。算下来我每天在 Markdown 文件上花的时间确实超过了八小时。在这样高频的使用下我对编辑器的要求会变得很具体。比如写文章时经常需要调整段落结构那么大纲视图和快捷折叠就很重要写技术方案时经常要贴代码块那么代码高亮和复制按钮就是刚需写文档时经常要插入截图那么图片的处理方式直接决定效率。这些需求单看都不难但叠加在一起市面上能同时满足的编辑器就很少了。还有一个容易被忽视的点工作流的一致性。我白天在公司的 Windows 上写文档晚上在家里的 Mac 上写博客周末可能在 Linux 服务器上临时改个文件。如果编辑器在不同系统上的表现不一致或者配置文件不互通体验就会大打折扣。这也是我考虑自己开发的一个重要原因——我想要一套完全由自己掌控的、跨平台体验统一的工具。1.2 现有编辑器的三个普遍痛点表格、图片路径、混合内容用过的 Markdown 编辑器不少从简单的文本编辑器加插件到功能全面的商业化软件各有各的短板。我归纳下来最影响体验的痛点集中在这三个。第一个痛点是表格编辑。Markdown 的表格语法本身就很反人类尤其是列数多、单元格内容长的时候。在纯文本里对齐竖线简直是一场噩梦稍微改一个字整个表格的行宽就乱了。虽然有些编辑器提供了表格可视化编辑但操作起来仍然笨重不够直接。第二个痛点是图片路径管理。写博客时图片通常要放在项目目录下而写笔记时图片可能要复制到笔记本的附件目录。不同的编辑器对图片的处理方式完全不同有的只支持粘贴到默认目录有的需要手动填路径有的会自动上传到图床但配置复杂。我经常遇到的情况是在这台机器上写的文档换到另一台机器上图片路径全变了整个文档的配图全部挂掉。第三个痛点是混合内容排版。这里的混合内容指的是文字、代码块、数学公式、流程图、表格混在同一篇文档里的情况。很多编辑器在某些单项上做得不错但一旦混合起来就容易出问题代码块里的特殊字符被转义了、数学公式渲染和代码高亮冲突、表格里塞代码块直接崩溃。真正重度使用的人一定会遇到这些组合场景而这些恰好是大多数编辑器测试覆盖最少的部分。1.3 我定义的好用标准三项基本原则经过长期使用和对比我给好用定下了三条基本原则。这三条原则后来直接指导了我自己的编辑器设计。第一输入不能有割裂感。写 Markdown 的时候我的思维应该集中在内容上而不是被工具打断。这意味着常用操作要尽可能少的快捷键要支持流畅的自动补全要有响应迅速的实时反馈。第二所见必须接近所得。虽然不是严格的 WYSIWYG所见即所得但预览效果应该和最终发布效果高度一致。最典型的情况是写博客的人用编辑器预览是一回事发布到网站上看到的又是另一回事。如果两者的排版差距太大写的时候就会心里没底。所以我要求编辑器的预览渲染结果能贴近主流的静态博客主题风格。第三文档应该是长期资产。这意味着编辑器生成的所有文件都应该是标准 Markdown 格式图片资源管理方式要清晰可控不能依赖某个编辑器特有的私有格式来保存数据。万一哪天编辑器不再维护了我的所有文档还能用任何工具正常打开、正常编辑。2. 好看从哪里来编辑器外观设计的三个层次2.1 第一层编辑区排版本身的质量很多人觉得编辑器好看就是皮肤好看换个字体换个配色就完事了。但真正的排版质量藏在一堆不容易察觉的细节里。首先是字体选择。中英文混排是 Markdown 文档最常见的场景但很多编辑器的中英文字体搭配非常随意中文用默认的宋体或者黑体英文用系统默认字体混在一起时基线不齐视觉上非常难受。我在这款编辑器里做了字体回退链和基线对齐优化中文使用思源黑体或者苹方英文用 Inter 或者 Source Sans Pro代码用 JetBrains Mono。三者之间有协调的字重和行高,长时间阅读眼睛不容易疲劳。其次是行距和段距。Markdown 的段落之间天然有间距但很多编辑器把行距、段距处理得过于紧凑或用太松。我边开发边测试参考了主流阅读类应用的行高比例最终把行距控制在字号的 1.7 倍左右、段距在行距的 1.2 到 1.4 倍之间并且对标题、列表、引用块分别设置了独立的间距参数。栏目页和预览页的差异尽量缩小这样切换时不会有明显的变形感。最后是排版细节的精细化。比如中英文之间自动加薄空格、标点符号的挤压、代码块的背景色与正文字号的比例、引用块的左边框颜色和宽度。这些细节单看都不起眼但组合在一起就是决定编辑器是否耐看的关键差异。2.2 第二层主题系统与沉浸模式界面外观的第二个层次是主题系统。市面上很多编辑器的主题只是换个背景色和文字颜色但真正好的主题应该能区分功能区域的视觉层级并根据使用环境自动调整。我的编辑器内置了亮色、暗色、护眼三套主题。亮色主题使用浅灰背景而不是纯白长时间看能轻微减少眩光感暗色主题不是简单把背景变黑而是采用深蓝灰色调配合降低饱和度的语法高亮避免在暗色环境下产生刺眼对比护眼主题给编辑区和预览区同时加了微暖的底色适合晚上长时间写作的场景。除了静态主题我还加入了一个很多人觉得没必要、但我觉得非常实用的功能沉浸模式。在这个模式下编辑区以外的所有 UI 元素自动隐藏页面居中当前段落高亮其他段落轻微半透明。写初稿的时候视线可以完全聚焦在当前要表达的内容上不会被侧边栏目录、文件树、状态栏干扰。这个模式我实际用下来效率提升非常明显尤其是写长文的时候。2.3 第三层细节动效与质感第三个层次是动效和质感。我平时对软件里的花哨动效是比较反感的但如果动效用得好它能起到很实际的辅助作用而不是纯装饰。我在编辑器里做的动效都很克制核心就三处一是光标所在行有一个极淡的背景高亮过渡动画持续时间在 150 毫秒左右不抢注意力但能帮你在多窗格布局里快速定位到当前编辑位置二是折叠区域展开和收起时有一个平滑的高度过渡这对阅读大纲时理解文档结构帮助很大三是打开文件时页面内容有一个轻微的淡入效果配合预渲染可以避免白屏闪烁。构建质感还有一个容易被忽略的点窗口布局的拖拽体验。三栏布局文件树、编辑区、预览区的分隔条宽度和拖拽响应速度直接决定了这个软件高级不高级的第一印象。很多编辑器分隔条只有 2 像素宽鼠标稍微偏一点就拖不动。我在开发时把分隔条调整到 5 像素的热区范围鼠标靠近时高亮提示拖拽时内容区域实时重排而不是等松手才刷新这个小改动让整个软件的手感提升了一大截。3. 彪悍体现在哪里核心功能设计与实现3.1 实时预览与 Markdown 解析引擎的设计实时预览是 Markdown 编辑器的核心功能但实现方式直接决定了编辑体验。市面上的编辑器主要分两派一派是滚动同步,编辑区和预览区是两个独立区域输入时通过监听滚动事件保持位置同步另一派是即时渲染编辑区本身就是渲染效果语法标记隐藏看到的就是渲染后的样子。这两派各有优劣我最初选了滚动同步方案原因很实际它对输入法的支持最稳定光标定位最可靠不会有光标漂移的问题。实时预览的关键在于解析引擎。我没有直接用现成的marked或markdown-it一把梭而是在markdown-it的基础上做了二次开发。为什么选它因为markdown-it的插件机制非常成熟而且它支持自定义渲染规则。我从一开始就知道会遇到数学公式、流程图、任务列表、脚注这些扩展语法用插件化的结构来组织这些扩展后续维护成本会低很多。解析引擎的性能是另一个硬指标。我处理的文档经常有几万字加上大表格和长代码块如果一输入就全量解析很容易卡顿。我采用的方案是分段解析把文档按标题层级切分成块每次编辑只重新解析被影响的那个块而不是整个文档。同时配合去抖策略输入过程中的中间状态不立即渲染等输入暂停 80 毫秒以后再统一渲染。这样在长文档里的输入流畅度能够接近纯文本编辑器的水平。3.2 表格编辑把 Markdown 最痛苦的部分变成可视化操作表格是 Markdown 语法里的重灾区。我在这款编辑器里花了不少精力在表格功能上目标只有一个让表格编辑像 Word 一样直观但同时保留 Markdown 的源码可控性。我的方案是在表格所在的段落范围内提供一个独立的类似电子表格的编辑浮层。当光标聚焦在表格区域时预览区会显示一个可编辑的可视化表格点击单元格可以直接输入内容支持按键切换单元格、回车换行、Tab 跳格。编辑完成后浮层会自动反算 Markdown 源码并把对齐用的空格重新排好。这个功能的实现难点在于解析和序列化的双向转换。先把表格的 Markdown 源码解析成二维数组把合并单元格、对齐方式也一并解析出来编辑时维护这个二维数组的状态编辑完成后再把数组序列化成对齐规整的 Markdown 表格源码。这里有个细节很多人手动写表格时会不舍得在空单元格里加占位空格导致表格渲染错位。我的序列化逻辑会在空单元格里自动补nbsp;和空格保证任何情况下渲染都不乱。我还在表格里加了一个非常实用的功能从 Excel 复制数据直接粘贴成 Markdown 表格。以前我从 Excel 复制一块数据粘贴到 Markdown 编辑器里大概率只是一堆用 Tab 分隔的纯文本。现在我的解析器会在粘贴时识别剪贴板里的表格数据格式自动转换成标准的 Markdown 表格语法。反过来我也可以一键把 Markdown 表格复制成 Excel 能识别的 TSV 格式。网上有人专门搜索markdown表格转换excel、markdown表格复制说明这个需求其实非常普遍。我做了这两个方向的转换实测下来大家反馈最多的就是表格相关的功能最实用。3.3 图片路径管理与粘贴上传图片路径问题是 Markdown 使用中最让人头疼的问题之一也是我自己开发时优先要解决的痛点。我的方案分为三层。第一层是运行时路径解析。编辑器在渲染文档时会智能解析图片的相对路径和绝对路径。如果图片路径相对于当前 Markdown 文件存在就直接使用如果相对于项目根目录存在也能正确解析如果磁盘上的实际路径和文档中写入的路径不一致编辑器会在不影响源码的前提下在预览时自动匹配最近的真实路径。这样即使文档是从别处拷贝过来的、图片路径已经变了预览也总能尽量显示正确的图片。第二层是粘贴时的自动处理。在编辑器里直接粘贴截图时可以选择把图片保存到与当前文档同级的assets目录、当前项目指定的图片目录或者统一上传到配置好的图床。保存时会自动生成时间戳加随机字符的文件名避免重名覆盖。如果保存成功编辑器会自动在光标位置插入对应的 Markdown 图片语法并且写入相对路径。第三层是路径失效检测。图片无法加载时编辑器会在预览区给出明确的占位提示显示目标路径并提供一个定位文件按钮让用户可以手动重新关联图片。这个功能在网上搜索markdown图片路径的问题帖里出现频率很高但很多编辑器都没有提供足够友好的处理机制导致用户经常要手动打开资源管理器去一张张检查图片路径。3.4 数学公式与代码块扩展语法的集成方式Markdown 的原始语法非常简单真正让它在技术圈流行的是社区扩展出来的各种语法数学公式、流程图、时序图、任务列表、脚注、划线等等。一个彪悍的 Markdown 编辑器必须把这些扩展语法一并处理好。数学公式这块我集成的是 KaTeX 而不是 MathJax。原因很实际KaTeX 的渲染速度比 MathJax 快非常多大概有数量级的差距。写公式密度大的数学文档时MathJax 很容易在快速滚动或者编辑时产生明显的渲染延迟但 KaTeX 几乎能做到瞬时渲染。虽然 KaTeX 的语法兼容性不如 MathJax 覆盖得广比如某些 LaTeX 的高级宏不支持但对日常写数学文档来说KaTeX 的覆盖范围已经足够。我在插件里做了兼容层把常见的\begin{aligned}、\over、\dfrac等语法做了转换处理实测下来大部分数学系的内容都能正常渲染。代码块的处理上我做了几个差异化功能。一是语言自动识别粘贴代码时可以自动检测语言类型并高亮二是代码折叠长代码块块级可以折叠成一个标题行方便快速浏览三是复制按钮预览区代码块右上角悬停时会出现复制按钮一键复制代码内容四是行号显示这个对技术文档尤其友好可以精确引用某一行代码。流程图这块我支持了 Mermaid 语法。但这里有个需要注意的事情Mermaid 本身有大量的渲染模式和配置项直接集成会让包体积变大加载变慢。我的方案是采用懒加载只有当文档里检测到 Mermaid 代码块时才动态加载渲染引擎平时不占用资源。这也符合我不为了做一个功能而拖累整体性能的原则。3.5 导出能力PDF、HTML、Word 三种输出路径Markdown 的价值不仅在于编辑体验更在于它能方便地转换成其他格式分享。我的编辑器在设计时就把导出功能作为核心能力来打造。导出 PDF 是我花时间最多的一项。常见的方案是直接用浏览器打印功能把 HTML 转 PDF但这样出来的 PDF 分页非常傻经常在代码块中间或者表格中间断页也很容易被浏览器打印样式的默认 margin 影响。我的方案是先将 Markdown 渲染成一套独立的打印优化 HTML再借助无头浏览器按自定义分页规则排版输出。这里的核心是 CSS 分页规则——我针对标题、表格、代码块分别设置了page-break-before和page-break-inside: avoid确保表格和代码块不会在中间被切断。同时支持自定义页眉页脚、页边距、纸张尺寸。导出 HTML 相对简单相当于把渲染后的内容加上一套内置的样式表打包输出。但我在这个功能里做了一个额外的设计导出的 HTML 是自包含的图片会被转成 Base64 嵌入 HTML这样即使对方没有网络也能正常打开看到全部内容。这个在处理会议纪要、分享给外部合作方时非常方便。导出 Word 则是通过 Pandoc 来做的。老实说这个功能我一开始觉得可有可无但后来发现实际需求很大。很多合作方那边还是以 Word 文档为标准交付格式所以我在工具内部集成了 Pandoc 的调用逻辑一键将 Markdown 转成带基础样式的 docx 文件。网上现在也有很多人用 Coze 这类工具搭建markdown转word工作流说明需求确实存在。我在实现时做了两级策略如果本地安装了 Pandoc就直接调用以获得最好的转换效果如果没有安装则退回到一个基于 HTML 转 Word 的兼容方案效果稍差但能保证输出可用。4. 技术选型与架构从零开发一个编辑器要用什么4.1 技术栈的选择Electron React TypeScript在选型阶段我认真考虑过原生桌面技术栈和跨平台框架的取舍。我的核心需求是跨平台——我日常在 Windows、macOS、Linux 三个系统之间切换使用如果为每个平台开发原生应用维护成本会成倍增长。所以跨平台框架是必然选择。最后我敲定的技术栈是Electron React TypeScript。Electron 虽然常被诟病内存占用大但它的成熟度和生态无可替代而且在做导出 PDF 这类需要无头浏览器的功能时Electron 内置的 Chromium 可以直接复用省去了很多打包分发的工作。React 负责 UI 层组件化的结构对编辑器的功能组织非常有帮助。TypeScript 则保证了这个项目在功能越来越多的情况下代码仍然可控、可维护。编辑器内核我使用了CodeMirror 6。选择它的原因是它在处理中英文混排、输入法组合态、大文档性能这些方面有着非常扎实的积累。CodeMirror 6 的设计很现代底层用纯函数式的 state 管理支持事务化地更新文档这对实现复杂的文档操作比如全局替换、格式化、批量图片路径修正非常友好。4.2 编辑器的三大部分编辑器内核、渲染管线、文件系统整个编辑器的架构可以粗略分为三大部分它们各司其职编辑器内核负责文本输入与编辑操作渲染管线负责将 Markdown 源码转换为可视化界面文件系统层负责与磁盘上的文件打交道。编辑器内核基于 CodeMirror 6主要处理光标管理、选区、自动补全、代码折叠、快捷键映射这些基础能力。渲染管线则是通过前面说过的分段解析引擎把 Markdown 源码解析为 AST再转为 React 组件树渲染成预览区。文件系统层负责文件的打开保存、目录树的读取监听、文件变动检测——如果文件在外部被修改编辑器会提示用户重新加载避免覆盖掉别处做出的修改。这三部分之间的通信协议是这条架构的关键。我定义了一套统一的消息总线所有跨层的操作都通过消息总线传递。比如用户在预览区的表格里编辑了一个单元格这个操作会生成一个表格更新事务通过消息总线传递给编辑器内核内核再以事务的方式更新文档源码。这样设计的最大好处是所有操作都是可撤销的并且撤销历史能追踪到预览区的可视化编辑操作。这一点很多编辑器做不到它们往往只是同步了视觉却破坏了撤销栈。4.3 性能优化大文档不卡的关键手段性能是重度用户最敏感的指标之一。一个几万字的文档如果在输入时明显掉帧或者打开时要卡顿几秒那么再好看的功能也会大打折扣。我在开发中花了大量时间做性能优化这里分享几个最有效的关键手段。第一个是虚拟滚动。预览区不是一次性把所有渲染出来的 DOM 节点都挂载上去而是只渲染可视区域和上下缓冲区域的节点。几万字的文档如果全部渲染DOM 节点数量会轻松破万浏览器滚动起来就是一个字卡。用虚拟滚动后任意时刻实际的 DOM 节点只有几十个滚动的流畅度和纯文本页面几乎没有区别。第二个是增量解析与缓存。我前文提到文档被切成块每次编辑只重新解析受影响的块。但还要配合一层缓存解析结果 AST 会按块缓存滚动到某个区域时直接取缓存不需要重新解析。只有真正发生编辑的块才会触发重新解析并且结果会同步更新缓存。第三个是渲染降级策略。当检测到当前设备的 CPU 或内存接近阈值时比如同时打开了多个大型文档编辑器会自动关闭一些非关键的视觉效果比如代码高亮的精细化模式、主题的动态过渡动画甚至自动降低预览的刷新率。虽然画面表现稍微降级但保证了输入和滚动不卡顿。对我来说能一直正常工作比偶尔飞快但经常卡死要重要得多。5. 开发过程中最容易踩的坑实测排错记录5.1 光标位置丢失CodeMirror 事务合并的边界开发编辑器的过程中第一个让我印象深刻的坑是光标位置丢失。具体表现是在预览区做了某个可视化操作之后切回编辑区光标突然跳到了文档开头或者根本不在原来的位置。排查过程是这样的我最初以为问题出在焦点管理上以为是预览区获取焦点后编辑区失去了光标上下文。但检查发现焦点一直保持在编辑区真正的原因是预览区发起的文档更新事务没有带上正确的光标位置信息。CodeMirror 6 的文档更新是通过事务来完成的事务可以指定selection字段但如果这个字段缺失或者指定了一个已经被消除的旧位置编辑器就会回退到默认位置通常是文档开头。找到根因后我的修复方案是在所有由预览区发起的事务里显式携带一个基于事务前后文档变化的位置映射对象。CodeMirror 6 提供了一个非常强大的changes.mapPos()方法可以把旧文档中的位置映射到新文档中的正确位置。我统一封装了一个更新方法凡是预览区的编辑操作都必须走这个封装确保光标位置永远被正确映射。这个问题修完之后我再也没遇到过光标跳回开头的情况。5.2 中文输入法组合态问题与 IME 处理第二个坑和中文输入法有关。在写 Markdown 文档时我最常输入的是中英文混合内容。在输入拼音的过程中编辑器如果错误地处理了组合态文字就会出现候选词闪现、文字重复、甚至光标乱跳的情况。这个问题的根源在于编辑器内核需要区分用户正在输入组合态和输入完成确认态两种状态。如果编辑器在组合态时就去更新文档模型相当于同一个拼音被当成了最终文字来处理自然会产生错乱。CodeMirror 6 对 IME 的支持整体上做得不错但在一些自定义插件里仍然有边界问题。我这里踩的坑主要出在我的自动补全插件上在输入拼音的过程中补全弹窗出现了但它选择补全项时错误地把提示内容插到了正在组合的拼音中间导致文字错乱。解决方案是给补全插件增加一个 IME 状态监听当检测到当前正在输入法组合态时自动关闭补全建议的插入功能等到确认输入之后再恢复。这个改动虽然小但对中文用户的体验提升非常明显。5.3 大型文档的渲染性能瓶颈虚拟滚动替换全量渲染第三个坑是大型文档的性能。最初版本上线后我用一篇三万字的技术文档做测试打开文件时发现要卡接近两秒滚动的时候也有明显掉帧。初步排查定位到问题在预览区的全量渲染。三万字渲染成 HTMLDOM 节点数超过了 1.5 万浏览器在构建和布局这些节点时就已经很吃力了。再加上我用了 React 来做 DOM 更新初次挂载和状态变更时的协调成本非常高。修复过程我写下来供参考先用 Performance 面板做了首字节到首屏的全链路分析发现 70% 的时间花在 DOM 构建25% 花在样式计算其余是 JavaScript 解析时间。确定瓶颈后我引入了虚拟滚动方案把预览区改造成了窗口化组件只渲染可视区域内的内容块并加上上下各 200 像素的缓冲区让快速滚动不会出现白屏。这个改造做完之后打开同一篇三万字文档的时间从 2 秒降到了 200 毫秒左右滚动的流畅度也基本和普通网站没有差别了。5.4 导出 PDF 的分页问题CSS Paged Media 实战导出 PDF 的功能也是踩坑重灾区最典型的问题是分页。最初我直接使用浏览器打印功能导出 PDF结果非常糟糕长表格被拦腰截断代码块从中间断开标题恰好落在页面底部内容和页眉压在一起。这些问题的本质是普通网页的 CSS 没有考虑分页这个维度而打印和 PDF 导出需要的是另一种样式系统——CSS Paged Media。修复方案的核心是三条 CSS 规则给表格和代码块设置break-inside: avoid内部不跨页断、给标题设置break-after: avoid标题和后面的内容保持在同一页、给列表项设置break-inside: avoid(避免列表项跨页断)。此外还需要处理页面边距的 margin-box 内容比如页码、文档标题、日期这些可以通过page规则来自动生成。这一步做完之后导出的 PDF 质量有了质的提升。但还有最后一个细节问题当单个表格超过一页时强制不跨页会导致表格被整体推到下一页前面留下大块空白。解决方案是在表格上设置允许跨页但重复表头的策略让表格在跨页时自动在下一页重新打印表头行。这个细节让我又花了一个周末调试但效果确实值得。6. 编辑器实测和主流工具的对比参考6.1 核心场景横向对比开发接近完成时我做了一轮横向对比测试。我选取了自己最常用的三个场景作为测试用例写一篇带大量代码块和公式的技术博客、整理一份混合了表格和图片的会议纪要、维护一个长期更新的项目文档仓库。以下是和其他主流编辑器的大致对比结果非严格性能测试仅供参考场景我的编辑器其他主流编辑器A即时渲染型其他主流编辑器B纯编辑型大文档流畅度流畅中流畅表格编辑体验可视化浮层方便支持但操作稍重纯源码编辑较差图片路径容错强自动匹配中弱数学公式渲染速度快KaTeX中部分用 MathJax不支持导出PDF排版好分页规则完善依赖系统打印不导出跨平台一致性好Electron受限于平台受限于平台离线使用完全离线部分支持完全离线6.2 意料之外的需求从搜索引擎热词看用户真实痛点在开发调试和收集反馈的过程中我特别关注了网上对 Markdown 相关的搜索关键词这些关键词直接反映了用户的真实痛点。搜索量比较高的几个关键词包括markdown换行、markdown 数学公式、markdown表格转换excel、markdown图片路径、markdown转word、 vscode用markdown转pdf 等等。这些搜索词背后是一大类被基础教程忽略的问题很多人学会了 Markdown 基础语法但一进入真实工作场景就卡住了。比如markdown换行——用过 Markdown 的人都知道在标准语法里单个回车是不会产生段落的换行的必须在行尾加两个空格或者用一个空行。这个语法设计对新人来说非常不直观我因此在编辑器的状态栏里加了一个实时的格式提示当检测到行尾有两个空格加回车的写法时会以视觉标记提示用户避免排版意外。markdown转word工作流和markdown pdf这类需求前面已经说过我在导出能力上做了针对性设计。而 markdown表格复制 这种搜索词恰恰印证了我做表格可视化编辑和剪贴板双向转换的方向是对的。搜索引擎里最常被搜索的问题往往就是用户在使用中摔得最惨的地方。6.3 编辑器内置的新手不犯错设计既然看到了这么多新手的痛点我在功能设计时就有意加入了几个防犯错的辅助机制这是很多编辑器没有的。第一个是完整的格式校验器。当文档里存在 Markdown 语法错误或者容易导致渲染问题的隐患时编辑器不会只给出一个笼统的错误提示而是精确定位到具体行告诉用户问题出在哪、标准语法应该怎么写。比如没关闭的代码块、未配对的数学公式分隔符、错误的表格列数。这个校验器不是阻塞式的而是以波浪线标记的方式在编辑区展示用户可以自己决定要不要修正。第二个是导出前的预览确认。用户点击导出 PDF 或者 Word 时编辑器会先展示一个导出预览面板以缩略图方式展示每一页的样子用户可以直接预览分页、检查是否有表格断裂、图片是否正常加载确认没问题再真正导出。这比导出后才发现问题节省了非常多来回折腾的时间。第三个是版本快照机制。我遇到过太多次意外覆盖的情况——源文件还在但自己不小心改错了内容又没有及时撤销回去。为此我做了一个轻量级的快照功能每五分钟自动保存一份增量快照可以回溯到任意时间点恢复内容。注意这不依赖任何云服务所有快照都存放在本地文件夹里保证数据始终掌握在用户自己手中。7. 开发之外的一些心得编辑器的主体功能做完了但开发和迭代的过程还在继续。这里说一些开发之外的经验可能会对想自己做类似工具的人有参考价值。关于做一款自己的工具这件事我最大的体会是需求量不一定要多大但一定要是你自己每天都用、而且用得很痛苦的场景。正因为是我自己每天在用每一个细小的摩擦都会被我感知到也正因为是自己要用我在解决这些痛点时才有足够的耐心去打磨。如果用的人少产品可能就没必要做了——这句话放在商业化产品上适用但放在个人工具上完全相反哪怕全世界只有你一个用户只要它让你每天的工作更舒服这个工具就值得做。对于技术栈的选择我的建议是优先选择自己最熟悉、社区最成熟的技术而不是盲目追新。Electron 和 CodeMirror 6 都是非常成熟的项目虽然它们不是那种酷炫的技术但稳定性和生态给了我非常大的确定性。做工具类产品稳定性就是最大的友好。最后分享一个小建议如果你也有自己动手开发工具的想法不用一开始就规划得特别宏大。我最初的需求其实只是想解决表格编辑和图片路径两个问题后来才一点一点扩展出了导出、主题、校验这些功能。工具是慢慢长出来的不是一次性设计出来的。先用最小方案解决自己的痛然后在实际使用中逐步迭代这是我认为最可持续的开发路径。