应优先使用 textcontent 更新纯文本，仅在需浏览器解析 html 标签时才用 innerhtml；处理不可信富文本须用 dompurify 等白名单方案净化，禁用 innertext 作安全兜底。
用 innerHTML 修改结构、用 textContent 更新纯文本，是两种根本不同的操作——选错不仅有安全风险，还会破坏交互或性能。关键不是“怎么写”，而是“为什么这么选”。
什么时候必须用 innerHTML
只有当你需要浏览器真正解析并渲染 HTML 标签时，才用 innerHTML。比如插入加粗、链接、换行、列表等带语义的富文本。
- 动态生成带格式的提示信息：
el.innerHTML = "请检查 <strong>邮箱格式</strong> 并重试" - 渲染服务端返回的轻量富文本（如后台编辑器内容），但前提是已做过滤
- 整块替换一个区域，且内容完全可控（例如硬编码的模板：
box.innerHTML = "<h2>欢迎页</h2> <p>点击开始</p>"）
⚠️ 只要字符串里拼接了任何外部数据（用户输入、URL 参数、API 返回值），就立刻进入高危区——<img onerror="alert(1)"> 这类代码会被执行。
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
为什么 textContent 是默认首选
90% 的文本更新场景，你其实只需要显示一段文字，不希望它被当 HTML 解析。这时候 textContent 不仅安全，还更快、更稳定。
- 表单校验提示：
errorEl.textContent = "密码不能少于6位"—— 即使用户输入了<script>fetch('/steal')</script>，也只当普通字符显示 - 日志面板、代码预览区、评论列表的文字内容
- 动态标题、状态栏、计数器等纯文本字段
它不会清空子节点，不触发重排，不丢失事件监听器，也不重置 input 的 value 值——这些是 innerHTML 做不到的。
不可信内容想渲染 HTML？别手写过滤
正则匹配 <script></script> 或删掉 onclick 属性，几乎必然被绕过。真实攻击常藏在 onanimationstart、href="javascript:"、SVG 事件里。
- 前端处理：用 DOMPurify 白名单净化：
el.innerHTML = DOMPurify.sanitize(dirtyHtml, {ALLOWED_TAGS: ['b','i','br'], ALLOWED_ATTR: ['class']}) - 服务端处理：在 API 返回前就过滤（如 Node.js 用
sanitize-html），前端只负责渲染，责任分离更可靠 - 替代方案：把富文本转成 Markdown 渲染，或用
contenteditable+ 自研编辑器控制输出
别用 innerText 当安全兜底
innerText 看起来像 textContent，但它受 CSS 影响（display: none 的文字不计入）、会自动折叠空白、在表格中行为异常，还会强制触发重排——这不是“稍弱一点的安全选项”，而是逻辑上就不该用于防 XSS。
- 需要兼容 IE8？可以加降级：
el.textContent !== undefined ? el.textContent = txt : el.innerText = txt - 但现代项目请坚定使用 textContent，它定义清晰、表现一致、无副作用
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
