textcontent 是纯文本更新的默认选择，适用于90%只需显示字符串的场景，它安全、高效且不触发执行逻辑；innerhtml 仅在必须解析html结构时使用；innertext 因受css影响且不安全，不应作为防xss方案。
textContent 是纯文本更新的默认选择
90% 的场景下，你只是想把一串字符显示在页面上，不希望它被当成 HTML 解析——这时候 textContent 不仅安全，还更快、更稳定。它会把 <script>alert(1)</script> 当作普通字符串渲染，尖括号和引号全变成可见字符，不会触发任何执行逻辑。
常见适用场景包括：
- 表单校验提示：
errorEl.textContent = "邮箱格式错误" - 动态计数器、状态栏、日志面板
- 用户昵称、评论正文、URL 参数解码后展示
它不会清空子节点，不重置 input.value，也不触发重排，DOM 更新可预测。性能实测中，在含 20+ 子节点的容器里连续更新 100 次，textContent 耗时通常只有 innerHTML 的 1/3～1/5。
innerHTML 只在真正需要解析 HTML 时才用
当你必须让浏览器解析并渲染标签结构（比如加粗、链接、换行、列表）时，innerHTML 才是合理选项。但它不是“能用”，而是“不得不”用。
典型使用条件：
- 插入服务端返回的轻量富文本（如后台编辑器内容），但前提是已做过滤
- 动态生成带语义的提示信息：
el.innerHTML = "请检查 <strong>邮箱格式</strong> 并重试" - 整块替换硬编码模板：
box.innerHTML = "<h2>欢迎页</h2> <p>点击开始</p>"
⚠️ 一旦字符串里拼接了任何外部数据（用户输入、API 返回值、URL 参数），就立刻进入高危区。<img onerror="alert(1)"> 这类代码会被执行，且正则手动过滤几乎必然被绕过。
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
别拿 innerText 当安全兜底
innerText 看起来像 textContent，但它受 CSS 影响（display: none 的文字不计入）、自动折叠空白、在表格中行为异常，还会强制触发重排——这不是“稍弱一点的安全选项”，而是逻辑上就不该用于防 XSS。
例如：
-
el.innerText = "<script>fetch('/steal')</script>"→ 页面可能不显示，也可能部分显示，行为不可控 - 表格单元格中调用
innerText可能漏掉某些嵌套文本 - 它依赖布局计算，首次读取会强制同步重排，影响性能
截至 2026 年 4 月，所有主流框架和安全指南都明确建议：禁用 innerText 作安全替代方案。
不可信富文本必须用 DOMPurify 白名单净化
如果业务确实要渲染用户提交的富文本（比如评论里的简单格式），不能靠手写正则或删 onclick 属性来“差不多就行”。真实攻击常藏在 onanimationstart、href="javascript:"、SVG 事件里。
正确做法是引入 DOMPurify 并白名单控制：
el.innerHTML = DOMPurify.sanitize(dirtyHtml, {
ALLOWED_TAGS: ['b', 'i', 'br', 'p', 'a'],
ALLOWED_ATTR: ['href', 'class']
});
关键点：
- 服务端也应做一次过滤，前后端双重防护不能省
- 避免模板字符串拼接后直接赋给
innerHTML：el.innerHTML = `<div>${userInput}</div>`和裸赋值没区别 - 如果结构复杂（比如消息里混着用户文本 + 系统 @ 提及），得靠结构化数据 + 安全渲染函数，而不是靠属性切换糊弄
真正难处理的从来不是“该用哪个 API”，而是业务里文本和 HTML 的边界模糊——这种地方最容易漏掉净化环节，也最容易被当成“小问题”跳过。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
