当你用innerHTML插入用户输入或动态数据时，XSS攻击就找到了入口。攻击者可以注入恶意脚本，窃取用户cookie、劫持会话或破坏页面。根本的解决方案是放弃innerHTML，改用textContent或innerText，它们不会解析HTML标签，直接将内容作为纯文本处理，从而彻底杜绝XSS风险。

innerHTML为何成为XSS的温床？

innerHTML属性会解析字符串中的HTML标签和JavaScript代码，并执行它们。这意味着，如果字符串包含

<script>alert('XSS')</script>

这样的脚本，它就会在页面中运行。常见的风险场景包括：用户评论、动态渲染的API数据、URL参数拼接的内容等。即使你对输入进行过滤，复杂的绕过技巧（如编码、事件处理器onclick等）也可能使防御失效。

textContent与innerText的安全机制

textContent和innerText都不会解析HTML。它们将传入的内容视为纯文本，原样显示在页面上。例如，即使字符串包含

<div>test</div>

，页面上显示的也只会是"<div>test</div>"这段文字，而不是一个div元素。这从根源上切断了脚本执行的可能性。两者略有区别：textContent获取所有元素的内容（包括隐藏元素），而innerText考虑CSS样式（不返回隐藏元素），但就安全而言，它们都是安全的替代方案。

具体替换方法与代码示例

假设你有一个显示用户名的元素，原本使用innerHTML：

// 危险做法
let userInput = "<script>恶意代码</script>";
document.getElementById('output').innerHTML = userInput;

替换为textContent：

// 安全做法
let userInput = "<script>恶意代码</script>";
document.getElementById('output').textContent = userInput;

此时，页面只会显示文本"<script>恶意代码</script>"，脚本不会执行。对于需要保留格式（如换行）的场景，innerText可能更合适，但同样安全。

何时仍需innerHTML及安全实践

如果你必须渲染HTML（如富文本编辑器内容），则不能直接用textContent。这时需要严格的安全措施：

(1) 在前端和后端都进行输入过滤，使用白名单库（如DOMPurify）清理HTML；

(2) 实施内容安全策略（CSP），限制脚本来源；

(3) 将敏感数据与DOM操作隔离。但原则是：但凡不需要HTML解析，就优先使用textContent。

性能与兼容性考量

textContent通常比innerHTML性能更好，因为它不触发HTML解析和重绘。在兼容性上，textContent支持IE9+，innerText支持IE6+但行为不一致。对于现代应用，textContent是更标准的选择。如果支持旧浏览器，可做特性检测：

element.textContent = content || element.innerText = content;

结合框架的最佳实践

在现代前端框架中，安全机制已内置。例如，React默认转义所有变量，使用{变量}会作为文本处理；Vue的v-text指令等同于textContent。但如果你在框架中使用dangerouslySetInnerHTML或v-html，仍需像原生场景一样谨慎。框架不是银弹，开发者仍需树立“默认不使用HTML解析”的意识。

纵深防御：不止于textContent

替换innerHTML是关键一步，但完整的XSS防御需多层措施：

(1) 输入验证，限制数据类型和长度；

(2) 输出编码，根据上下文（HTML、URL、CSS）进行编码；

(3) 使用HTTP安全头，如CSP；

(4) 定期安全审计。textContent是链条中最简单有效的一环。

总结：改变习惯，从源头杜绝风险

innerHTML的便利性带来了巨大的安全债务。作为开发者，应养成习惯：默认使用textContent，仅在必需时使用innerHTML并辅以严格防护。安全不是可选项，而是代码的一部分。从今天起，检查你的代码库，将所有非必要的innerHTML替换掉，这可能是你为项目做的最快、最有效的安全加固。