1. 项目缘起从纯文本到富文本的AI交互体验升级最近在折腾一个AI对话应用的后端服务功能跑通后发现了一个不大不小但很影响体验的问题AI的回复全是纯文本。当它试图解释一段代码、列出一个步骤清单或者给出一个包含表格的数据时回复框里呈现的就是一堆带着星号、反引号和横线的“天书”。用户需要自己在脑子里把**加粗**、- 列表项或者| 表头 | 表头 |这样的标记语言“翻译”成视觉上结构清晰的富文本。这就像给了用户一份需要自己组装的家具却只提供了零件清单和一张模糊的图纸体验大打折扣。这不仅仅是美观问题更是信息传达效率的问题。Markdown作为一种轻量级标记语言其核心价值就在于“易读易写”并且能轻松转换为结构化的HTML。在AI对话场景中支持Markdown渲染意味着AI能够以更符合人类阅读习惯的方式组织信息代码块有高亮、重点内容被加粗、列表清晰分层、表格整齐划一。这直接提升了信息的可读性和专业性让AI从一个“会说话的文本生成器”变成一个“会排版的智能助手”。我观察到的相关热词比如markdown语法、markdown编辑器、vscode markdown插件都指向了开发者或内容创作者对Markdown工作流的深度依赖。而ai agent、spring ai这类词则反映了AI能力正在被快速集成到各类应用中。将两者结合——让AI的产出直接适配主流的Markdown渲染管线就成了一个非常实际且高频的需求。这不仅仅是前端画个界面那么简单它涉及到前后端数据流的配合、安全过滤、以及不同平台渲染一致性的挑战。接下来我就结合这次实践把从识别需求到完整实现的思路、踩过的坑和最终方案详细拆解一遍。2. 技术选型寻找渲染管道的“最佳拍档”决定要做Markdown渲染后第一个问题就是怎么做在哪里做这本质上是一个渲染管道的设计问题。我们需要在数据流中找到一个合适的位置将AI返回的、包含Markdown标记的原始字符串转换成前端可以安全、高效渲染的富文本结构。2.1 前端渲染 vs 后端渲染这是第一个需要权衡的岔路口。前端渲染意味着后端API原样返回Markdown字符串由浏览器或客户端应用负责将其解析并渲染成HTML。这是目前非常主流和灵活的方案。它的优势很明显减轻服务器压力解析和渲染的计算工作分摊到了每个用户的设备上。动态交互友好对于需要实时编辑、预览的Markdown编辑器场景前端渲染几乎是唯一选择可以做到输入即预览。技术生态丰富前端有大量成熟、优秀的Markdown解析库如marked、markdown-it、Showdown等它们功能强大支持插件扩展例如代码高亮、数学公式、自定义组件等。但是纯前端渲染也有其局限性尤其是在AI对话这种强内容生成的场景下首屏性能对于较长的AI回复前端需要先下载完整的Markdown文本然后执行JS解析最后才能渲染出最终视图这可能会带来可感知的延迟。一致性挑战如果AI回复中包含了需要特定资源如特定版本的代码高亮样式、数学公式渲染引擎的内容需要确保前端环境已正确加载这些依赖否则渲染结果可能不一致。SEO不友好如果AI对话内容有被搜索引擎收录的需求那么爬虫抓取到的原始Markdown文本可读性远不如渲染后的HTML。后端渲染则是在服务器端将Markdown字符串解析为HTML然后直接将HTML字符串返回给前端前端只需将其插入到DOM中通常使用v-html、dangerouslySetInnerHTML或类似机制。它的优缺点正好相反首屏性能更优前端拿到的是立即可渲染的HTML省去了解析时间。输出一致性高服务器环境是可控的可以确保解析器和所有插件版本固定输出结果稳定。潜在的SEO优势直接输出HTML对爬虫更友好。但缺点也很突出服务器开销增加每次AI回复都需要服务器进行解析计算如果并发量高这是一笔额外的开销。交互性受限生成的HTML是“死”的如果希望用户能点击复制代码块、折叠展开某些内容需要额外注入大量的前端脚本和事件绑定复杂度陡增。安全风险直接将后端生成的HTML插入前端如果清洗不彻底极易引发XSS跨站脚本攻击。必须进行严格的HTML净化。2.2 混合渲染策略我的选择与理由经过权衡我选择了“后端解析前端渲染”的混合策略。具体来说后端Node.js/Python/Go等接收AI的原始回复包含Markdown。使用一个可靠的Markdown解析库如markdown-itfor Node.js,python-markdownfor Python将其解析成一个中间表示例如一个JSON AST抽象语法树或者一个高度结构化的数据对象。这个过程中可以安全地执行一些预处理比如识别出所有的代码块记录语言类型、链接、图片等。前后端通信后端不再返回纯文本或HTML而是返回这个结构化的数据对象JSON格式。前端Vue/React等前端根据这个结构化的数据使用自己的组件库来渲染。例如遇到“code_block”类型且语言为“javascript”就使用CodeBlock language“javascript”这个专用组件来渲染该组件内部会集成代码高亮库如Prism.js或highlight.js。为什么选择这个看起来更复杂的方案核心原因是安全、灵活与职责分离。安全彻底杜绝了XSS。后端不输出HTML前端不解析原始Markdown。数据是结构化的渲染是组件化的。图片链接、跳转链接等可以在组件层面进行安全策略控制例如限制图片域名、为外链添加rel“noopener noreferrer”。灵活与一致性前端完全掌控最终视觉效果。我可以为“引用块”设计独特的样式为“表格”添加滚动和悬停效果为“任务列表”添加交互勾选功能如果需求需要所有这些都不需要修改后端代码。同时所有用户看到的UI样式是统一的。性能与体验虽然首次加载需要下载组件库和样式但一旦加载完成后续的渲染非常快因为只是数据驱动组件更新。对于AI流式输出SSE的场景我们可以流式地接收结构化的数据块chunk并实时渲染到界面上体验比接收纯文本再解析要好。扩展性如果未来需要支持更复杂的自定义语法或AI返回特定类型的数据卡片如天气卡片、股票信息只需要在前端定义新的组件并在结构化数据中增加对应的类型标识即可后端解析器只需做最小化的适配。这个方案将Markdown的“解析”理解语法结构和“渲染”生成最终视图两个阶段解耦中间用结构化数据连接兼顾了安全、性能和未来扩展性。当然它需要前后端协同设计数据协议并编写相应的组件初期成本较高但对于一个追求长期稳定和体验的中大型项目来说我认为是值得的。3. 后端实现从文本到结构化的安全转换确定了混合渲染的策略后端的工作就清晰了做一个可靠、安全、高效的“Markdown翻译官”把带有标记的文本翻译成机器和前端都能轻松理解的结构化描述。3.1 解析库的选择与配置我使用的后端技术栈是 Node.js社区里最主流的Markdown解析库是markdown-it。它速度快、插件生态丰富而且可以通过配置严格控制输出。# 安装核心库和常用插件 npm install markdown-it npm install markdown-it-highlightjs # 代码高亮后端可选我们主要用其识别语言 npm install markdown-it-emoji # 表情符号可选初始化解析器时安全是首要考虑。我们必须禁用所有可能导致生成任意HTML标签和属性的功能。const MarkdownIt require(markdown-it); const md new MarkdownIt({ html: false, // 非常重要禁止解析HTML标签防止注入 xhtmlOut: false, breaks: true, // 将换行符转换为 br在结构化数据中我们可以用 \n 表示 linkify: true, // 自动将类似URL的文本转换为链接 typographer: true, // 一些印刷符号替换如 (c) - © // 高亮函数这里我们不直接返回HTML而是收集代码块信息 highlight: function (str, lang) { // 我们并不在此处渲染高亮HTML而是将代码和语言信息记录下来 // 返回一个空字符串或特定标记因为我们最终要输出JSON // 实际处理会在自定义的渲染器里做 return ; // 原始代码会通过token流获取 } }); // 明确禁用一些不安全的特性 md.validateLink (url) { // 这里可以实施链接安全策略比如只允许 http/https return /^https?:\/\//.test(url); };3.2 构建自定义渲染器输出ASTmarkdown-it的核心工作原理是将Markdown文本转换为一系列的tokens令牌然后根据这些tokens渲染出HTML。我们要做的就是拦截这个渲染过程不生成HTML而是根据token类型构建我们自己的树形结构。下面是一个简化版的自定义渲染器实现它将Markdown转换为一个嵌套的JSON数组function markdownToJSON(markdownText) { const tokens md.parse(markdownText, {}); const ast []; let currentList null; // 用于处理嵌套列表 const stack []; // 通用栈用于处理嵌套结构如块引用 // 一个辅助函数用于向当前目标ast或栈顶元素添加子节点 const addChild (parent, node) { if (!parent.children) parent.children []; parent.children.push(node); }; for (let i 0; i tokens.length; i) { const token tokens[i]; const target stack.length 0 ? stack[stack.length - 1] : { children: ast }; switch (token.type) { case heading_open: const headingNode { type: heading, level: parseInt(token.tag.slice(1)), // h1 - 1 children: [] }; addChild(target, headingNode); // 标题内容在下一个 inline token 里这里先推入栈等待内容填充 stack.push(headingNode); break; case paragraph_open: const paraNode { type: paragraph, children: [] }; addChild(target, paraNode); stack.push(paraNode); break; case blockquote_open: const quoteNode { type: blockquote, children: [] }; addChild(target, quoteNode); stack.push(quoteNode); break; case bullet_list_open: case ordered_list_open: const listNode { type: list, ordered: token.type ordered_list_open, children: [] }; addChild(target, listNode); currentList listNode; // 列表本身也入栈用于容纳 list_item stack.push(listNode); break; case list_item_open: const listItemNode { type: list_item, children: [] }; // 列表项应该添加到当前列表中 addChild(currentList, listItemNode); stack.push(listItemNode); break; case code_block: const codeNode { type: code_block, language: token.info ? token.info.trim() : plaintext, // 代码语言 content: token.content }; addChild(target, codeNode); break; // code_block是自闭合的没有_close token case fence: // 围栏代码块和code_block类似但markdown-it有时用它 const fenceNode { type: code_block, language: token.info ? token.info.trim() : plaintext, content: token.content }; addChild(target, fenceNode); break; case inline: // 内联内容文本、加粗、链接等需要进一步处理其子token if (stack.length 0) { const currentNode stack[stack.length - 1]; currentNode.children currentNode.children.concat(processInlineTokens(token.children || [])); } break; case heading_close: case paragraph_close: case blockquote_close: case bullet_list_close: case ordered_list_close: stack.pop(); // 关闭一个块级元素 if (token.type.includes(list_close)) { currentList null; // 列表关闭后重置 } break; case list_item_close: stack.pop(); break; // 可以继续处理其他token类型table, hr等 } } return ast; // 返回完整的AST } // 处理内联token如加粗、斜体、链接、图片 function processInlineTokens(tokens) { const result []; for (const token of tokens) { switch (token.type) { case text: result.push({ type: text, content: token.content }); break; case strong_open: result.push({ type: strong_open }); // 开始加粗标记 break; case strong_close: result.push({ type: strong_close }); break; case em_open: result.push({ type: em_open }); // 开始斜体标记 break; case em_close: result.push({ type: em_close }); break; case link_open: const linkNode { type: link, href: token.attrs.find(attr attr[0] href)[1], title: token.attrs.find(attr attr[0] title)?.[1], children: [] // 链接文本作为子节点 }; result.push(linkNode); // 链接内的文本需要后续的inline token填充这里简化处理 // 实际需要更复杂的栈机制来处理内联嵌套 break; case image: const imgNode { type: image, src: token.attrs.find(attr attr[0] src)[1], alt: token.attrs.find(attr attr[0] alt)[1], title: token.attrs.find(attr attr[0] title)?.[1] }; result.push(imgNode); break; // ... 处理其他内联类型 } } // 注意这里返回的是一个扁平数组对于复杂的嵌套内联结构如**加粗*斜体*加粗** // 需要更复杂的栈式处理来构建树。上述代码是一个原理性简化。 return result; }最终一段如## 这是一个标题\n\n这是一段**加粗**文字。的Markdown会被转换成类似下面的JSON结构[ { type: heading, level: 2, children: [ { type: text, content: 这是一个标题 } ] }, { type: paragraph, children: [ { type: text, content: 这是一段 }, { type: strong_open }, { type: text, content: 加粗 }, { type: strong_close }, { type: text, content: 文字。 } ] } ]这个结构化的数据就是前后端约定的“合同”。后端API在收到AI回复后调用markdownToJSON函数然后将得到的AST JSON返回给前端即可。实操心得处理内联嵌套的“坑”上面示例代码最大的简化在于processInlineTokens函数。真实场景中内联标记加粗、斜体、链接内套其他样式是嵌套的用一个简单的循环无法构建正确的树形结构。这里必须引入一个栈Stack来管理内联节点的开闭。当遇到strong_open时创建一个新的“strong”节点并入栈后续的内联内容都作为这个栈顶节点的子节点直到遇到strong_close才出栈。这是实现一个健壮解析器的关键细节也是很多自制解析器容易出错的地方。好在markdown-it提供的token流本身已经隐含了嵌套关系仔细处理即可。4. 前端实现用组件化思维渲染结构化数据后端已经把一份清晰的“建筑图纸”AST给了我们前端的工作就是用“预制构件”Vue/React组件把这栋楼盖起来。这个过程清晰、安全且完全可控。4.1 设计组件映射表首先我们需要根据AST中的节点类型type定义与之对应的渲染组件。这就像一个路由表// 在Vue中的一种实现思路 // ComponentMapper.vue script setup import { h } from vue; import CodeBlock from ./CodeBlock.vue; import Paragraph from ./Paragraph.vue; import Heading from ./Heading.vue; import List from ./List.vue; import ListItem from ./ListItem.vue; import Blockquote from ./Blockquote.vue; import Text from ./Text.vue; // 处理纯文本和简单的内联格式如加粗、斜体 import Link from ./Link.vue; import Image from ./Image.vue; const componentMap { code_block: CodeBlock, paragraph: Paragraph, heading: Heading, list: List, list_item: ListItem, blockquote: Blockquote, text: Text, link: Link, image: Image, // ... 其他类型 }; const props defineProps([node]); const renderNode (node) { const Component componentMap[node.type]; if (!Component) { console.warn(No component mapped for type: ${node.type}, node); return null; } // 对于有子节点的组件递归渲染其子节点 if (node.children node.children.length 0) { // 将子节点作为默认插槽或特定prop传递给组件 // 这里假设组件通过 children prop 接收子节点 return h(Component, { ...node, children: node.children.map(child renderNode(child)) }); } return h(Component, node); }; /script template div component :isrenderNode(node) / /div /template4.2 关键组件实现示例以最复杂的CodeBlock和Text处理内联格式组件为例CodeBlock.vue 它的职责是接收语言和代码内容并集成代码高亮库。template pre classcode-block :classlanguage-${language} code refcodeElslot //code !-- 代码内容通过插槽或prop传入 -- /pre /template script setup import { ref, onMounted, nextTick } from vue; import Prism from prismjs; // 或 highlight.js import prismjs/themes/prism-tomorrow.css; // 引入样式 // 按需加载语言定义 import prismjs/components/prism-javascript; import prismjs/components/prism-python; // ... 其他语言 const props defineProps({ language: { type: String, default: plaintext }, content: { type: String, default: } }); const codeEl ref(null); onMounted(() { nextTick(() { if (codeEl.value Prism) { Prism.highlightElement(codeEl.value); } }); }); /script style scoped .code-block { background: #f5f5f5; border-radius: 6px; padding: 1em; overflow-x: auto; margin: 1em 0; } /styleText.vue 它需要处理内联格式的嵌套。我们假设传入的node结构更精细例如{ type: ‘inline’, children: […] }其中children里包含了text、strong、em等节点。template span template v-for(child, index) in node.children :keyindex template v-ifchild.type text {{ child.content }} /template strong v-else-ifchild.type strong Text :nodechild / !-- 递归处理strong内部可能还有em等 -- /strong em v-else-ifchild.type em Text :nodechild / /em Link v-else-ifchild.type link :hrefchild.href :titlechild.title Text :nodechild / !-- 链接文本 -- /Link !-- ... 处理其他内联类型如code, del等 -- /template /span /template script setup import Link from ./Link.vue; // 引入其他内联组件 const props defineProps({ node: { type: Object, required: true } }); /scriptLink.vue 这是一个安全控制的重点区域。template a :hrefsafeHref :titletitle :targettarget :relrel click.preventhandleClick slot / /a /template script setup import { computed } from vue; const props defineProps({ href: { type: String, required: true }, title: { type: String, default: } }); // 1. URL安全校验 const safeHref computed(() { try { const url new URL(props.href); // 只允许 http 和 https 协议 if (![http:, https:].includes(url.protocol)) { console.warn(Unsafe protocol in link: ${props.href}); return javascript:void(0);; } // 可以在这里添加域名白名单检查 // if (!isAllowedDomain(url.hostname)) { ... } return props.href; } catch { // 如果不是合法URL可能是相对路径或锚点 // 对于相对路径需要结合你的路由策略处理这里简单返回 return props.href.startsWith(#) ? props.href : #${props.href}; } }); // 2. 安全属性设置 const target computed(() (isExternalLink.value ? _blank : null)); const rel computed(() (isExternalLink.value ? noopener noreferrer : null)); const isExternalLink computed(() { return safeHref.value.startsWith(http); }); // 3. 可控的点击行为例如应用内路由跳转 vs 外链打开 const handleClick (event) { if (isExternalLink.value) { // 外链允许默认行为新标签页打开 // 可以在这里做点击统计等 window.open(safeHref.value, _blank); } else { // 内链使用前端路由跳转阻止默认的页面刷新 event.preventDefault(); // 假设使用Vue Router // router.push(safeHref.value); console.log(Internal navigation to:, safeHref.value); } }; /script4.3 流式渲染与性能优化对于AI流式输出Server-Sent Events的场景我们的结构化数据也可以分块chunk返回。前端需要能够增量式地更新AST并渲染。后端分块 后端在流式接收AI响应时可以按句子或段落进行Markdown解析并发送一个个包含部分AST节点的数据块。前端增量更新 前端维护一个完整的AST数组。每收到一个数据块就将其解析并拼接到现有AST的末尾。然后触发一次针对新增部分的渲染。虚拟列表 如果对话历史非常长渲染所有消息会导致DOM节点过多影响性能。此时可以对整个对话历史应用虚拟列表技术只渲染可视区域内的消息。对于单条很长的AI回复也可以考虑对渲染出的DOM节点进行“局部虚拟化”但这复杂度较高通常优先优化AI回复的分块粒度。一个简单的增量更新示例使用Vue 3的响应式系统// 在消息组件内部 const messageAst ref([]); // 当前消息的AST // 假设通过EventSource接收流 const eventSource new EventSource(‘/api/chat-stream’); eventSource.onmessage (event) { const chunkData JSON.parse(event.data); // 假设后端返回 { type: “ast_chunk”, ast: […] } if (chunkData.type ‘ast_chunk’) { // 将新解析出的AST片段追加到现有AST中 messageAst.value […messageAst.value, …chunkData.ast]; } };踩坑实录样式隔离与冲突在引入Prism.js或highlight.js进行代码高亮时我遇到了样式冲突问题。这些库会向code标签注入大量的span子元素并赋予特定的CSS类名如.token.keyword。如果项目本身使用了CSS-in-JS方案或者像Tailwind CSS这类使用高优先级工具类的框架可能会覆盖代码高亮的样式。解决方案是提升代码高亮样式表的优先级或者将其放入 Shadow DOM 中进行样式隔离。一个更简单实用的办法是在包裹代码块的容器上添加一个特定的类名如.ai-markdown-content然后所有代码高亮样式都嵌套在这个类名下确保选择器有足够高的特异性。.ai-markdown-content pre code .token.keyword { color: #ff79c6 !important; /* 提高特异性必要时使用!important */ }5. 安全加固与内容过滤构建可信的渲染管道让AI的回复以富文本形式渲染相当于打开了一扇门。我们必须在这扇门口设置严格的安全检查防止恶意内容溜进来。安全是底线绝不能妥协。5.1 输入净化后端的责任即使我们采用结构化数据方案后端在生成AST之前对原始的AI回复进行净化仍然是必要的。标记清洗 虽然我们禁用了HTML解析但有些Markdown扩展语法或AI的“创造性”输出可能包含类似HTML的标签。需要在解析前用一个简单的正则表达式或专门的库如sanitize-html的文本模式去除所有和字符之间的内容或者将其转义。// 一个简单的转义示例 function escapeRawHtml(rawText) { return rawText.replace(/[]/g, (c) c ‘’ ? ‘lt;’ : ‘gt;’); } // 在调用 markdownToJSON 之前 const safeMarkdown escapeRawHtml(aiRawResponse);链接安全 如前所述在markdown-it的validateLink钩子中实施策略。只允许http://和https://开头的链接。对于图片链接甚至可以设置一个代理白名单防止盗链和潜在的不良内容。数据大小限制 对单次AI回复的Markdown文本长度进行限制防止超长内容导致解析器性能下降或内存溢出。5.2 输出控制前端的防线前端是最后一道防线即便数据来自“可信”的后端也应遵循安全最佳实践。绝不信任输入 对待后端传来的AST数据也要进行验证。例如检查image.src是否是一个字符串link.href是否符合预期格式。虽然AST是我们自己定义的但防御性编程是有益的。组件级安全策略Link组件 如上文实现必须校验协议并为外链添加rel“noopener noreferrer”属性防止window.opener漏洞。Image组件 可以考虑实现一个统一的图片代理或懒加载组件在onError事件中替换为默认占位图防止外链图片失效或包含不当内容。Iframe/脚本 在我们的场景中Markdown通常不应解析出iframe或script。但如果未来支持自定义HTML块必须彻底禁止这类标签。CSP内容安全策略 在Web应用层面配置严格的CSP HTTP头是终极防护。它可以禁止内联脚本、限制资源加载的源如图片、样式、字体即使有恶意脚本被注入也无法执行。Content-Security-Policy: default-src ‘self’; img-src ‘self’ https://trusted-cdn.com; style-src ‘self’ ‘unsafe-inline’; script-src ‘self’;这个策略表示默认只允许加载同源资源图片允许同源和https://trusted-cdn.com样式允许同源和内联样式某些代码高亮库可能需要脚本只允许同源。5.3 处理AI的“幻觉”与不规则标记AI并非完美它可能生成不合规的Markdown例如未闭合的**加粗、嵌套混乱的列表甚至是一些自创的“伪Markdown”语法。解析器的容错性 选择一个容错性好的解析库markdown-it在这方面表现不错。它通常能自动修正一些常见的错误比如将未配对的*视为普通星号字符。后处理与降级 在将AST返回给前端前可以遍历AST进行一次“清理”。例如发现一个strong_open节点没有对应的strong_close节点可以自动为其补全或者将整个段落降级为纯文本节点。这比直接渲染出奇怪的样式要好。前端降级渲染 在前端组件中如果遇到无法识别或结构破损的节点类型应有降级方案。例如Text组件遇到未知的内联节点可以将其内容作为纯文本渲染并记录错误日志而不是直接崩溃或渲染空白。安全红线关于dangerouslySetInnerHTML的警示如果你的方案是后端返回HTML字符串前端使用v-html或dangerouslySetInnerHTML那么你必须使用像DOMPurify这样的库在客户端进行二次净化。永远不要相信后端传来的、未经净化的HTML。DOMPurify可以配置一个非常严格的允许标签和属性列表过滤掉所有危险元素和事件处理器。即便如此混合方案中后端生成HTML的方式其安全风险和维护成本依然高于结构化数据方案。我个人强烈推荐后者。6. 扩展与优化让渲染引擎更强大基础功能实现后我们可以着眼于此方案的扩展潜力让它不仅能渲染标准Markdown还能适应更丰富的交互需求。6.1 支持扩展语法与自定义组件AI的应用场景多样有时我们可能希望它返回一些标准Markdown不支持的元素比如一个可交互的按钮、一个进度条、或一个特殊的数据图表。定义自定义容器 可以利用Markdown的扩展语法比如围栏代码块的变种。例如约定:::warning和:::之间包裹的内容渲染为警告提示框。:::warning 这是一条重要的警告信息。 :::后端解析器需要识别这种自定义语法并在AST中生成一个type: ‘custom_warning’的节点。前端注册自定义组件 在前端的componentMap中为custom_warning注册一个WarningBox.vue组件。这个组件可以有自己的样式和图标实现丰富的渲染效果。属性传递 甚至可以支持更复杂的语法从标记中提取属性。例如:::chart type“line” data“{...}” :::后端解析出type和data属性前端Chart组件接收这些属性并渲染对应的图表。6.2 代码块的深度交互代码块不仅仅是静态高亮我们可以让它变得有用。一键复制 在CodeBlock组件右上角添加一个复制按钮点击后使用navigator.clipboard.writeTextAPI将代码内容复制到剪贴板。语言检测与切换 如果AI返回的代码块未指定语言或语言不准确前端可以集成一个轻量级的语言检测库如highlight.js的highlightAuto提供“检测语言”或“切换语言”的选项。代码执行沙盒环境 对于某些教育或演示场景如果代码是JavaScript且经过严格安全审查可以考虑在iframe沙盒中安全地运行它展示运行结果。这是一个高风险功能必须极其谨慎通常仅用于完全可控的内部环境。6.3 性能与可访问性图片懒加载 对Image组件实现懒加载使用Intersection Observer API监听图片是否进入视口再加载真实图片源提升首屏速度。可访问性A11y为CodeBlock添加role“code”和aria-label属性描述代码块的作用。确保Heading组件生成正确的h1到h6标签并保持层级结构方便屏幕阅读器导航。为Link组件提供清晰的链接文本避免使用“点击这里”这种模糊的描述。深色模式适配 代码高亮主题、边框颜色、背景色等都需要适配深色模式。可以通过CSS变量Custom Properties来定义颜色主题使切换变得容易。实现AI回复的Markdown渲染远不止是调用一个库那么简单。它是一次对数据流、安全模型和用户体验的综合设计。从最初在后端返回HTML的简单想法到最终确立“结构化数据 前端组件化渲染”的混合架构这个过程让我深刻体会到在追求功能的同时安全性、可维护性和未来扩展性必须作为同等重要的考量因素。现在当看到AI生成的复杂步骤清单、格式清晰的代码示例或数据表格能够在前端完美地呈现出来时那种体验的提升是实实在在的。这个方案也为后续集成更丰富的交互元素如可折叠的详情块、内嵌的简单图表铺平了道路让AI与用户的对话界面真正成为一个强大而美观的信息交付平台。 AI对话应用Markdown渲染实践：从后端解析到前端组件化渲染
1. 项目缘起从纯文本到富文本的AI交互体验升级最近在折腾一个AI对话应用的后端服务功能跑通后发现了一个不大不小但很影响体验的问题AI的回复全是纯文本。当它试图解释一段代码、列出一个步骤清单或者给出一个包含表格的数据时回复框里呈现的就是一堆带着星号、反引号和横线的“天书”。用户需要自己在脑子里把**加粗**、- 列表项或者| 表头 | 表头 |这样的标记语言“翻译”成视觉上结构清晰的富文本。这就像给了用户一份需要自己组装的家具却只提供了零件清单和一张模糊的图纸体验大打折扣。这不仅仅是美观问题更是信息传达效率的问题。Markdown作为一种轻量级标记语言其核心价值就在于“易读易写”并且能轻松转换为结构化的HTML。在AI对话场景中支持Markdown渲染意味着AI能够以更符合人类阅读习惯的方式组织信息代码块有高亮、重点内容被加粗、列表清晰分层、表格整齐划一。这直接提升了信息的可读性和专业性让AI从一个“会说话的文本生成器”变成一个“会排版的智能助手”。我观察到的相关热词比如markdown语法、markdown编辑器、vscode markdown插件都指向了开发者或内容创作者对Markdown工作流的深度依赖。而ai agent、spring ai这类词则反映了AI能力正在被快速集成到各类应用中。将两者结合——让AI的产出直接适配主流的Markdown渲染管线就成了一个非常实际且高频的需求。这不仅仅是前端画个界面那么简单它涉及到前后端数据流的配合、安全过滤、以及不同平台渲染一致性的挑战。接下来我就结合这次实践把从识别需求到完整实现的思路、踩过的坑和最终方案详细拆解一遍。2. 技术选型寻找渲染管道的“最佳拍档”决定要做Markdown渲染后第一个问题就是怎么做在哪里做这本质上是一个渲染管道的设计问题。我们需要在数据流中找到一个合适的位置将AI返回的、包含Markdown标记的原始字符串转换成前端可以安全、高效渲染的富文本结构。2.1 前端渲染 vs 后端渲染这是第一个需要权衡的岔路口。前端渲染意味着后端API原样返回Markdown字符串由浏览器或客户端应用负责将其解析并渲染成HTML。这是目前非常主流和灵活的方案。它的优势很明显减轻服务器压力解析和渲染的计算工作分摊到了每个用户的设备上。动态交互友好对于需要实时编辑、预览的Markdown编辑器场景前端渲染几乎是唯一选择可以做到输入即预览。技术生态丰富前端有大量成熟、优秀的Markdown解析库如marked、markdown-it、Showdown等它们功能强大支持插件扩展例如代码高亮、数学公式、自定义组件等。但是纯前端渲染也有其局限性尤其是在AI对话这种强内容生成的场景下首屏性能对于较长的AI回复前端需要先下载完整的Markdown文本然后执行JS解析最后才能渲染出最终视图这可能会带来可感知的延迟。一致性挑战如果AI回复中包含了需要特定资源如特定版本的代码高亮样式、数学公式渲染引擎的内容需要确保前端环境已正确加载这些依赖否则渲染结果可能不一致。SEO不友好如果AI对话内容有被搜索引擎收录的需求那么爬虫抓取到的原始Markdown文本可读性远不如渲染后的HTML。后端渲染则是在服务器端将Markdown字符串解析为HTML然后直接将HTML字符串返回给前端前端只需将其插入到DOM中通常使用v-html、dangerouslySetInnerHTML或类似机制。它的优缺点正好相反首屏性能更优前端拿到的是立即可渲染的HTML省去了解析时间。输出一致性高服务器环境是可控的可以确保解析器和所有插件版本固定输出结果稳定。潜在的SEO优势直接输出HTML对爬虫更友好。但缺点也很突出服务器开销增加每次AI回复都需要服务器进行解析计算如果并发量高这是一笔额外的开销。交互性受限生成的HTML是“死”的如果希望用户能点击复制代码块、折叠展开某些内容需要额外注入大量的前端脚本和事件绑定复杂度陡增。安全风险直接将后端生成的HTML插入前端如果清洗不彻底极易引发XSS跨站脚本攻击。必须进行严格的HTML净化。2.2 混合渲染策略我的选择与理由经过权衡我选择了“后端解析前端渲染”的混合策略。具体来说后端Node.js/Python/Go等接收AI的原始回复包含Markdown。使用一个可靠的Markdown解析库如markdown-itfor Node.js,python-markdownfor Python将其解析成一个中间表示例如一个JSON AST抽象语法树或者一个高度结构化的数据对象。这个过程中可以安全地执行一些预处理比如识别出所有的代码块记录语言类型、链接、图片等。前后端通信后端不再返回纯文本或HTML而是返回这个结构化的数据对象JSON格式。前端Vue/React等前端根据这个结构化的数据使用自己的组件库来渲染。例如遇到“code_block”类型且语言为“javascript”就使用CodeBlock language“javascript”这个专用组件来渲染该组件内部会集成代码高亮库如Prism.js或highlight.js。为什么选择这个看起来更复杂的方案核心原因是安全、灵活与职责分离。安全彻底杜绝了XSS。后端不输出HTML前端不解析原始Markdown。数据是结构化的渲染是组件化的。图片链接、跳转链接等可以在组件层面进行安全策略控制例如限制图片域名、为外链添加rel“noopener noreferrer”。灵活与一致性前端完全掌控最终视觉效果。我可以为“引用块”设计独特的样式为“表格”添加滚动和悬停效果为“任务列表”添加交互勾选功能如果需求需要所有这些都不需要修改后端代码。同时所有用户看到的UI样式是统一的。性能与体验虽然首次加载需要下载组件库和样式但一旦加载完成后续的渲染非常快因为只是数据驱动组件更新。对于AI流式输出SSE的场景我们可以流式地接收结构化的数据块chunk并实时渲染到界面上体验比接收纯文本再解析要好。扩展性如果未来需要支持更复杂的自定义语法或AI返回特定类型的数据卡片如天气卡片、股票信息只需要在前端定义新的组件并在结构化数据中增加对应的类型标识即可后端解析器只需做最小化的适配。这个方案将Markdown的“解析”理解语法结构和“渲染”生成最终视图两个阶段解耦中间用结构化数据连接兼顾了安全、性能和未来扩展性。当然它需要前后端协同设计数据协议并编写相应的组件初期成本较高但对于一个追求长期稳定和体验的中大型项目来说我认为是值得的。3. 后端实现从文本到结构化的安全转换确定了混合渲染的策略后端的工作就清晰了做一个可靠、安全、高效的“Markdown翻译官”把带有标记的文本翻译成机器和前端都能轻松理解的结构化描述。3.1 解析库的选择与配置我使用的后端技术栈是 Node.js社区里最主流的Markdown解析库是markdown-it。它速度快、插件生态丰富而且可以通过配置严格控制输出。# 安装核心库和常用插件 npm install markdown-it npm install markdown-it-highlightjs # 代码高亮后端可选我们主要用其识别语言 npm install markdown-it-emoji # 表情符号可选初始化解析器时安全是首要考虑。我们必须禁用所有可能导致生成任意HTML标签和属性的功能。const MarkdownIt require(markdown-it); const md new MarkdownIt({ html: false, // 非常重要禁止解析HTML标签防止注入 xhtmlOut: false, breaks: true, // 将换行符转换为 br在结构化数据中我们可以用 \n 表示 linkify: true, // 自动将类似URL的文本转换为链接 typographer: true, // 一些印刷符号替换如 (c) - © // 高亮函数这里我们不直接返回HTML而是收集代码块信息 highlight: function (str, lang) { // 我们并不在此处渲染高亮HTML而是将代码和语言信息记录下来 // 返回一个空字符串或特定标记因为我们最终要输出JSON // 实际处理会在自定义的渲染器里做 return ; // 原始代码会通过token流获取 } }); // 明确禁用一些不安全的特性 md.validateLink (url) { // 这里可以实施链接安全策略比如只允许 http/https return /^https?:\/\//.test(url); };3.2 构建自定义渲染器输出ASTmarkdown-it的核心工作原理是将Markdown文本转换为一系列的tokens令牌然后根据这些tokens渲染出HTML。我们要做的就是拦截这个渲染过程不生成HTML而是根据token类型构建我们自己的树形结构。下面是一个简化版的自定义渲染器实现它将Markdown转换为一个嵌套的JSON数组function markdownToJSON(markdownText) { const tokens md.parse(markdownText, {}); const ast []; let currentList null; // 用于处理嵌套列表 const stack []; // 通用栈用于处理嵌套结构如块引用 // 一个辅助函数用于向当前目标ast或栈顶元素添加子节点 const addChild (parent, node) { if (!parent.children) parent.children []; parent.children.push(node); }; for (let i 0; i tokens.length; i) { const token tokens[i]; const target stack.length 0 ? stack[stack.length - 1] : { children: ast }; switch (token.type) { case heading_open: const headingNode { type: heading, level: parseInt(token.tag.slice(1)), // h1 - 1 children: [] }; addChild(target, headingNode); // 标题内容在下一个 inline token 里这里先推入栈等待内容填充 stack.push(headingNode); break; case paragraph_open: const paraNode { type: paragraph, children: [] }; addChild(target, paraNode); stack.push(paraNode); break; case blockquote_open: const quoteNode { type: blockquote, children: [] }; addChild(target, quoteNode); stack.push(quoteNode); break; case bullet_list_open: case ordered_list_open: const listNode { type: list, ordered: token.type ordered_list_open, children: [] }; addChild(target, listNode); currentList listNode; // 列表本身也入栈用于容纳 list_item stack.push(listNode); break; case list_item_open: const listItemNode { type: list_item, children: [] }; // 列表项应该添加到当前列表中 addChild(currentList, listItemNode); stack.push(listItemNode); break; case code_block: const codeNode { type: code_block, language: token.info ? token.info.trim() : plaintext, // 代码语言 content: token.content }; addChild(target, codeNode); break; // code_block是自闭合的没有_close token case fence: // 围栏代码块和code_block类似但markdown-it有时用它 const fenceNode { type: code_block, language: token.info ? token.info.trim() : plaintext, content: token.content }; addChild(target, fenceNode); break; case inline: // 内联内容文本、加粗、链接等需要进一步处理其子token if (stack.length 0) { const currentNode stack[stack.length - 1]; currentNode.children currentNode.children.concat(processInlineTokens(token.children || [])); } break; case heading_close: case paragraph_close: case blockquote_close: case bullet_list_close: case ordered_list_close: stack.pop(); // 关闭一个块级元素 if (token.type.includes(list_close)) { currentList null; // 列表关闭后重置 } break; case list_item_close: stack.pop(); break; // 可以继续处理其他token类型table, hr等 } } return ast; // 返回完整的AST } // 处理内联token如加粗、斜体、链接、图片 function processInlineTokens(tokens) { const result []; for (const token of tokens) { switch (token.type) { case text: result.push({ type: text, content: token.content }); break; case strong_open: result.push({ type: strong_open }); // 开始加粗标记 break; case strong_close: result.push({ type: strong_close }); break; case em_open: result.push({ type: em_open }); // 开始斜体标记 break; case em_close: result.push({ type: em_close }); break; case link_open: const linkNode { type: link, href: token.attrs.find(attr attr[0] href)[1], title: token.attrs.find(attr attr[0] title)?.[1], children: [] // 链接文本作为子节点 }; result.push(linkNode); // 链接内的文本需要后续的inline token填充这里简化处理 // 实际需要更复杂的栈机制来处理内联嵌套 break; case image: const imgNode { type: image, src: token.attrs.find(attr attr[0] src)[1], alt: token.attrs.find(attr attr[0] alt)[1], title: token.attrs.find(attr attr[0] title)?.[1] }; result.push(imgNode); break; // ... 处理其他内联类型 } } // 注意这里返回的是一个扁平数组对于复杂的嵌套内联结构如**加粗*斜体*加粗** // 需要更复杂的栈式处理来构建树。上述代码是一个原理性简化。 return result; }最终一段如## 这是一个标题\n\n这是一段**加粗**文字。的Markdown会被转换成类似下面的JSON结构[ { type: heading, level: 2, children: [ { type: text, content: 这是一个标题 } ] }, { type: paragraph, children: [ { type: text, content: 这是一段 }, { type: strong_open }, { type: text, content: 加粗 }, { type: strong_close }, { type: text, content: 文字。 } ] } ]这个结构化的数据就是前后端约定的“合同”。后端API在收到AI回复后调用markdownToJSON函数然后将得到的AST JSON返回给前端即可。实操心得处理内联嵌套的“坑”上面示例代码最大的简化在于processInlineTokens函数。真实场景中内联标记加粗、斜体、链接内套其他样式是嵌套的用一个简单的循环无法构建正确的树形结构。这里必须引入一个栈Stack来管理内联节点的开闭。当遇到strong_open时创建一个新的“strong”节点并入栈后续的内联内容都作为这个栈顶节点的子节点直到遇到strong_close才出栈。这是实现一个健壮解析器的关键细节也是很多自制解析器容易出错的地方。好在markdown-it提供的token流本身已经隐含了嵌套关系仔细处理即可。4. 前端实现用组件化思维渲染结构化数据后端已经把一份清晰的“建筑图纸”AST给了我们前端的工作就是用“预制构件”Vue/React组件把这栋楼盖起来。这个过程清晰、安全且完全可控。4.1 设计组件映射表首先我们需要根据AST中的节点类型type定义与之对应的渲染组件。这就像一个路由表// 在Vue中的一种实现思路 // ComponentMapper.vue script setup import { h } from vue; import CodeBlock from ./CodeBlock.vue; import Paragraph from ./Paragraph.vue; import Heading from ./Heading.vue; import List from ./List.vue; import ListItem from ./ListItem.vue; import Blockquote from ./Blockquote.vue; import Text from ./Text.vue; // 处理纯文本和简单的内联格式如加粗、斜体 import Link from ./Link.vue; import Image from ./Image.vue; const componentMap { code_block: CodeBlock, paragraph: Paragraph, heading: Heading, list: List, list_item: ListItem, blockquote: Blockquote, text: Text, link: Link, image: Image, // ... 其他类型 }; const props defineProps([node]); const renderNode (node) { const Component componentMap[node.type]; if (!Component) { console.warn(No component mapped for type: ${node.type}, node); return null; } // 对于有子节点的组件递归渲染其子节点 if (node.children node.children.length 0) { // 将子节点作为默认插槽或特定prop传递给组件 // 这里假设组件通过 children prop 接收子节点 return h(Component, { ...node, children: node.children.map(child renderNode(child)) }); } return h(Component, node); }; /script template div component :isrenderNode(node) / /div /template4.2 关键组件实现示例以最复杂的CodeBlock和Text处理内联格式组件为例CodeBlock.vue 它的职责是接收语言和代码内容并集成代码高亮库。template pre classcode-block :classlanguage-${language} code refcodeElslot //code !-- 代码内容通过插槽或prop传入 -- /pre /template script setup import { ref, onMounted, nextTick } from vue; import Prism from prismjs; // 或 highlight.js import prismjs/themes/prism-tomorrow.css; // 引入样式 // 按需加载语言定义 import prismjs/components/prism-javascript; import prismjs/components/prism-python; // ... 其他语言 const props defineProps({ language: { type: String, default: plaintext }, content: { type: String, default: } }); const codeEl ref(null); onMounted(() { nextTick(() { if (codeEl.value Prism) { Prism.highlightElement(codeEl.value); } }); }); /script style scoped .code-block { background: #f5f5f5; border-radius: 6px; padding: 1em; overflow-x: auto; margin: 1em 0; } /styleText.vue 它需要处理内联格式的嵌套。我们假设传入的node结构更精细例如{ type: ‘inline’, children: […] }其中children里包含了text、strong、em等节点。template span template v-for(child, index) in node.children :keyindex template v-ifchild.type text {{ child.content }} /template strong v-else-ifchild.type strong Text :nodechild / !-- 递归处理strong内部可能还有em等 -- /strong em v-else-ifchild.type em Text :nodechild / /em Link v-else-ifchild.type link :hrefchild.href :titlechild.title Text :nodechild / !-- 链接文本 -- /Link !-- ... 处理其他内联类型如code, del等 -- /template /span /template script setup import Link from ./Link.vue; // 引入其他内联组件 const props defineProps({ node: { type: Object, required: true } }); /scriptLink.vue 这是一个安全控制的重点区域。template a :hrefsafeHref :titletitle :targettarget :relrel click.preventhandleClick slot / /a /template script setup import { computed } from vue; const props defineProps({ href: { type: String, required: true }, title: { type: String, default: } }); // 1. URL安全校验 const safeHref computed(() { try { const url new URL(props.href); // 只允许 http 和 https 协议 if (![http:, https:].includes(url.protocol)) { console.warn(Unsafe protocol in link: ${props.href}); return javascript:void(0);; } // 可以在这里添加域名白名单检查 // if (!isAllowedDomain(url.hostname)) { ... } return props.href; } catch { // 如果不是合法URL可能是相对路径或锚点 // 对于相对路径需要结合你的路由策略处理这里简单返回 return props.href.startsWith(#) ? props.href : #${props.href}; } }); // 2. 安全属性设置 const target computed(() (isExternalLink.value ? _blank : null)); const rel computed(() (isExternalLink.value ? noopener noreferrer : null)); const isExternalLink computed(() { return safeHref.value.startsWith(http); }); // 3. 可控的点击行为例如应用内路由跳转 vs 外链打开 const handleClick (event) { if (isExternalLink.value) { // 外链允许默认行为新标签页打开 // 可以在这里做点击统计等 window.open(safeHref.value, _blank); } else { // 内链使用前端路由跳转阻止默认的页面刷新 event.preventDefault(); // 假设使用Vue Router // router.push(safeHref.value); console.log(Internal navigation to:, safeHref.value); } }; /script4.3 流式渲染与性能优化对于AI流式输出Server-Sent Events的场景我们的结构化数据也可以分块chunk返回。前端需要能够增量式地更新AST并渲染。后端分块 后端在流式接收AI响应时可以按句子或段落进行Markdown解析并发送一个个包含部分AST节点的数据块。前端增量更新 前端维护一个完整的AST数组。每收到一个数据块就将其解析并拼接到现有AST的末尾。然后触发一次针对新增部分的渲染。虚拟列表 如果对话历史非常长渲染所有消息会导致DOM节点过多影响性能。此时可以对整个对话历史应用虚拟列表技术只渲染可视区域内的消息。对于单条很长的AI回复也可以考虑对渲染出的DOM节点进行“局部虚拟化”但这复杂度较高通常优先优化AI回复的分块粒度。一个简单的增量更新示例使用Vue 3的响应式系统// 在消息组件内部 const messageAst ref([]); // 当前消息的AST // 假设通过EventSource接收流 const eventSource new EventSource(‘/api/chat-stream’); eventSource.onmessage (event) { const chunkData JSON.parse(event.data); // 假设后端返回 { type: “ast_chunk”, ast: […] } if (chunkData.type ‘ast_chunk’) { // 将新解析出的AST片段追加到现有AST中 messageAst.value […messageAst.value, …chunkData.ast]; } };踩坑实录样式隔离与冲突在引入Prism.js或highlight.js进行代码高亮时我遇到了样式冲突问题。这些库会向code标签注入大量的span子元素并赋予特定的CSS类名如.token.keyword。如果项目本身使用了CSS-in-JS方案或者像Tailwind CSS这类使用高优先级工具类的框架可能会覆盖代码高亮的样式。解决方案是提升代码高亮样式表的优先级或者将其放入 Shadow DOM 中进行样式隔离。一个更简单实用的办法是在包裹代码块的容器上添加一个特定的类名如.ai-markdown-content然后所有代码高亮样式都嵌套在这个类名下确保选择器有足够高的特异性。.ai-markdown-content pre code .token.keyword { color: #ff79c6 !important; /* 提高特异性必要时使用!important */ }5. 安全加固与内容过滤构建可信的渲染管道让AI的回复以富文本形式渲染相当于打开了一扇门。我们必须在这扇门口设置严格的安全检查防止恶意内容溜进来。安全是底线绝不能妥协。5.1 输入净化后端的责任即使我们采用结构化数据方案后端在生成AST之前对原始的AI回复进行净化仍然是必要的。标记清洗 虽然我们禁用了HTML解析但有些Markdown扩展语法或AI的“创造性”输出可能包含类似HTML的标签。需要在解析前用一个简单的正则表达式或专门的库如sanitize-html的文本模式去除所有和字符之间的内容或者将其转义。// 一个简单的转义示例 function escapeRawHtml(rawText) { return rawText.replace(/[]/g, (c) c ‘’ ? ‘lt;’ : ‘gt;’); } // 在调用 markdownToJSON 之前 const safeMarkdown escapeRawHtml(aiRawResponse);链接安全 如前所述在markdown-it的validateLink钩子中实施策略。只允许http://和https://开头的链接。对于图片链接甚至可以设置一个代理白名单防止盗链和潜在的不良内容。数据大小限制 对单次AI回复的Markdown文本长度进行限制防止超长内容导致解析器性能下降或内存溢出。5.2 输出控制前端的防线前端是最后一道防线即便数据来自“可信”的后端也应遵循安全最佳实践。绝不信任输入 对待后端传来的AST数据也要进行验证。例如检查image.src是否是一个字符串link.href是否符合预期格式。虽然AST是我们自己定义的但防御性编程是有益的。组件级安全策略Link组件 如上文实现必须校验协议并为外链添加rel“noopener noreferrer”属性防止window.opener漏洞。Image组件 可以考虑实现一个统一的图片代理或懒加载组件在onError事件中替换为默认占位图防止外链图片失效或包含不当内容。Iframe/脚本 在我们的场景中Markdown通常不应解析出iframe或script。但如果未来支持自定义HTML块必须彻底禁止这类标签。CSP内容安全策略 在Web应用层面配置严格的CSP HTTP头是终极防护。它可以禁止内联脚本、限制资源加载的源如图片、样式、字体即使有恶意脚本被注入也无法执行。Content-Security-Policy: default-src ‘self’; img-src ‘self’ https://trusted-cdn.com; style-src ‘self’ ‘unsafe-inline’; script-src ‘self’;这个策略表示默认只允许加载同源资源图片允许同源和https://trusted-cdn.com样式允许同源和内联样式某些代码高亮库可能需要脚本只允许同源。5.3 处理AI的“幻觉”与不规则标记AI并非完美它可能生成不合规的Markdown例如未闭合的**加粗、嵌套混乱的列表甚至是一些自创的“伪Markdown”语法。解析器的容错性 选择一个容错性好的解析库markdown-it在这方面表现不错。它通常能自动修正一些常见的错误比如将未配对的*视为普通星号字符。后处理与降级 在将AST返回给前端前可以遍历AST进行一次“清理”。例如发现一个strong_open节点没有对应的strong_close节点可以自动为其补全或者将整个段落降级为纯文本节点。这比直接渲染出奇怪的样式要好。前端降级渲染 在前端组件中如果遇到无法识别或结构破损的节点类型应有降级方案。例如Text组件遇到未知的内联节点可以将其内容作为纯文本渲染并记录错误日志而不是直接崩溃或渲染空白。安全红线关于dangerouslySetInnerHTML的警示如果你的方案是后端返回HTML字符串前端使用v-html或dangerouslySetInnerHTML那么你必须使用像DOMPurify这样的库在客户端进行二次净化。永远不要相信后端传来的、未经净化的HTML。DOMPurify可以配置一个非常严格的允许标签和属性列表过滤掉所有危险元素和事件处理器。即便如此混合方案中后端生成HTML的方式其安全风险和维护成本依然高于结构化数据方案。我个人强烈推荐后者。6. 扩展与优化让渲染引擎更强大基础功能实现后我们可以着眼于此方案的扩展潜力让它不仅能渲染标准Markdown还能适应更丰富的交互需求。6.1 支持扩展语法与自定义组件AI的应用场景多样有时我们可能希望它返回一些标准Markdown不支持的元素比如一个可交互的按钮、一个进度条、或一个特殊的数据图表。定义自定义容器 可以利用Markdown的扩展语法比如围栏代码块的变种。例如约定:::warning和:::之间包裹的内容渲染为警告提示框。:::warning 这是一条重要的警告信息。 :::后端解析器需要识别这种自定义语法并在AST中生成一个type: ‘custom_warning’的节点。前端注册自定义组件 在前端的componentMap中为custom_warning注册一个WarningBox.vue组件。这个组件可以有自己的样式和图标实现丰富的渲染效果。属性传递 甚至可以支持更复杂的语法从标记中提取属性。例如:::chart type“line” data“{...}” :::后端解析出type和data属性前端Chart组件接收这些属性并渲染对应的图表。6.2 代码块的深度交互代码块不仅仅是静态高亮我们可以让它变得有用。一键复制 在CodeBlock组件右上角添加一个复制按钮点击后使用navigator.clipboard.writeTextAPI将代码内容复制到剪贴板。语言检测与切换 如果AI返回的代码块未指定语言或语言不准确前端可以集成一个轻量级的语言检测库如highlight.js的highlightAuto提供“检测语言”或“切换语言”的选项。代码执行沙盒环境 对于某些教育或演示场景如果代码是JavaScript且经过严格安全审查可以考虑在iframe沙盒中安全地运行它展示运行结果。这是一个高风险功能必须极其谨慎通常仅用于完全可控的内部环境。6.3 性能与可访问性图片懒加载 对Image组件实现懒加载使用Intersection Observer API监听图片是否进入视口再加载真实图片源提升首屏速度。可访问性A11y为CodeBlock添加role“code”和aria-label属性描述代码块的作用。确保Heading组件生成正确的h1到h6标签并保持层级结构方便屏幕阅读器导航。为Link组件提供清晰的链接文本避免使用“点击这里”这种模糊的描述。深色模式适配 代码高亮主题、边框颜色、背景色等都需要适配深色模式。可以通过CSS变量Custom Properties来定义颜色主题使切换变得容易。实现AI回复的Markdown渲染远不止是调用一个库那么简单。它是一次对数据流、安全模型和用户体验的综合设计。从最初在后端返回HTML的简单想法到最终确立“结构化数据 前端组件化渲染”的混合架构这个过程让我深刻体会到在追求功能的同时安全性、可维护性和未来扩展性必须作为同等重要的考量因素。现在当看到AI生成的复杂步骤清单、格式清晰的代码示例或数据表格能够在前端完美地呈现出来时那种体验的提升是实实在在的。这个方案也为后续集成更丰富的交互元素如可折叠的详情块、内嵌的简单图表铺平了道路让AI与用户的对话界面真正成为一个强大而美观的信息交付平台。