textContent 是规避 XSS 最简单可靠的做法，因其纯文本写入、不解析 HTML；innerText 不防 XSS，因它不转义标签、仅模拟视觉文本呈现，且在部分浏览器中仍可能触发渲染。
直接用 textContent 替代 innerText 做文本写入，是规避 XSS 类安全漏洞最简单、最可靠的做法。
为什么 innerText 不能防 XSS
很多人误以为 innerText 会自动转义 HTML 标签，所以“更安全”。但事实是：
• innerText 的设计目标是模拟用户看到的文本，不是做内容过滤；
• 它在设置值时虽会把 、<code>& 等字符转义为实体（如 <），但这只是副作用，并非安全机制；
• 更关键的是：innerText 在某些旧版浏览器或特殊结构（如表格单元格、contenteditable 元素）中行为不稳定，可能意外渲染标签；
• 它还会触发页面重排（reflow），带来性能隐患，且无法保证跨浏览器一致性。
textContent 是真正安全的文本写入方式
textContent 的语义就是“纯文本操作”，它天然具备三重防护：
• 所有字符（包括 <script></script>、onclick=）都被当作普通字符串处理，不会被解析为 HTML 或执行脚本；
• 不重建 DOM，不丢失事件监听器、表单状态或自定义属性；
• 不受 CSS 样式影响（比如 display: none 不会导致内容被跳过），行为稳定可预测。
例如：el.textContent = "<img src=x onerror=alert(1)>";
浏览器只会显示一串明文，绝不会触发弹窗。
哪些场景必须用 textContent 而非 innerText
以下情况一律推荐使用 textContent：
• 展示用户提交的评论、日志、代码片段、JSON 响应等原始内容；
• 后端返回的富文本需降级为纯文本展示（如邮件预览、摘要提取）；
• 构建 SSR/同构应用时，确保客户端与服务端文本输出完全一致；
• 对性能敏感的操作（如高频更新列表项文字），避免 innerText 引发的强制回流。
不要混合使用或 fallback 到 innerText
虽然过去为兼容 IE8 会写 el.innerText || el.textContent，但现在已无必要：
• 所有现代浏览器（Chrome/Firefox/Safari/Edge）均完整支持 textContent；
• 若需支持极老旧环境（如 IE8），应单独封装转义函数，而非依赖 innerText 的不可靠行为；
• 即使要 fallback，也应优先用 textContent，仅在它不存在时才考虑 innerText —— 而不是反过来。
