直接 innerHTML += 会触发多次重排，因每次执行都需读取、拼接、解析、重建、重算布局；应改用 documentFragment 批量插入或 className 切换等优化手段。
为什么直接 innerHTML += 会触发多次重排
每次执行 innerHTML +=，浏览器都得先读取当前内容、拼接新字符串、再解析 HTML、重建子树、重新计算布局——整个流程走完一次就是一次强制重排+重绘。尤其在循环中反复调用，等于把 N 次重排摊开执行，性能雪崩。
常见错误现象：for 循环里对同一个元素反复写 innerHTML +=，页面明显卡顿，Performance 面板看到大量 Layout（Layout / Reflow）事件。
- 本质是“读-改-写”三步被拆开执行，且每次“读”都会强制 flush 队列（因为要拿到最新 DOM 状态）
- 哪怕只是追加纯文本，只要涉及
innerHTML赋值，就会触发 HTML 解析流程，无法绕过 Layout - 服务端返回的 HTML 片段若含
<script></script>或内联样式，还可能触发额外解析和执行开销
用 documentFragment 批量插入节点更可控
当你需要动态添加多个同级节点（比如列表项、卡片块），documentFragment 是比拼字符串更语义清晰、更易维护的选择，且只触发一次重排。
使用场景：从数组生成 <li> 列表、渲染搜索建议下拉、批量更新表格行。
立即学习“前端免费学习笔记（深入）”；
- 创建
document.createDocumentFragment()，所有新节点先 append 到它里面 - 最后一次性
parent.appendChild(fragment)，浏览器只做一次 Layout 计算 - 相比字符串拼接，它天然规避 XSS 风险（节点由
document.createElement创建，非 HTML 字符串注入） - 注意：fragment 本身不挂载到 DOM，所以不能用
querySelector查找它内部节点，得先 append 后再查
修改 className 比逐个设 style 属性更轻量
直接操作 element.style.xxx = yyy 每设一个属性就可能触发一次重排（尤其当该属性影响几何信息时），而切换 className 是原子操作，样式变更由 CSS 引擎统一处理。
典型误用：el.style.width = '200px'; el.style.marginLeft = '10px'; el.style.backgroundColor = '#fff'; —— 前两个会重排，最后一个只重绘，但三次独立赋值让浏览器无法合并优化。
- 把所有视觉变更归到一个 class 里，例如
.card-expanded { width: 200px; margin-left: 10px; background: #fff; } - 用
el.classList.toggle('card-expanded')替代手动设 style，既简洁又避免 layout thrashing - 如果必须动态计算样式（如根据屏幕宽度设 margin），优先用
style.cssText = '...'一次性写入，而非分多行赋值
读写分离：避免 getBoundingClientRect() 后紧跟 DOM 修改
任何读取几何信息的操作（offsetWidth、getBoundingClientRect()、getComputedStyle()）都会强制浏览器同步刷新渲染队列——也就是“冲掉”之前所有待批处理的修改，立刻执行重排，再返回数值。紧接着再改 DOM，又开启新一轮队列。
容易踩的坑：在动画循环或滚动监听里，一边读位置一边改样式，导致每帧都强制重排。
- 把所有读操作集中到函数开头，缓存结果（如
const rect = el.getBoundingClientRect(); const top = rect.top;） - 所有写操作集中到函数末尾，确保浏览器能批量处理
- 实在需要边读边写，用
requestAnimationFrame分两帧：第一帧读，第二帧写 - 注意：
clientWidth和scrollWidth这类属性也属于“强制同步读”，同样触发 flush
真正难的是判断哪些操作在你当前上下文里构成“隐式重排”——比如你以为只是改个颜色，结果父容器用了 flex-wrap: wrap，子元素宽度微变就导致整行重排。这种耦合性没法靠单一技巧解决，只能靠 Performance 面板实测 + 对布局上下文的持续敏感。
