豆包AI写Markdown实用技巧分享

本文深入解析了在前端集成豆包AI生成的Markdown内容时必须直面的一系列关键挑战与实战方案：从手动解析标记（需借助marked等库而非依赖自动渲染）、统一代码块语言标识以保障语法高亮准确生效，到严防XSS注入（必须用DOMPurify白名单净化，彻底摒弃已废弃的marked内置sanitize）、解决实时预览中光标错乱与性能卡顿问题（结合节流、选区恢复与ref控制），再到应对混合编辑场景的底层复杂性——每一步都踩在真实开发的痛点上，既讲清原理陷阱，又给出可落地的轻量级或专业级解法，助你安全、稳定、丝滑地将AI输出真正“活”在页面上。

豆包AI输出的Markdown源码不自动渲染，得手动处理

豆包AI生成的文本里含**加粗**、*斜体*、```js等Markdown标记，但前端直接innerHTML插入会原样显示，不是渲染效果。它不替你做解析，只管“写出来”。

常见错误现象：

**Hello**

print(1)

• 用marked（轻量）或remarkable（可配选项多）这类库做客户端解析，别手写正则——Markdown嵌套和转义太容易翻车
• 如果只支持有限语法（比如只要标题/列表/代码块），可用DOMPurify.sanitize()配合简单转换函数，比全量解析快且安全
• 注意marked默认不启用gfm（GitHub Flavored Markdown），表格、任务列表要显式开：marked.setOptions({ gfm: true })

代码块语言标识丢失或错乱

豆包AI有时输出```javascript，有时是```js，甚至```后面空着——这会让highlight.js或Prism无法触发语法高亮，或高亮成错的语言。

使用场景：用户复制粘贴后想立刻看到带颜色的代码，而不是灰扑扑的等宽字体。

• 预处理时统一归一化语言标识：用正则把```[ \t]*(\w+)捕获后映射到标准名，例如js→javascript、py→python
• 对空语言标识（```）默认 fallback 为plaintext，避免Prism报Language not loaded警告
• highlight.js 9.x 起要求显式注册语言，记得调hljs.registerLanguage('javascript', js)，否则即使写了```js也白搭

前端插入Markdown内容时XSS风险被低估

豆包AI本身不注入脚本，但它不阻止用户在提问中夹带，然后AI可能原样复述进输出——尤其当提示词含“保持原文格式”之类时。

错误现象：页面弹窗、接口被悄悄调用、document.cookie泄露。

• 绝不能用innerHTML = marked(text)，必须先过一遍DOMPurify.sanitize()，且配置{ ALLOWED_TAGS: [...] }白名单（留pre、code、strong等，砍掉script、iframe、onerror类属性）
• marked的sanitize: true选项早已废弃，别信旧文档；它只防基础HTML，不防javascript:alert()这类伪协议
• 如果业务允许，服务端提前用marked+DOMPurify双处理，前端只负责渲染，更稳

实时预览下光标位置错乱

用户边打字边看右侧Markdown渲染结果，但输入框光标老跳到开头或末尾——本质是React/Vue重渲染时textarea没维持焦点和选区。

性能影响：每次按键都触发完整Markdown解析+DOM替换，卡顿明显，尤其长文。

• 用useRef（React）或ref（Vue）绑定textarea，在useEffect/生命周期钩子里恢复光标位置，靠selectionStart/selectionEnd
• 加节流：不是每次input事件都解析，用setTimeout延后300ms，连续输就清前一个定时器
• 避免把整个div#preview设为contenteditable来“假装编辑”，豆包输出的HTML结构不可控，光标行为更难预测

真正麻烦的是混合内容：一段文字里既有用户手动写的**粗体**，又有AI补全的```sql，还得让光标在两者间无缝移动——这时候纯前端方案容易力不从心，得考虑分段控制或换用ProseMirror这类富文本底层。

以上就是本文的全部内容了，是否有顺利帮助你解决问题？若是能给你带来学习上的帮助，请大家多多支持golang学习网！更多关于科技周边的相关知识，也可关注golang学习网公众号。