innerHTML 直接赋值危险，因浏览器会解析并执行其中的 HTML 和脚本，若内容来自用户或第三方，易导致 XSS 攻击；应优先用 textContent 显示纯文本，用 insertAdjacentHTML 替代 innerHTML 并配合校验，服务端需配置 CSP 和正确 Content-Type。
innerHTML 直接赋值为什么危险
因为浏览器会把字符串当 HTML 解析并执行，如果内容来自用户输入或第三方 API，innerHTML = '<script>alert(1)</script>' 就会真的运行脚本。innerHTML 不做任何过滤，也不区分“只是显示文字”还是“要渲染结构”，它只管解析、插入、执行。
常见错误现象：innerHTML 插入评论、富文本编辑器输出、JSON 返回的 HTML 片段后，页面突然弹窗、请求异常发包、用户 cookie 被窃取。
使用场景：你确实需要渲染一段已知安全的 HTML（比如 CMS 后台自己生成的静态模块），且能 100% 控制来源——这时候 innerHTML 最快最直接。
用 insertAdjacentHTML 替代 innerHTML 更可控
insertAdjacentHTML 和 innerHTML 都解析 HTML 字符串，但它不替换整个节点内容，而是按位置插入，副作用更小，也更容易做前置校验。
立即学习“前端免费学习笔记（深入）”；
实操建议：
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
- 始终指定第二个参数为
'beforeend'（等价于追加到子元素末尾），避免误用'afterbegin'导致结构错乱 - 插入前先用正则粗筛明显危险标签：
if (htmlStr.includes('<script') || htmlStr.includes('javascript:')) { throw new Error('unsafe HTML'); } - 它不会自动清理已存在的事件监听器，如果反复插入同一区域，注意用
removeEventListener或委托方式管理绑定
纯文本内容一律用 textContent
如果你只是想显示一段带尖括号或引号的用户输入（比如日志、代码片段、错误消息），textContent 是唯一正确选择。它把所有字符当纯文本处理，<strong>hello</strong> 会原样显示成文字，不会加粗。
容易踩的坑：
- 误用
innerText：它受 CSS 样式影响（比如display: none的文本不计入），且在 Firefox 中行为不一致 - 混用
textContent和innerHTML在同一个父节点下：后者插入的 HTML 节点会被前者覆盖掉，顺序和意图容易错乱 - 想高亮关键词但又怕 XSS？先用
textContent渲染全文，再用 DOM 方法找文本节点手动包裹<mark>，别拼 HTML 字符串
服务端返回 HTML 片段时必须声明 Content-Type 和 CSP
即使前端做了过滤，服务端也要配合加固。如果 API 返回的是 HTML 片段（比如 /api/widget?name=sidebar），响应头里必须包含 Content-Type: text/html; charset=utf-8，否则浏览器可能按 text/plain 处理导致解析异常。
更重要的是 CSP（内容安全策略）：
- 设置
script-src 'none'可彻底禁止内联脚本执行，让<script>标签失效（但仍会解析 DOM 结构） - 若需允许特定 CDN 脚本，写成
script-src 'self' https://cdn.example.com，别加'unsafe-inline' - CSP 对
innerHTML和insertAdjacentHTML一视同仁，只要含<script>就拦截，这是最后一道防线
真正麻烦的是那些嵌套了 onerror="fetch(...)" 或 <img src=x onerror=...> 的“伪静态”HTML——它们不依赖 <script> 标签，CSP 无法拦截，只能靠前端白名单解析或服务端预处理剔除。
