innerhtml会解析执行html，存在xss风险；textcontent仅写入纯文本，自动转义标签，天然防xss且性能更优。
修改 DOM 内容时，innerHTML 和 textContent 的核心安全差异在于：前者会解析并执行 HTML 字符串，存在 XSS 风险；后者只写入纯文本，天然免疫 XSS，也更轻量。
innerHTML：能渲染结构，但必须防 XSS
当你设置 element.innerHTML = "<button onclick='\"alert(1)'>点我</button>"，浏览器会真正创建按钮，并绑定 onclick 事件——这正是危险所在。
- 用户输入若未过滤就拼进 innerHTML（如
el.innerHTML = "<div>" + userInput + "</div>"），可能注入恶意脚本、事件处理器或外链资源 - 即使内容看似“只是标签”，
<img src="x" onerror="fetch('/steal')">这类 payload 仍可触发 - 可信场景下可用，例如后台预处理过的富文本、静态模板片段；否则务必用
DOMPurify.sanitize()或服务端转义后再赋值
textContent：安全、高效，仅作文本展示
设 element.textContent = "<strong>危险</strong>"，页面只会显示字面字符串 危险，所有尖括号被自动转义，不解析、不执行、不渲染。
- 适合错误提示、状态文案、用户名、搜索结果摘要等任何含用户输入的纯文本场景
- 不会重置表单控件的当前值（
<input>.value、<textarea>.value</textarea>不受影响） - 性能更好：不触发重排（reflow），无 HTML 解析开销，空白符（空格、换行）也被原样保留
别误用 innerText 替代 textContent
innerText 行为依赖 CSS 渲染状态：隐藏元素（display: none）、不可见文本、换行折叠、字体度量计算都影响其读写结果。它不是 textContent 的兼容补丁，而是语义不同的属性。
- 需要获取“用户实际看到的文本”（比如模拟复制粘贴）才考虑 innerText
- 现代开发中，只要目标是写纯文本，优先选 textContent —— 标准、稳定、快、安全
- IE8 及更早版本不支持 textContent，但当前已无实际兼容压力
表单控件要单独处理
对 <input>、<textarea></textarea>、<select></select>，不能靠 innerHTML 或 textContent 更新显示值。
- 正确方式是直接赋值对应属性：
input.value = "新内容"、textarea.value = "多行文本" - 用
setAttribute("value", ...)只改初始属性，不改变用户当前输入状态 - 若同时需更新界面文字和表单值，应分别操作：先设
el.value，再用textContent更新旁白或说明文字
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
