textContent可直接替代innerHTML插入纯文本，如错误提示、用户名、日志等，自动转义防XSS且不解析标签；但若需渲染HTML结构（加粗、换行、按钮），则不可替换，须用DOMPurify净化后使用innerHTML。
什么时候能直接用 textContent 替代 innerHTML
只要你要插入的内容是纯文本（比如错误提示、用户名、日志行、搜索关键词），且不依赖 HTML 标签渲染效果，就能安全替换。它不会解析任何标签，<script></script>、<strong>、onclick= 全部原样显示为字符。
常见可替换场景：
- 表单校验提示：
errorEl.textContent = errorMsg—— 即使errorMsg是"邮箱含 <script>alert(1)</script>"，也只显示文字 - 用户资料展示：
nameEl.textContent = userData.name—— 防止昵称里藏<img onerror=...> - URL 参数高亮：
searchTermEl.textContent = new URLSearchParams(location.search).get('q') - 代码片段预览：
preEl.textContent = "function foo() { return '<div>' + x; }" <h3>哪些情况不能硬切 <code>textContent，否则会破坏功能如果你原本靠
innerHTML渲染结构（比如加粗、换行、列表、按钮），换成textContent后，用户看到的是源码，不是效果。典型误用：
立即学习“前端免费学习笔记（深入）”；
- Markdown 渲染结果直接塞进
textContent→ 显示<p>Hello</p>，而非换行后的 Hello - 富文本编辑器输出：
editorOutput = "<strong>重点</strong>说明"→el.textContent = editorOutput会失去加粗 - 动态生成带 class 的按钮：
el.innerHTML = '<button class="btn">提交</button>'→ 改用textContent后只剩字符串
此时必须保留
innerHTML，但得走净化流程，不能跳过。为什么别用
innerText当备选innerText不是textContent的安全平替，它行为不稳定，还可能引入新问题：- 受 CSS 影响：
display: none的子元素内容不计入，visibility: hidden却会计入 - 自动折叠空白：多个空格、换行被压成一个空格，
textContent才严格保留原始格式 - 在
<input>或contenteditable区域表现异常，某些 Safari 版本会意外触发 layout 计算 - 跨浏览器一致性差，W3C 明确推荐
textContent作为纯文本写入标准
追加文本时的坑：别用
innerHTML +=el.innerHTML += "新消息"看似方便，实则三重危险：- 每次执行都会把整个子树转成字符串 → 拼接 → 解析重建，性能差
- 原有事件监听器、
<input>的 value、自定义属性全部丢失 - 若原
innerHTML已含未过滤内容，拼接过程可能放大 XSS 风险
正确做法：
- 纯文本追加：
logEl.textContent += `\n[${new Date().toISOString()}] ${msg}` - 需插入 HTML 结构：
logEl.insertAdjacentHTML('beforeend', '<div class="msg">新消息</div>')，只解析新增部分
真正容易被忽略的是：很多团队只在“首次渲染”时想到
textContent，却在后续追加、更新、拼接环节又退回innerHTML—— 这些地方才是 XSS 漏洞最常复现的位置。 - Markdown 渲染结果直接塞进
