js 中 innerHTML 属性作用 js 中 innerHTML 属性的使用场景

而当你给innerHTML赋值时，这才是它真正强大的地方。你把一段HTML格式的字符串赋给它，浏览器会立刻解析这段字符串，然后用解析后的新内容完全替换掉原元素内部的所有子节点。这意味着，你不需要一个一个地创建元素、设置属性、再追加到DOM树上，只需要一行代码就能完成复杂的DOM结构更新。我个人觉得，对于那些需要快速替换或加载大块HTML内容的场景，比如从服务器获取了一段渲染好的HTML片段，直接用innerHTML赋值是最直接、最省事的办法。

立即学习“前端免费学习笔记（深入）”；

举个例子，如果你有一个空的div，想往里面加一个段落和一个链接：

let myDiv = document.getElementById('myContainer');
myDiv.innerHTML = '
这是一段新的内容。
点击这里';

执行这行代码后，myContainer这个div里面就会立刻出现一个p标签和一个a标签。这种方式，在需要动态生成或者更新大量结构化内容时，效率是显而易见的。不过，它的便利性也伴随着一些需要深思熟虑的风险和局限性。

innerHTML 和 textContent 有什么区别？

这是一个前端开发者经常会遇到的问题，也是理解innerHTML的关键所在。说实话，我刚开始接触DOM操作的时候，也经常把它们搞混。简单来说，innerHTML处理的是HTML结构，而textContent处理的只是纯文本。

具体点讲，当你使用textContent时，它只会获取或设置元素的纯文本内容，会忽略所有的HTML标签。比如，如果你的div里有

Hello World!

相比之下，innerHTML则完全不同。它会把所有HTML标签都包含在内，并且当你赋值时，它会把字符串当作HTML来解析。所以，如果你把

Hello World!

在我看来，选择哪个取决于你的具体需求：

• 如果你需要操作或显示包含HTML标签的结构化内容，innerHTML是你的选择。
• 如果你只需要处理纯文本，不希望任何HTML标签被解析，并且关心安全性（尤其是用户输入），那么textContent无疑是更优、更安全的方案。我个人在使用用户输入时，总是优先考虑textContent或者更精细的DOM操作，以避免不必要的麻烦。

使用 innerHTML 时需要注意哪些安全风险？

谈到innerHTML，安全风险是绝对绕不开的话题，而且这风险可不小。最主要的就是跨站脚本攻击（XSS）。这玩意儿，说白了就是攻击者通过某种方式，把恶意脚本注入到你的网页里，然后这段脚本在用户的浏览器上执行，从而窃取用户数据、劫持会话，甚至篡改页面内容。

科大讯飞-AI虚拟主播

科大讯飞推出的移动互联网智能交互平台，为开发者免费提供：涵盖语音能力增强型SDK，一站式人机智能语音交互解决方案，专业全面的移动应用分析；

下载

innerHTML之所以容易成为XSS的温床，就在于它会直接解析你给它的字符串。如果这个字符串来源于不可信的源（比如用户输入、第三方API返回的数据），并且没有经过严格的净化处理，那么攻击者就可以在其中嵌入标签，或者利用HTML属性（如onerror、onload等）来执行恶意JavaScript代码。

举个例子，如果你的代码是这样：

let userInput = "@@##@@"; // 假设这是用户输入
document.getElementById('displayArea').innerHTML = userInput;

当这段代码执行时，displayArea这个元素会尝试加载一个不存在的图片，然后onerror事件就会触发，执行alert("你被攻击了！")。这只是一个简单的示例，实际的攻击会复杂得多，危害也大得多。

所以，我的建议是：永远不要直接将未经净化的、来自用户或不可信源的字符串赋值给innerHTML。 这句话我可能要强调一百遍。

那么怎么解决呢？

1. 优先使用 textContent 或 DOM 操作： 如果你只是想显示纯文本，或者只修改某个元素的属性，完全没有必要使用innerHTML。直接用textContent或者document.createElement()、appendChild()等方法来构建DOM，会安全得多。
2. 内容净化（Sanitization）： 如果你确实需要插入HTML，并且内容来自不可信源，那么在赋值给innerHTML之前，必须对内容进行严格的净化。这意味着你需要移除所有潜在的恶意标签和属性。市面上有一些成熟的库可以帮助你做这件事，比如DOMPurify。它会解析你的HTML字符串，然后只保留安全的标签和属性，移除所有不安全的。
3. CSP（Content Security Policy）： 这是一种浏览器安全机制，可以限制网页中可执行脚本的来源，即使有XSS漏洞，也能在一定程度上降低攻击的危害。但这更多是防御的最后一道防线，而不是解决innerHTML本身带来的风险。

记住，安全不是一蹴而就的，它需要我们时刻保持警惕和审慎。

什么时候应该避免使用 innerHTML？

虽然innerHTML用起来很方便，但并非所有场景都适合它。在我日常的开发中，有些情况我会本能地避免使用它，或者说，我会去寻找更优的替代方案。

1. 频繁更新小部分内容时： 如果你只是想更新一个元素内部的一小段文本，或者修改某个子元素的样式、属性，直接使用innerHTML会显得非常低效。因为每次赋值，浏览器都需要重新解析整个字符串，然后销毁旧的DOM节点，再创建新的DOM节点。这个过程开销很大。这时候，直接操作具体的子元素（比如childElement.textContent = 'new text'，或者childElement.style.color = 'red'）会高效得多。我曾经见过一些新手，为了改一个数字，把整个父元素的innerHTML都重新赋值一遍，这简直就是性能杀手。

2. 需要追加内容而不是替换内容时： innerHTML的赋值操作是完全替换。如果你想在现有内容的基础上追加新的HTML，比如在一个列表中添加一个新的列表项，直接用innerHTML += '

3. 新项
'虽然语法上可行，但效率极低。它会先读取整个innerHTML，然后拼接新内容，再重新赋值。这会导致整个元素内部的DOM树被重新解析和渲染。更优的做法是使用element.insertAdjacentHTML('beforeend', '
4. 新项
')，或者更推荐的DOM操作方法：document.createElement()配合appendChild()。insertAdjacentHTML性能更好，因为它只解析和插入新内容，不会动到原有结构。

5. 处理用户输入或其他不可信数据时： 这一点在前面的安全风险部分已经强调过了，这里再提一次，因为实在太重要了。任何时候，只要你处理的数据可能来自外部，尤其是用户可以直接控制的输入，就绝不能直接赋值给innerHTML。这几乎是前端安全的黄金法则。

6. 构建复杂的DOM结构时： 如果你需要动态地构建一个非常复杂的、嵌套层级很深的DOM结构，用字符串拼接innerHTML会变得异常痛苦和容易出错。代码可读性会变得很差，调试也困难。这时候，我会倾向于使用document.createElement()、appendChild()、setAttribute()等原生的DOM操作方法。虽然这些方法看起来更“啰嗦”，但它们提供了更精细的控制，代码逻辑也更清晰，更易于维护。在现代前端框架（如React, Vue）中，它们通过虚拟DOM来优化这些操作，本质上也是避免了直接、频繁地操作真实DOM，从而提升性能和开发体验。

总而言之，innerHTML就像一把瑞士军刀，功能强大且方便，但不是所有任务的最佳工具。理解它的工作原理和局限性，才能在合适的场景下发挥它的最大价值，同时规避潜在的风险。