AI 对话中的 Markdown 渲染：安全解析与代码高亮的前端实践

AI 对话中的 Markdown 渲染安全解析与代码高亮的前端实践一、模型输出原始文本的那一刻危险就开始了模型生成到一半突然吐出一段/divscriptalert(1)/script。前端没消毒直接innerHTML注入整个对话页弹满警告框。某智能客服上线第一周就出过这事半个团队周末救火。从此所有模型输出必须过净化缺一行就是 P0 工单。这事我见过太多团队栽进去。大家都觉得模型不会主动攻击人但提示词注入是真实威胁。攻击者构造一段文本诱导模型吐 HTML 标签或 JS 片段前端傻乎乎地信任就会被穿透。更隐蔽的是标签截断。流式输出时模型可能先吐出三个反引号再吐出语言名最后才吐出真正的代码。中间这段未闭合的 Markdown 直接交给解析器要么整页结构坍塌要么高亮错位。某头部 IDE 集成的 AI 助手曾因此把正文渲染成一堆乱码用户截图传遍社区。更麻烦的是性能。一段 5000 字的回答含十几个代码块每个都用主线程同步高亮输入框点击会延迟上百毫秒。某低配笔记本上的反馈尤其明显研发不得不在高亮路径上动手脚。二、解析、净化与高亮的链路拆解安全的渲染链路通常分三步先把原始 Markdown 解析为抽象语法树再对语法树做白名单过滤最后把受信节点序列化为 DOM。关键决策在于过滤发生在树层面而非字符串层面。字符串替换容易因正则漏洞被绕过树过滤按节点类型精确裁剪安全面更窄。代码高亮是另一条独立支路。高亮计算涉及大量正则与词法分析若放在主线程同步执行长代码块会卡住输入交互。正确做法是用 Web Worker 把高亮搬运到后台线程渲染线程只接收着色后的 token 序列。三、生产级安全渲染实现下面的实现演示了带净化、超时与降级的安全渲染封装。重点是把外部 HTML 过滤、Worker 高亮与主线程渲染三件事隔离。import DOMPurify from dompurify; import MarkdownIt from markdown-it; const md new MarkdownIt({ html: false, linkify: true, breaks: true }); // 安全渲染解析 白名单净化 超时降级 async function renderMarkdown(raw: string): Promisestring { // html:false 禁止原始 HTML 通过从源头切断注入面 const html md.render(raw); // 仅放行安全标签与属性移除 on* 事件与 javascript: 协议 const clean DOMPurify.sanitize(html, { ALLOWED_TAGS: [p, code, pre, ul, ol, li, strong, em, a, table], ALLOWED_ATTR: [href, class], }); if (!clean) throw new Error(净化后内容为空疑似恶意输入); return clean; } // 代码高亮放入 Worker 避免阻塞主线程 function highlightInWorker(code: string, lang: string): Promisestring[] { return new Promise((resolve, reject) { const worker new Worker(/highlight.worker.js); const timer setTimeout(() { worker.terminate(); // 高亮超时直接终止避免 Worker 永久挂起 reject(new Error(高亮超时)); }, 2000); worker.onmessage (e) { clearTimeout(timer); worker.terminate(); resolve(e.data.tokens); // 仅接收 token主线程不执行任何用户代码 }; worker.onerror () { clearTimeout(timer); worker.terminate(); reject(new Error(高亮失败)); }; worker.postMessage({ code, lang }); }); }在把渲染结果注入容器时应确认它已经过净化。更稳妥的是直接操作经过校验的 DOM 节点而非整段innerHTML进一步缩小攻击面。四、渲染安全与性能的边界权衡白名单越严越安全却也会丢失表达力。例如流程图、数学公式在严格白名单下会被剥除。此时应引入专用渲染器如 KaTeX、Mermaid把它们作为独立受信组件挂载而非放进通用 Markdown 净化通道既保安全又保能力。某学术写作平台用这套方案安全审计一次通过公式还能正常渲染。Worker 高亮带来线程切换成本。对短代码块搬运开销可能超过同步高亮本身。应按代码长度做阈值判断短块主线程直接高亮长块才进 Worker用复杂度换流畅度。实测 10 行以下主线程快约 40%20 行以上 Worker 优势才显现。最后Markdown 解析本身也可能被超长输入拖垮。应为单次渲染设输入长度上限超出部分截断并提示防止单个巨型回答耗尽主线程。某智能助理曾被一个含 80KB 代码块的请求拖到主线程卡顿 5 秒限制单块 8KB 后恢复正常。实际测试也表明链路中最大的瓶颈经常不是渲染本身而是净化阶段的正则回溯。超长文本搭配宽松的白名单可能触发灾难性回溯让主线程原地卡住数秒。解决方法是限制输入长度在前置层截断让净化器每次都处理可控大小的片段而非整篇一次性通过。还有一层容易被忽略的防护是速率限制。用户连续发送多条消息时解析与高亮任务可能叠加在队列里导致前一帧还没渲完后一帧又来了。合理的做法是为每次渲染分配唯一 ID并在新的请求到来时丢弃尚未完成的旧任务避免无谓堆积。五、总结AI 对话的 Markdown 渲染核心是建立解析、净化、高亮三段式安全链路。关闭原始 HTML 解析从源头断注入用DOMPurify白名单在树层过滤用 Web Worker 把高亮移出主线程。对公式与图表引入独立受信渲染器按代码长度动态选择高亮路径。落地时务必设输入上限与超时降级。这条路在金融、医疗、教育的对话产品里都跑通过回报是值得的。