先说结论markdown在线编辑器这个事看着是小工具选型实际上是一整条渲染管线的设计问题。我最近在一个文档项目里做技术选型前后试了七八款在线markdown编辑器从开源的到商业的、从轻量预览到富文本混排的都有。最后项目上线倒是顺利但中间踩了一堆渲染管线相关的坑尤其是最后做md转PDF导出的时候那个跑版现场简直可以用“惨烈”来形容。今天把这段经历完整记录下来从编辑器选型到渲染细节再到PDF导出排障一次性讲透给准备做同类项目的朋友趟个路。先说说这个项目大概什么样。我们要做一个面向内部团队的在线文档系统用户打开浏览器就能编辑markdown左边写右边看写完一键导出Word和PDF还要支持历史版本。需求听起来不复杂但我实操下来发现markdown在线编辑器最麻烦的点从来不是“能不能编辑”而是“编辑器的渲染结果和最终导出结果能不能保持一致”。1. 在线编辑器先别挑花眼先看渲染管线1.1 为什么多个编辑器“看着差不多”却会导出不同结果很多人在选markdown在线编辑器的时候习惯先看界面好不好看、功能全不全比如支不支持表格、行内代码高亮、图片粘贴上传然后直接装一个就开始用。我最早也这样但后来被导出的PDF教育了一顿之后才明白markdown在线编辑器真正的分水岭不在UI层而在渲染管线。什么叫渲染管线就是markdown源文本从字符串变成浏览器里可见HTML的完整链路。拆开来看大致是这几个阶段markdown源文本经过解析器parser生成AST语法树再通过渲染器renderer转成HTML最后套上CSS样式呈现在页面上。整个链条里解析器决定“语法怎么理解”渲染器决定“HTML怎么生成”CSS决定“界面怎么展示”三者组合起来就是你最终看到的效果。我调研过的在线编辑器看起来功能差不多但底层解析器各不相同。有的是用marked做前端解析有的是用markdown-it有的用remark/rehype这套unified生态还有的是直接把本地编辑器那套解析逻辑搬到浏览器里。解析器的选择直接决定了GFM语法支持度、HTML转义策略、XSS防护能力和扩展灵活性而这些恰恰是后期最容易出问题的地方。所以我的建议是选markdown在线编辑器第一件事不是看demo而是去查它的底层解析器是什么、如何扩展、如何做安全过滤。你可以用一套同样的markdown测试文本去不同编辑器里跑一遍重点看表格、嵌套列表、任务列表、HTML混排、代码块高亮这几个场景差异一下就出来了。1.2 三类常见渲染管线和选型建议我按渲染管线的类型把市面上的markdown在线编辑器大体分成了三类各有各的适用场景没有绝对的好坏只有合不合适。第一类是纯前端预览型。这类编辑器在浏览器里做完整的解析和渲染常见的组合是CodeMirror或Monaco做编辑区marked或markdown-it做解析然后直接把HTML渲染到预览区。优点是轻量、部署简单、响应快离线也能跑缺点是解析和渲染能力受限于前端库复杂的文档结构、脚注、目录、自定义容器这些功能可能需要自己写扩展另外XSS防护需要特别注意。第二类是浏览器渲染与服务端处理混合型。编辑的时候前端做实时预览但最终导出和校验走服务端比如调Pandoc或其它的转换接口重新解析一遍。这类方案的优势是导出结果可控因为最终产物不是浏览器现场拼的而是服务端统一生成的跑版风险低。缺点是需要后端配合开发量相对大一点预览和导出可能因为两个解析器不同而出现细微差异。第三类是类本地编辑器型。比如把Typora、Obsidian那种本地体验搬到浏览器里特点是编辑即预览、看到的就是最终效果比如ByteMD、Vditor这些都是比较典型的方案底层用markdown-it做解析还封装了图表、数学公式、代码高亮这些能力。这类方案体验很好但定制时需要理解它的内部结构不然出了问题你都不知道是该改解析器还是改渲染层。选型建议上我的经验是如果只是个人博客后台之类的轻量场景第一类就够了如果是团队文档、需要稳定导出、对格式一致性有硬要求直接考虑第二类或第三类成熟方案别在解码器这种基础组件上自己造轮子。一个通用思路是把编辑器的“编辑能力”和“导出能力”解耦编辑用编辑器导出走独立渲染管线这样两边都能各自优化互不拖累。2. 渲染管线里我踩过的3个坑2.1 坑一CommonMark还是GFM解析器规则不一样结果就分叉第一个坑是我在一开始没有确认解析器遵循的是CommonMark规范还是GFM扩展规范导致同一个markdown文档在编辑预览和导出时出现了两套不同的渲染结果。CommonMark是markdown最基础的规范标准它定义的是最核心的语法比如标题、列表、引用、代码块这些。而GFM是GitHub在CommonMark基础上扩展的一套规范额外支持表格、任务列表、删除线、自动链接、脚注等这些日常高频的语法。很多在线编辑器默认只实现了CommonMark或者实现了部分GFM但没有完全对齐。我遇到的实际情况是用户在编辑器里用GFM语法写了一个带表格和任务列表的文档前端预览时表格和任务列表渲染得好好的但导出PDF的时候表格直接变成了文字堆在一起任务列表前面的复选框全部消失了。查到最后发现预览用的解析器对GFM支持度比较全而导出用的解析器只实现了CommonMark核心或者需要手动开启GFM插件没开启的情况下表格语法直接按普通段落处理了。这个问题的坑点在于你在界面上看到的预览效果不代表解析器“真的理解”了这段语法它可能是碰巧渲染对了。一旦走到导出管线换了一个更严格的解析器语法支持度不一致的问题就暴露出来了。解决办法有两条路。第一如果预览和导出用的是同一套解析器要确保两边配置一致特别是GFM扩展开关、HTML标签白名单、XSS过滤规则这些必须用同一份配置文件。第二如果预览和导出本来就是两个引擎那就需要建立一条统一的导出链路比如服务端用同一个解析器统一处理所有导出请求前端预览只负责展示这样能最大程度避免两边语法差异导致的结果分叉。我建议在项目初期就写好一组markdown覆盖测试用例把表格、任务列表、删除线、多级列表、行内代码、代码块、引用、图片、链接、HTML混排这些典型场景全覆盖在切换解析器或升级版本时直接跑一遍哪里有差异一目了然。这个测试文件我到现在还在用每次升级依赖都会先跑一遍省了不少事。2.2 坑二XSS过滤做错层预览区迟早出问题第二个坑是安全过滤的层级问题。markdown本身支持内嵌HTML这意味着如果你不处理用户写了一段script进去预览的时候就可能直接执行。在线编辑器做得再花哨这个口子不堵住终究是个隐患。最开始我图省事在渲染前做了一次全局过滤把script标签、onerror事件这些关键字都替换成空字符串。测试了几个常见攻击payload都没问题但后来同事反馈说预览卡顿我一看是有人在文档里写了一个嵌套的img srcx onerroralert(1)虽然onerror被替换了但属性名大小写变体、HTML实体编码、换行符插空等绕过方式还是能想办法穿透过滤。后来我仔细研究了一下markdown的安全过滤该怎么做结论是过滤必须放在渲染管线的正确层级而且要分层处理。首先是解析器这一层很多新版本解析器已经内置了安全开关或是过滤逻辑比如markdown-it自带的html: false选项可以把HTML标签直接转义其次是渲染器这一层推荐用一个独立的HTML消毒库例如DOMPurify这类方案对最终生成的HTML再做一次清洗白名单机制比黑名单可靠得多最后是服务端这一层如果文档需要持久化那么在服务端接收内容时也要做一次校验避免绕过前端直接写入恶意内容。这个事给我的教训是安全过滤不是写一个正则就能解决的它必须在整条链路上分层防守。尤其是预览区和导出区如果走的是两条渲染路径安全策略必须保持一致否则你辛辛苦苦堵住了预览区的洞导出PDF的服务端又把原来的HTML头头尾尾地拼回去等于白堵。2.3 坑三浏览器字体渲染偏差预览和导出白白不一样第三个坑跟编辑器本身关系不大但特别容易让人误以为是编辑器渲染的问题字体渲染不一致。markdown在线编辑器在浏览器里面预览时用的是浏览器默认字体栈和渲染引擎但导出PDF时如果走的是浏览器打印那套流程字体加载和排版逻辑又会变一个样子。我踩过的场景是文档里设置了一个自定义字体栈预览效果很正常字距、行高都很舒服结果导出PDF那个字体文件没加载出来回退到系统默认字体整个排版字距变大、行高变高明显“宽”了一圈表格列宽也跟着错位。这个问题的根源在于浏览器渲染网页时字体文件的加载、字体的度量、字距调整都是动态计算的但打印或导出PDF时很多浏览器会简化字体处理部分自定义字体如果没有嵌入或加载不及时就会回退到默认字体。另外不同操作系统、不同浏览器对同一字体的渲染也会有所不同macOS上看着很舒服的排版放到Windows的Chrome里导出就可能完全不同。解决办法是预览和导出的CSS最好分开处理。预览时可以做得花哨一点导出的CSS要收敛用系统自带的常见字体栈同时把字体文件通过font-face嵌入并明确设置font-display: block确保字体加载完成后再渲染。另外导出的样式建议用固定宽度布局比如width: 210mm配合合适的margin而不是直接用页面宽度的百分比这样不同屏幕下导出来的结果相对可控。我还注意到一个问题行高和字体大小使用em或rem这类相对单位会比px更适合导出场景因为它们在字号映射时可以等比缩放。如果写死了px在打印缩放比例调整时很容易出现文字重叠、行距异常的问题。3. md转PDF跑版记录从分页错乱到稳定输出接下来说说这次项目里重头戏——md转PDF。实际上编辑器选型和渲染管线那些坑大多还停留在“开发调试期”真正让我连续加班的是导出PDF的跑版问题。3.1 第一次试直接打印页面表格被截断的惨状最开始我图省事直接用浏览器的打印功能把预览区的页面整体打印成PDF。听起来很简单对吧操作路径就是用户预览完右键打印选择“另存为PDF”。结果一测试就傻眼了问题一堆。第一个问题是分页。文档超过一页之后第二页会从预览区的任意位置“随机”断开完全没有分页概念。表格如果有十几行可能从中间劈开列宽全乱了有些单元格的文字直接跑到页面外面去。代码块也一样有些前后几十行的代码块会被硬生生截断一行代码被切成两半一半在上一页一半在下一页根本没法看。第二个问题是比例不对。预览的时候内容占满屏幕到打印预览里内容突然变得特别小或者特别大需要手动调整缩放比例。用户不可能每次导出都自己调一遍比例这不现实。第三个问题是背景色丢失。代码高亮的背景色、提示框的背景色在打印预览里全变成了白色视觉效果差很多。后来查了一圈才发现浏览器打印默认不打印背景色和背景图需要在CSS里显式设置-webkit-print-color-adjust: exact或者print-color-adjust: exact才能把背景色带出来。这次尝试让我意识到直接用预览页面打印是行不通的。预览页面的CSS是为了屏幕优化过的屏幕和纸张的尺寸、分辨率、排版逻辑都不一样硬套只能是惨不忍睹。3.2 方案BChromium无头浏览器固定输出最终采用放弃浏览器手动打印之后我转向了用Chromium无头浏览器来做PDF导出。思路很简单服务器端启动一个无头浏览器把markdown先渲染成HTML页面然后调用页面打印接口例如Puppeteer的page.pdf()接口直接导出PDF。这个方案当时我评估了几种决定用它主要理由是渲染结果和预览效果最能保持一致毕竟都是Chromium内核在解析排版。不过用无头浏览器导出一样会遇到分页和跑版问题只是你有了完全可控的CSS和参数可以系统性地解决。我最终采用的导出参数表格大概是这样的参数设置值说明formatA4固定纸张大小避免默认Letter带来的尺寸差异printBackgroundtrue打印背景色代码高亮不丢margintop 15mm, bottom 15mm, left 12mm, right 12mm统一页边距避免内容贴边preferCSSPageSizetrue优先使用CSS中page定义的页面尺寸scale1固定为1让导出尺寸和设计尺寸一致还有一个容易被忽略的问题page.pdf()的scale参数默认是1但如果CSS里写了缩放或页面宽度特别大导出时还是可能出现比例变化。固定scale为1并确保页面宽度和A4宽度一致可以避免大部分比例跑偏的问题。再说分页。纯markdown渲染出来的文档最容易在表格、代码块、图片这些大型元素上断页。我用CSS做了这几个规则第一表格和代码块整体不拆行用了break-inside: avoid让它们尽量作为一个整体出现在同一页避免被拦腰截断。第二标题后面紧跟段落时避免标题出现在页面最底部、正文跑到下一页用了break-after: avoid。第三列表项内部避免分页防止一个列表项的内容被拆成两页。实际做下来这几个规则基本能覆盖90%以上的跑版场景。剩下的零星情况我用一个“元素高度预检测”的思路来解决导出前先用无头浏览器量一下需要处理的大元素的实际高度如果接近或超过当前页剩余空间就在它前面自动插入分页符。3.3 中文、代码块、emoji这些细节处理导出PDF除了整体的分页还有一堆细节问题每一个都能让你头疼。这里挨个说清楚。中文换行是我遇到的第一个奇葩问题。默认情况下中文长单词比如URL、文件名如果太长浏览器可能不会自动换行导致内容溢出到页面border之外。我给正文和代码块都加了word-break: break-word和overflow-wrap: break-word让长字符串在合适的位置断行总算解决了溢出问题。代码块的细节更多。默认的无头浏览器导出代码块的字体大小、行高如果和正文不一致整体会显得特别乱。我干脆给代码块单独设置了固定的字号和行高让它和正文形成清晰的层级关系。还有一个小细节代码块里面如果有特别长的行横向滚动是没用的因为打印出来没有滚动条所以要么自动断行要么在导出前做行内容截断处理我选择了自动断行方案至少内容不丢。emoji这个问题更坑。Windows和macOS上看到的emoji字体不一样有些emoji字符在无头浏览器里渲染不出颜色直接变成黑白方块。我查了一圈最终的方案是给PDF导出页面引入一套独立的emoji字体比如Noto Color Emoji并在字体栈里把它放在靠前的位置让这些符号固定使用同一套字形渲染。这样至少能保证所有用户看到的PDF是同一副面孔。图片也是个容易翻车的地方。如果markdown里引用的是外链图片导出时无头浏览器需要等待图片加载完成否则PDF里就是一堆破图图标。我用的是page.waitForSelector配合网络空闲等待确保图片全部加载完再触发打印。如果图片是base64嵌入的倒没这个问题但是PDF体积会变大不少需要根据实际情况权衡。最后还有一个经常被忽略的细节页脚和页码。很多内部文档都要求每页带页码和文档标题我一开始没做后来被要求补上才意识到page.pdf()默认自带的页眉页脚丑到没法看。后来我改用了CSSpage的margin box来自定义页眉页脚比如bottom-center显示页码top-left显示文档标题效果比默认的好得多。4. 高频问题排查表和个人心得4.1 常见问题速查表整个项目做下来我把团队成员反馈最多的问题整理成了一个速查表基本覆盖了markdown在线编辑器到PDF导出这条链路里九成以上的坑。你可以直接收藏遇到问题对照排查比自己瞎试快多了。现象可能原因排查思路预览正常导出PDF表格乱预览和导出用不同解析器GFM开关不一致统一两边解析器配置建覆盖测试用例代码块被拦腰截断未设置break-inside: avoid给pre加避免分页样式必要时手动分页导出PDF背景色全丢未启用打印背景色设置printBackground: trueCSS里加print-color-adjust字体和预览时明显不同自定义字体未嵌入或加载失败采用系统字体栈或用font-face嵌入字体并等待加载长URL或文件名溢出页面缺少换行规则给正文和代码块加word-break和overflow-wrap中文引号或特殊符号变方块字体不支持对应字形引入通用字体或emoji字体调字体栈顺序导出PDF页码位置不对自定义页眉页脚覆盖不完整用pagemargin box统一定义页眉页脚打印时行高突然变小字体度量变化导致行高计算不一致相对单位替代固定px配合固定缩放比例图片导出后是空白或破图图片加载未完成就触发打印等待图片加载再导出或用base64内嵌表格列宽在打印时错位表格没有固定布局按内容自适应给表格设置合适的table-layout和列宽规则预览区和PDF的行间距观感差异很大屏幕和纸张的渲染上下文不同将预览和导出的CSS分离导出用精简样式PDF文件体积异常大大量base64图片或字体被嵌入图片适当压缩字体按需子集化4.2 我的一些操作心得项目收尾阶段我重新把整套系统梳理了一遍有一些偏方法论层面的体会这里记录一下。第一把“预览渲染”和“导出渲染”从最开始就当成两条独立的管线来设计。不要想着“预览能用就行导出的时候再说”这个想法的代价就是后期无尽的兼容性补丁。预览管线可以追求实时性、丰富性导出管线要从一开始就追求确定性、稳定性。两者可以共享同一套markdown解析结果但CSS、安全策略、资源加载策略尽量分开维护。第二所有踩过的坑最终值得沉淀成自动化的覆盖测试。我写的那组markdown覆盖用例后来直接集成到了CI流程里每次升级解析器、调整CSS、更换导出版本都会自动跑一遍再也没出现“昨天还能导出今天突然跑版”的灵异事件。测试用例里除了常规语法一定要放几个极限情况比如超长表格、超长代码、满屏emoji、混合中英文的超长字符串这些才是跑版的重灾区。第三如果项目允许给用户保留手动微调导出设置的能力。比如页面边距、字号缩放、是否打印背景这些选项让你的工具至少能兜住一些莫名其妙的边缘情况。用户本来就是拿你导出的PDF去交差或者归档的他至少应该有个最后救命的旋钮。第四无头浏览器这份方案稳定性和性能是可以接受的但要做好资源回收。如果导出请求很频繁尽量复用浏览器实例而不是每个请求都启动一次不然内存飙起来服务挂了反而更麻烦。这次从选型到上线最大的感受是markdown在线编辑器本身没那么难选难的是你选完以后怎么保证整个“编辑—预览—导出”的闭环在各种真实场景下都稳。每一个看起来一两行就能配置好的选项背后都是一整套渲染工程的问题早一点把它想清楚后面你会感谢自己。