1. 这不是个“要不要重渲染”的问题而是流式场景下文本语义连续性的生死线你有没有遇到过这样的情况前端页面正在用 marked 渲染一段用户实时输入的 Markdown 内容比如聊天窗口里的消息、协作编辑器里的草稿、或者一个带预览的写作面板——刚敲下**加粗开始还没来得及补上两个星号闭合预览区就炸了整段文字变成纯文本甚至后面所有内容都错位、丢失样式连br都没渲染对更糟的是后端用 marked 做流式日志解析时某条日志末尾卡在、code才能构建 AST一旦输入被截断在任意位置它要么报错中断要么强行“猜”语义结果就是标签错配、嵌套失衡、HTML 输出不可控。这个问题影响范围远超表面它直接决定你的编辑器是否卡顿、协作系统是否丢数据、AI 生成内容能否安全嵌入、日志平台能否准确高亮、甚至影响 SSR 渲染首屏的稳定性。我见过三个真实案例某 SaaS 客服系统因流式渲染崩溃导致会话中断率上升 17%某开源笔记应用因未处理引用块截断造成用户误删整段内容某 DevOps 平台的日志预览页在解析含 mermaid 代码块的流水线日志时因~~~mermaid开头被截断触发 marked 的 fallback 机制把后续所有日志当 mermaid 语法解析最终页面白屏。所以这不是“能不能用 marked”的问题而是“如何让 marked 在非理想输入下依然可控”的工程实践问题。2. 为什么“全部重渲染”是饮鸩止渴从 marked 的解析机制说起2.1 marked 的工作流本质单次、完整、状态不可逆的编译过程marked 的核心设计哲学是“一次编译全程可信”。它内部执行的是典型的三阶段流程Lexer → Parser → Renderer。Lexer 负责将原始字符串按规则切分成 tokens如text,emphasis_open,link_start,code_blockParser 将 tokens 组织成 AST抽象语法树Renderer 再将 AST 转为 HTML。这个流程的关键在于每个阶段都假设输入是语法完整的且 tokens 序列是自洽的。举个具体例子当你传入**hello world**Lexer 会输出[emphasis_open, text, emphasis_close]三个 tokenParser 检测到emphasis_open和紧随其后的emphasis_close就能安全地构造一个strong节点。但如果你只传入**hello world少了一个*Lexer 仍会尝试匹配可能输出[emphasis_open, text]而 Parser 在遍历完 tokens 后发现emphasis_open没有配对的emphasis_close就会触发emphasize规则的 fallback —— 把**当作普通文本hello world也当普通文本最终输出p**hello world/p。这看起来“没崩”但问题藏在更深处如果后续追加*你得到的不是**hello world*而是**hello world*多了一个星号因为第一次渲染已把**固化为文本第二次渲染无法“回溯”修正。提示marked 默认不抛错而是静默降级处理截断语法这比直接报错更危险——它让你误以为“还能用”实则埋下数据污染隐患。2.2 流式场景下的三大不可逆损耗“全部重渲染”方案看似简单实则在流式场景中造成三重损耗第一重DOM 重绘风暴。每次输入变化哪怕一个字符你都调用marked.parse(input)生成全新 HTML 字符串再用innerHTML替换整个预览容器。这意味着浏览器必须销毁旧 DOM 树重建新树触发 layout paint所有事件监听器如点击链接、hover 代码块全部丢失需重新绑定滚动位置重置用户正在看的段落瞬间跳走对于长文档500 行单次重渲染耗时可达 80–120ms输入延迟肉眼可见。第二重状态丢失与上下文断裂。marked 解析是无状态的——它不记录“上一次解析到哪”也不保存“当前 open 的 blockquote 深度”。例如用户输入 第一行 第二行当输入到 第一行时marked 渲染为blockquotep第一行/p/blockquote当追加\n 第二行你重渲染整个字符串marked 会正确识别为两个p在同一个blockquote下但若用户中间停顿输入 第一行\n仅换行marked 会把\n当作段落结束生成blockquotep第一行/p/blockquotep/p此时 第二行的缩进上下文已丢失后续追加内容无法正确嵌套。第三重内存与计算资源浪费。marked 的 Lexer 是正则驱动的对长字符串做全量扫描。假设用户编辑一篇 3000 字的文档每秒输入 5 个字符你每秒调用 5 次marked.parse()每次都要对 3000 字符做完整词法分析——其中 99% 的内容和上一次完全相同。这就像每次开车都把整辆车拆开检查螺丝而不是只换磨损的轮胎。2.3 真正的解法方向增量解析 语义缓存 上下文保持绕过“重渲染陷阱”的核心思路是把 marked 从“编译器”角色转变为“增量修补器”。这需要三层能力增量解析层只分析新增/修改的字符区间定位受影响的语法单元如哪个**开始/结束被改动AST 缓存层保存上一次解析生成的 AST 节点标记每个节点对应的源码位置start/end index支持局部更新上下文保持层维护解析状态机如当前是否在 code block 内、嵌套的 blockquote 层数、list item 的缩进栈让新输入能延续旧状态。这并非天方夜谭。VS Code 的 Markdown 预览、Typora 的实时渲染、Obsidian 的编辑器内嵌预览底层都实现了类似机制。它们的共同点是绝不把 marked 当黑盒调用而是深度介入其 Lexer 和 Parser 的生命周期。比如 Typora 会预扫描输入识别出、---、等 block-level delimiter 的起始位置只对 delimiter 区间内的内容做 marked 解析区间外的内容直接复用旧 AST。3. 实战方案手把手实现一个抗截断的流式 Markdown 解析器3.1 方案选型为什么选择 marked 的 Lexer 自定义 Parser而非重写市面上有多个 Markdown 解析器remarkAST 优先、markdown-it可插件化、commonmark严格规范。我最终选择基于 marked 的 Lexer 进行二次开发原因很实际生态兼容性公司已有大量 marked 的 renderer 定制如自定义 emoji、数学公式、mermaid 图表直接复用可省去 200 行适配代码性能基线可靠marked 的 Lexer 经过十年迭代正则优化成熟对中文标点、emoji、URL 的处理稳定调试友好marked 的源码注释清晰token 类型命名直白codespan,fences,heading便于定位问题。关键决策点不替换 marked而是“包裹”它。我们保留marked.Lexer和marked.Parser的实例但拦截其输入/输出注入流式逻辑。这样既利用 marked 的语法覆盖能力支持 GFM、tables、footnotes又规避其单次编译缺陷。3.2 核心架构三层缓冲模型Buffer Layer我们设计一个StreamingMarkdown类包含三个核心 bufferBuffer 名称存储内容更新时机作用sourceBuffer原始输入字符串含未完成语法用户输入时追加作为所有解析的唯一数据源astBufferAST 节点数组每个节点含start/end字段初次解析或增量更新后提供 DOM 更新的最小粒度stateBuffer解析状态对象{ inCodeBlock: false, blockquoteDepth: 0, listStack: [] }Lexer 扫描时实时更新保证跨 chunk 的语法连续性初始化时sourceBuffer astBuffer []stateBuffer { inCodeBlock: false, ... }。当用户输入新字符流程如下将新字符追加到sourceBuffer计算本次变更的deltaRange { start: prevLength, end: sourceBuffer.length }调用lexer.scanDelta(sourceBuffer, deltaRange, stateBuffer)只扫描 delta 区间及前后 50 字符防跨行截断根据扫描结果定位受影响的 AST 节点如deltaRange覆盖某个emphasis_opentoken则其 parent node 需重解析对受影响节点及其子树调用parser.parseTokens(tokens)生成新 AST 片段合并新旧 AST更新astBuffer调用renderer.render(astBuffer)生成增量 HTML仅 diff 部分。注意scanDelta不是 marked 原生方法需我们扩展 Lexer。原理是先用marked.Lexer.prototype.block的正则匹配 block-level 结构如、#、-再用marked.Lexer.prototype.inline匹配 inline 结构如**、[]()但限制扫描范围为deltaRange.start - 50到deltaRange.end 50并传入stateBuffer作为上下文。3.3 关键代码实现抗截断的 Lexer 扩展以下是scanDelta的核心逻辑TypeScript// 扩展 marked.Lexer class StreamingLexer extends marked.Lexer { // 保存上次扫描的 block-level delimiter 位置 private blockDelimiters: Array{ type: string; start: number; end: number } []; scanDelta( src: string, deltaRange: { start: number; end: number }, state: ParsingState ): Token[] { // 步骤1确定安全扫描范围——向左扩展至最近的 block delimiter向右扩展至下一个 block delimiter const safeStart Math.max(0, this.findSafeStart(src, deltaRange.start)); const safeEnd Math.min(src.length, this.findSafeEnd(src, deltaRange.end)); // 步骤2提取安全范围内的子字符串 const safeChunk src.slice(safeStart, safeEnd); // 步骤3重置 Lexer 状态注入当前 state this.state { ...state }; // 步骤4调用原生 block lexer但只处理 safeChunk let tokens: Token[] []; try { tokens this.block(safeChunk); } catch (e) { // 截断时捕获错误返回空 tokens避免崩溃 console.warn(Block lexer failed on chunk, returning empty tokens); tokens []; } // 步骤5对每个 token修正其 start/end 位置原生 lexer 返回的是 chunk 内偏移 return tokens.map(token ({ ...token, // 将 chunk 内偏移转为全局偏移 start: token.start safeStart, end: token.end safeStart, // 标记是否为新生成用于后续 AST 更新判断 isNew: token.start deltaRange.start token.end deltaRange.end })); } private findSafeStart(src: string, pos: number): number { // 向左找最近的 block delimiter, #, , ---, *** 等 const blockRegex /^(\s*|\s*#{1,6}\s|\s*[\s\S]*?|\s*-{3,}|\s*\*{3,})$/m; let i pos; while (i 0) { const lineStart src.lastIndexOf(\n, i - 1) 1; const line src.slice(lineStart, i); if (blockRegex.test(line.trim())) { return lineStart; } i lineStart - 1; } return 0; } private findSafeEnd(src: string, pos: number): number { // 向右找下一个 block delimiter 或文件尾 const nextNewline src.indexOf(\n, pos); if (nextNewline -1) return src.length; const lineEnd src.indexOf(\n, nextNewline 1); const nextLine lineEnd -1 ? src.slice(nextNewline 1) : src.slice(nextNewline 1, lineEnd); const blockRegex /^(\s*|\s*#{1,6}\s|\s*|\s*-{3,}|\s*\*{3,})$/; if (blockRegex.test(nextLine.trim())) { return nextNewline; } return lineEnd -1 ? src.length : lineEnd; } }这段代码的精妙之处在于findSafeStart和findSafeEnd它不盲目扫描整个字符串而是以 block-level 结构为锚点划定最小安全解析范围。例如当用户在 第一行后输入\n 第二行deltaRange是{ start: 12, end: 25 }\n 第二行的位置findSafeStart会找到的起始行位置 0findSafeEnd会找到下一个\n位置 25于是只扫描 第一行\n 第二行这 25 个字符而非整个文档。这使解析耗时从 O(n) 降至 O(Δn)Δn 通常 100。3.4 AST 缓存与增量更新如何只重绘被改动的 DOM 节点AST 缓存的核心是Node接口的扩展interface StreamingNode extends marked.Token { // 原生 marked.Token 字段 type: string; raw: string; text?: string; // 新增字段 start: number; // 在 sourceBuffer 中的起始位置 end: number; // 在 sourceBuffer 中的结束位置 domId: string; // 对应 DOM 节点的唯一 ID用于 diff children?: StreamingNode[]; // 支持嵌套 } // AST 更新算法 function updateAst( oldAst: StreamingNode[], newTokens: Token[], source: string ): StreamingNode[] { const newAst: StreamingNode[] []; let oldIndex 0; for (const token of newTokens) { // 步骤1查找 oldAst 中是否有 start/end 完全匹配的节点 const matchedOld oldAst.find(node node.start token.start node.end token.end ); if (matchedOld) { // 完全匹配复用旧节点保留其 domId 和事件绑定 newAst.push(matchedOld); oldIndex oldAst.indexOf(matchedOld) 1; } else { // 未匹配创建新节点 const newNode: StreamingNode { ...token, start: token.start, end: token.end, domId: node-${Date.now()}-${Math.random().toString(36).substr(2, 9)} }; newAst.push(newNode); } } // 步骤2将 oldAst 中剩余的节点未被 newTokens 覆盖的追加到 newAst // 这些是未改动的节点如前面的段落、后面的代码块 newAst.push(...oldAst.slice(oldIndex)); return newAst; }这个算法确保未改动的节点如## 标题、前面的 引用的domId不变DOM diff 时直接复用新增节点如新输入的**加粗**获得新domId触发插入被截断后修复的节点如从**text变为**text**因end位置变化被视为新节点触发替换。最终渲染时我们不调用innerHTML而是用document.getElementById(domId).outerHTML newHtml只更新变动节点。实测一篇 1200 字文档单字符输入的平均更新耗时从 92ms 降至 14ms滚动位置保持率从 38% 提升至 99.7%。4. 标签截断的 7 类高频场景与针对性防御策略4.1 场景一Inline 语法截断**,__,*,_典型截断**bold、*italic、_underline、~~strikethrough~~少一个~风险Lexer 将**当作普通文本Parser 无法建立strong节点后续**无法配对。防御策略延迟解析 超前匹配不在用户松开键盘时立即解析而是设置 300ms debounce在 debounce 期间预扫描输入检测是否存在“疑似未闭合的 inline delimiter”若检测到**但后续 50 字符内无第二个**则临时添加一个虚拟闭合符如**bold**并用 CSS 高亮提示用户补全span classincomplete-emphasis**bold/span用户补全后移除虚拟符触发正常解析。.incomplete-emphasis { background: rgba(255, 220, 0, 0.3); border-bottom: 2px dashed #ffcc00; }4.2 场景二Link/Img 截断[text](url、则判定为截断将整个[text](url片段标记为incomplete_linktokenRenderer 对incomplete_link渲染为span classincomplete-link[点击这里](https://example.com/span并禁用点击事件。4.3 场景三Code Block 截断、~~~典型截断javascript、~~~python、末尾少一个风险Lexer 进入 code block 模式后将后续所有内容包括# 标题、当作代码直到遇到闭合符。防御策略delimiter 栈 超时熔断维护一个delimiterStack: string[]每遇到或~~~就 push每遇到闭合符同类型、同长度就 pop若栈非空且超过 3 秒未遇到闭合符则触发熔断将栈顶 delimiter 标记为unclosed强制退出 code block 模式并在渲染时添加警告提示。4.4 场景四List Item 截断-,*,1.典型截断- 第一项后直接换行未输入- 第二项或1. 第一项后输入2.但未对齐。风险Parser 误判 list depth导致嵌套错乱引用块被吞入 list。防御策略缩进快照 智能恢复每次解析 list 时记录每个 item 的缩进值空格数当新行缩进值与上一行相同视为同级 item当缩进值减少视为退出 list当缩进值增加但无对应 list marker-/1.则忽略缩进视为普通段落。4.5 场景五Blockquote 截断典型截断 第一行后换行未输入 第二行或 嵌套后只输。风险Parser 将换行后的内容当作新 paragraph破坏引用结构。防御策略行级状态继承Lexer 扫描每行时检查行首数量若当前行数量 ≥ 上一行且上一行以结尾则继承上一行的blockquoteDepth若当前行数量 上一行则根据差值退出对应层数。4.6 场景六HTML Tag 截断div、script典型截断div class、script src、table未闭合风险marked 默认开启sanitize: false截断的 HTML 会被浏览器解析可能导致 XSS 或布局崩溃。防御策略HTML 状态机 白名单在 Lexer 前插入一个轻量级 HTML parser仅识别/字符若检测到但未匹配进入inHtmlTag状态在inHtmlTag状态下禁止解析任何 Markdown 语法将整段当作 raw HTML仅允许白名单标签div,span,img其余标签自动转义。4.7 场景七Mermaid/PlantUML 截断mermaid、plantuml典型截断mermaid\ngraph TD\nA--B少一个风险marked 将后续所有内容包括 # 标题当作 mermaid 代码渲染失败。防御策略代码块类型感知 语法校验Lexer 识别lang时记录lang类型对mermaid/plantuml块调用对应语法校验器如mermaid.parse()验证若校验失败且块末尾无则标记为incomplete-diagram渲染为带 warning 的代码块。5. 实操避坑指南我在 5 个项目中踩过的 12 个深坑5.1 坑一过度依赖 marked 的gfm选项导致 GFM 特性在流式下失效marked 的gfm: true启用表格、任务列表等特性但这些特性依赖完整的行扫描。例如表格解析需要同时看到| Header |和|---|两行。在流式场景下若用户先输入| Name | Age |再输入|---|---|第一次渲染会把| Name | Age |当作普通文本。解决方案关闭gfm改用tables: true单独启用表格并实现行级缓存——当检测到|开头的行暂存到tableBuffer待下一行匹配|---|时再触发表格解析。5.2 坑二未处理 Unicode 组合字符导致 emoji 截断用户输入U1F44D是单个码点但输入程序员 emoji由U1F468 U200D U1F4BB三个码点组成。若截断发生在U200D零宽连接符处Lexer 会将其当作普通字符破坏 emoji 渲染。解决方案在sourceBuffer更新前用String.normalize(NFC)归一化再用Array.from(str)获取真实字符数而非str.length。5.3 坑三CSS 选择器性能爆炸.preview *导致重绘卡顿曾用document.querySelector(.preview).innerHTML html然后通过document.querySelectorAll(.preview code)绑定 highlight.js。结果发现querySelectorAll在 5000 行 HTML 中耗时 200ms。解决方案改用MutationObserver监听.preview的子节点变化只对新增的code节点调用hljs.highlightElement()耗时降至 8ms。5.4 坑四移动端输入法回车键行为不一致iOS 输入法回车是\nAndroid 是\r\n某些输入法还插入\u2028行分隔符。marked默认只识别\n导致 Android 用户换行后解析错乱。解决方案在sourceBuffer更新前统一替换\r\n和\u2028为\n。5.5 坑五未隔离渲染上下文导致 XSS 漏洞曾以为marked.parse(text, { sanitize: true })就绝对安全但发现sanitize: true仅过滤 HTML 标签不处理onerroralert(1)这类属性。解决方案在 Renderer 层对所有attrs做白名单过滤只允许class,id,src,href其余一律删除。5.6 坑六AST 缓存内存泄漏初期将整个 AST 节点存入Map节点含children引用形成循环引用GC 无法回收。解决方案使用WeakMap存储节点元数据或序列化 AST 为 plain object去掉函数和循环引用。5.7 坑七Debounce 时间设为 0导致输入卡顿为追求实时性设debounce 0结果每敲一个键都触发解析CPU 占用 95%。解决方案动态 debounce——输入速度 5 字符/秒时设为 100ms否则设为 300ms。5.8 坑八未处理粘贴大段内容的性能雪崩用户粘贴 10000 字 Markdown一次性触发解析主线程阻塞 2s。解决方案将粘贴内容分块每 500 字一块用setTimeout分批解析每块间隔 16ms1 帧。5.9 坑九服务端 SSR 与客户端 hydration 不一致服务端用marked渲染客户端用流式解析器AST 结构微小差异如空格处理导致 React hydration error。解决方案服务端渲染时注入>
