textcontent是读写纯文本最安全直接的方式，不解析html、不执行脚本、不触发重排；适用于错误提示、用户名、日志等纯文本场景，而innerhtml仅在必须解析html结构时使用。
textContent 是读写纯文本内容最安全、最直接的方式——它不解析 HTML、不执行脚本、不触发重排，且行为跨浏览器一致。只要你不打算渲染标签，就该默认用它。
什么时候必须用 textContent 而不是 innerHTML
你只是显示或更新一段文字，比如错误提示、用户名、日志行、标题、计数器，或者从表单里提取用户输入的纯文本内容。这些场景下：
-
textContent会自动转义所有 HTML 字符：<script>alert(1)</script>原样显示为文字，不会执行 - 它不重置
<input>的value，也不清空已绑定的事件监听器 - 它保留原始空白和换行（包括
\n和缩进），不像innerText那样受 CSS 影响或自动折叠 - 对隐藏元素（
display: none或visibility: hidden）依然能读取其文本，适合采集完整内容
为什么不能用 innerText 替代 textContent 来“兜底”
innerText 不是更“兼容”的安全选项，而是逻辑完全不同、且不可靠的属性：
- 它会跳过
display: none元素里的文本，导致内容丢失 - 在表格中行为异常（如
<td> 内文本可能被忽略） <li>某些 Safari 版本读取时会强制触发 layout 计算，拖慢性能</li> <li>在 <code><input>或<textarea></textarea>上读取的是“渲染后可见文本”，不是真实值（比如被 CSS 截断的部分） - 它不标准、不推荐用于防 XSS，W3C 明确将
textContent作为首选
如何从 HTML 字符串中提取纯文本（还没插入 DOM）
不能对字符串直接调 textContent——它是 DOM 方法，必须作用于节点。正确做法是先解析再取值：
function htmlToText(html) {
const parser = new DOMParser();
const doc = parser.parseFromString(html, 'text/html');
return doc.body.textContent || '';
}
// 示例：htmlToText('<p>Hello <strong>world</strong></p>') → "Hello world"
注意：DOMParser 不会执行脚本、不加载外部资源，比创建临时 <div> 更轻量、更可控；但也不会解析 HTML 实体（如 <code> ），如需转义，得额外处理。
写入时容易踩的坑：别在富文本场景误用 textContent
如果你需要渲染加粗、链接、换行等结构化内容，textContent 就不合适了——它会把 <strong>hello</strong> 当作纯字符显示，而不是加粗文本。
- 真要渲染 HTML，必须用
innerHTML，但前提是内容可信或已白名单净化（如DOMPurify.sanitize(dirtyHtml)） - 拼接用户输入、API 返回值、URL 参数到
innerHTML中，等于主动引入 XSS 风险 - 想保留换行效果？
textContent里的\n不会被浏览器渲染为换行，得配合white-space: pre-lineCSS，或改用innerHTML+replace(/\n/g, '<br>')（仅限可信内容）
真正复杂的点在于边界判断：一个字段到底是“纯文本”还是“带格式内容”？很多 bug 和漏洞都出在这里——不是 API 返回了 HTML 字符串，你就该用 innerHTML；而是你是否明确需要浏览器去解析它。一旦混淆，安全、性能、交互全受影响。
