咨询不使用v-html与innerHTML实现XSS安全的博客内容渲染方案

你遇到的“markdown/富文本渲染必须依赖innerHTML注入”只是长期开发形成的惯性路径，并非不可替代的技术要求。整体实现不需要颠覆现有编辑器、解析器的技术栈，只需要调整原有的渲染链路即可。

核心实现思路 #

把传统的「解析用户内容→拼接生成完整HTML字符串→通过innerHTML/v-html注入页面」的流程，替换为「解析用户内容→生成结构化的抽象节点树→通过原生DOM API逐节点在页面上构建元素」的流程，全程不接触innerHTML或v-html，从链路设计上杜绝XSS注入的可能。

具体落地步骤 #

• 调整解析器输出目标：你提到的marked官方示例只是为了演示最简化的接入效果，并非固定的使用范式。marked、markdown-it等主流markdown解析库，以及ProseMirror、TipTap等主流WYSIWYG编辑器，本身都支持输出结构化的节点树，不需要强制生成HTML字符串。比如使用marked时，直接调用lexer方法拿到逐节点的解析结果，跳过它自带的HTML字符串拼接逻辑即可。
• 逐节点做安全渲染：遍历拿到的结构化节点树，只创建白名单内的合法标签（h1-h6、p、strong、em、code、pre、a、img、ul/ol/li等），所有用户输入的文本内容统一通过textContent属性写入。textContent本身不会解析HTML标签，用户输入的<script>、事件属性等恶意内容，都会被当成普通纯文本展示，不会被浏览器执行。
• 前置校验属性合法性：涉及a标签的href、img标签的src这类可跳转、可加载外部资源的属性，先过滤掉javascript:、危险场景下的data:协议，只保留http/https/站点相对路径这类白名单内的合法值，再通过setAttribute写入对应标签即可。

常见误区澄清 #

• 这套链路不需要额外引入专业的HTML消毒工具：因为所有可渲染的标签都是代码中硬编码的白名单节点，没有任何环节会把用户输入的片段当成HTML解析，自然不存在恶意脚本注入的入口。
• 最终渲染的DOM结构和传统innerHTML方式完全一致：逐元素构建出来的页面结构，和浏览器解析HTML字符串生成的DOM没有区别，不会出现样式错位、格式异常的问题。

内容的提问来源于stack exchange，提问作者khernik