写入时，浏览器会解析字符串并构建对应的DOM节点树，这意味着每次设置innerHTML，浏览器都会重新解析字符串并创建节点，如果替换的是一个大型列表，代价会明显上升。
### 字符串拼接的常见误区
很多新手会写出这样的代码：
```javascript
const list = ['苹果', '香蕉', '橙子'];
let html = '';
for (let i = 0; i < list.length; i++) {
html += '<li>' + list[i] + '</li>';
}
document.getElementById('fruitList').innerHTML = html;这种写法在数据量小的时候没问题，但当列表项达到数百甚至上千时，每次循环拼接字符串都会产生中间变量，内存占用和GC压力随之增加，推荐的做法是使用join方法：
const list = ['苹果', '香蕉', '橙子'];
const html = list.map(item => '<li>' + item + '</li>').join('');
document.getElementById('fruitList').innerHTML = html;
innerHTML的性能边界与优化思路
性能问题不是凭感觉猜测的，这里有一个行业共识：在相同操作下，innerHTML的写入速度通常比createElement+appendChild方案慢，但在整体代码可读性和简便性上明显占优，具体差距和浏览器实现、DOM深度、节点数量都有关系。
哪些场景下性能差异明显
- 一次性渲染大量静态内容：比如首屏落地页的骨架结构,innerHTML的解析开销可以接受。
- 频繁小范围更新：比如用户输入触发局部刷新，建议避免使用innerHTML,改用textContent或直接操作目标节点。
- 表格或列表的批量重绘：如果每次请求回来都整体替换tbody的innerHTML,页面会明显卡顿。
性能优化实操步骤
- 先清空容器，再设置innerHTML,避免累积旧节点。
- 将拼接好的HTML字符串一次性赋值，不要分多次赋值，包含大量重复模板，优先考虑
DocumentFragment
createElement方案。 - 使用
requestAnimationFrame或宏任务调度,避免阻塞主线程。
业内专家指出，前端性能优化的核心不是选一个万能工具，而是根据操作频率和DOM规模,选择成本最低的方案。
innerHTML与XSS攻击的攻防细节
提到innerHTML，XSS是绕不开的话题，设置innerHTML时，字符串中的<script>标签不会执行，但事件属性比如onerror、onclick会触发,这是最容易踩的坑。
实际攻击场景示例
const username = '<img src=x onerror="alert(1)">';
document.getElementById('profile').innerHTML = username;
上面的代码在设置innerHTML之后，浏览器加载图片失败，触发onerror事件，弹窗就出现了，这在评论区、用户昵称展示等场景中是真实存在的风险。
防御方案对比
| 方案 | 原理 | 适用场景 |
|---|---|---|
| textContent | 不解析HTML，纯文本输出 | 所有用户输入内容 |
| 转义尖括号 | 将<替换为< |
需要保留部分HTML格式时 |
| DOMPurify等库 | 白名单过滤标签和属性 | 富文本编辑器场景 |
| 服务端校验 | 入库前过滤危险字符 | 数据源头控制 |
近几年，前端框架逐步普及，React的dangerouslySetInnerHTML、Vue的v-html本质都是innerHTML的封装，同样存在XSS风险。业务代码中，凡是涉及用户输入的内容输出，一律默认走textContent，除非你能明确确认内容经过严格过滤
。
innerHTML与textContent、insertAdjacentHTML的选型对比
很多开发者会问，innerHTML和textContent到底选哪个？这里给出一个判断标准：目标是纯文本就选textContent，目标是HTML结构才选innerHTML。
innerHTML和textContent区别
textContent只处理文本内容，不解析HTML标签，它不会触发图片加载、样式渲染或脚本事件，性能上比innerHTML更稳定，安全性也高得多，修改文本时，比如更新商品价格、用户昵称、消息内容,textContent是更合适的选择。
insertAdjacentHTML的补充定位
insertAdjacentHTML提供四个插入位置：beforebegin、afterbegin、beforeend、afterend，它和innerHTML的区别在于，不需要先获取容器再整体替换，可以在指定位置插入节点,同时避免影响已有子节点。
// 在列表末尾追加一项
const list = document.getElementById('list');
list.insertAdjacentHTML('beforeend', '<li>新项目</li>');
对比来看，insertAdjacentHTML更适合局部增量更新，innerHTML则适合整体替换，从性能角度，insertAdjacentHTML避免了序列化整个容器的开销,在列表追加场景下更高效。
innerHTML在真实业务场景中的最佳实践
上面讲了很多技术细节，接下来落到实际业务操作中，以常见的后台管理系统为例，表格数据刷新、弹窗内容填充、TAB切换这三个场景,对innerHTML的依赖程度各不相同。
表格数据刷新
表格每页显示20条数据，点击翻页时直接替换整个tbody的innerHTML，这种操作频率较低，数据量可控，性能影响可以忽略，但需要注意，如果表格行内包含事件绑定，替换后事件会丢失,需要使用事件委托或重新绑定。
填充
一般是固定的模板，配合模板字符串使用,可读性非常好：
const modal = document.getElementById('modal');
modal.innerHTML = `
<h3>${data.title}</h3>
<p>${data.content}</p>
<button class="btn-confirm">确认</button>
`;
这里要注意，data.title和data.content如果是服务端返回的，必须经过转义处理,否则等于把XSS漏洞直接暴露在线上。
动态渲染业务组件
现在很多项目使用Vue或React，但偶尔也会在原生场景下使用innerHTML，比如通过后端下发的JSON配置，动态渲染表单或图表，这种场景下，推荐使用html模板工具库或自定义渲染函数，而不是简单拼接字符串,否则代码维护成本会急剧上升。
innerHTML常见问题解答
innerHTML和textContent在性能上差距有多大？
没有绝对量化的差距，取决于内容规模和浏览器引擎，小规模文本更新，两者几乎无差别；大规模列表渲染，innerHTML的解析开销更明显，从安全性角度，textContent完全规避了XSS风险,所以纯文本场景优先选择textContent。
innerHTML读取的HTML字符串和原始源码一致吗？
不一致，浏览器会序列化当前DOM结构，补全缺失的标签、转换属性引号、统一标签大小写，比如原始源码中写<img src='a.jpg'>，读取innerHTML可能得到<img src="a.jpg">,所以不要依赖innerHTML做源码级别的字符串比较。
使用innerHTML时如何避免XSS攻击？
核心原则是：用户输入内容不直接进入innerHTML，如果必须使用，先对特殊字符进行转义，将&、<、>、、转换为HTML实体，富文本场景引入白名单过滤库，服务端配合做输入校验，前端再做输出转义,形成双层防护。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/557613.html
