innerHTML是浏览器级HTML解析器，赋值时会销毁子节点、解析字符串并重建DOM，导致事件丢失、状态重置、性能下降及必然XSS风险；仅当内容可信、经DOMPurify净化、需渲染结构且配置CSP时才可谨慎使用。
innerHTML 可以读写元素内部的 HTML 字符串，但它不是“安全的文本操作接口”，而是浏览器级的 HTML 解析器——只要内容含未过滤的用户输入，就等于主动邀请 XSS。
innerHTML 读写行为：解析、重建、丢失状态
赋值 el.innerHTML = str 时，浏览器会做三件事：销毁当前所有子节点、将 str 当作 HTML 源码解析、构建新 DOM 树并挂载。这导致：
- 原有绑定的事件监听器全部失效
- 表单控件（如
<input>）的当前值、焦点、选择范围被重置 - 自定义属性（
data-*）、CSS 动画状态、Web Component 生命周期钩子中断 - 性能开销明显高于纯文本操作（尤其在大列表中反复赋值）
读取时 el.innerHTML 返回的是序列化后的 HTML 字符串，已转义实体（如 &），但不反映运行时 DOM 状态（比如 JS 修改过的 value 或 checked）。
XSS 风险不是“可能”，而是“必然发生”
只要把用户可控数据（URL 参数、API 返回字段、表单输入）未经净化直接塞进 innerHTML，攻击者就能注入执行任意脚本。典型触发方式包括：
立即学习“前端免费学习笔记（深入）”；
<script>fetch('/api/steal?c='+document.cookie)</script><img src=x onerror=eval(atob('YWxlcnQoMSk='))><svg onload=alert(1)>- 甚至空格绕过：
<IMG SRC="x" ONERROR="alert(1)">（大小写+空格仍被解析）
注意：onerror、onload、javascript: 协议、data: URI 中的 JS 等，都无需 <script> 标签即可触发。
什么情况下能用 innerHTML？必须满足全部条件
只有同时满足以下四点，才可考虑使用 innerHTML：
- 内容来源绝对可信（如硬编码字符串、内部 CMS 后台发布的富文本，且该后台本身有服务端净化）
- 前端已引入并调用
DOMPurify.sanitize()进行二次过滤（不能只靠后端） - 明确需要渲染结构（如带
<strong>、<ul>的公告），且无法用textContent替代 - 已配置 CSP 响应头：
Content-Security-Policy: default-src 'self'; script-src 'self'; object-src 'none'
示例安全写法：
import DOMPurify from 'dompurify'; const raw = '<div onclick="bad()"><script>alert(1)</script>Hello</div>'; const clean = DOMPurify.sanitize(raw); // → '<div>Hello</div>' el.innerHTML = clean;
更简单、更安全的替代方案优先级排序
绝大多数场景根本不需要 innerHTML：
- 只显示纯文本（评论、日志、错误提示）→ 用
textContent，自动转义<、&等字符，无 XSS，不破坏 DOM - 需加 class 或包裹标签（如高亮搜索词）→ 用
document.createElement()+textContent+append() - 批量插入同构列表（如用户列表）→ 用
DocumentFragment批量创建再一次性 append，避免重复 layout - React/Vue 等框架中 → 绝对避免
dangerouslySetInnerHTML/v-html，除非已用 DOMPurify 包裹
真正难处理的不是技术选型，而是业务方坚持“必须支持用户发带样式的公告”。这时候，净化逻辑必须下沉到服务端，前端只负责调用净化后的 HTML —— 浏览器端净化只是兜底，不是主力防线。
