触发回流的操作包括：读取offsetTop等布局属性、增删可见DOM节点、修改影响盒模型的CSS属性、className或style变更；避免多次回流需批量操作，如用className切换、先读后写、documentFragment缓存、优先使用transform/opacity。
哪些 DOM 操作会触发回流（reflow）？
回流是浏览器重新计算元素几何属性（位置、尺寸）并重建渲染树的过程，开销远大于重绘。只要涉及布局信息的读取或修改，就可能触发回流。
常见触发场景包括：
- 访问
offsetTop、offsetLeft、clientWidth、getComputedStyle()等返回布局信息的属性 - 添加/删除可见 DOM 节点
- 改变元素尺寸、位置、字体大小、边框等影响盒模型的 CSS 属性
- 调整
className或直接操作style导致样式变更影响布局
注意：getComputedStyle() 和 offsetHeight 这类“读取”操作本身不触发回流，但若其前有未提交的样式修改（如刚改了 div.style.width），浏览器会**强制同步回流**来返回准确值——这是最容易被忽略的隐式性能陷阱。
如何批量修改样式避免多次回流？
核心原则：把多次样式变更合并为一次生效，让浏览器只做一次布局计算。
立即学习“Java免费学习笔记（深入）”；
Miller CSV TSV JSON 数据处理器
下载
Miller (mlr) 是一个命令行工具，用于查询、整形和重新格式化名称索引数据，如 CSV、TSV、JSON 和 JSON Lines。它将 awk、sed、cut、join 和 sort 的功能整合到一个专为结构化数据处理而构建的单一工具中。
推荐做法：
- 用
className切换预定义 CSS 类，而非逐条设置style.xxx - 需要动态计算样式时，先读完所有所需布局信息（如
el.offsetWidth），再统一写入样式，避免“读-写-读-写”交替 - 对大量节点操作，用
documentFragment缓存 DOM 变更，最后一次性appendChild - 使用
transform和opacity替代top/left/width/height—— 它们走合成层（compositor），不触发回流
const fragment = document.createDocumentFragment();
for (let i = 0; i < 100; i++) {
const el = document.createElement('div');
el.className = 'item animated';
fragment.appendChild(el);
}
container.appendChild(fragment); // 仅触发一次回流requestAnimationFrame 适合什么场景？
它不是万能优化开关，而是用来对齐浏览器刷新节奏的工具。适用于需要与屏幕刷新率同步的连续视觉更新，比如动画、滚动响应、拖拽反馈。
关键点：
- 在
requestAnimationFrame回调中读取布局（如scrollTop）+ 修改样式，可避免强制同步回流 - 不要在其中执行耗时 JS（如遍历大数组、深克隆对象），否则会阻塞渲染帧
- 连续动画中，若每次回调都调用
getBoundingClientRect()，仍会触发回流——应缓存结果或改用transform驱动
function updatePosition() {
const pos = element.getBoundingClientRect(); // 读取
element.style.transform = `translateY(${pos.top}px)`; // 写入，不触发回流
}
requestAnimationFrame(updatePosition);Chrome DevTools 怎么定位回流热点？
别靠猜。打开 Chrome DevTools → **Rendering** 面板 → 勾选 Paint flashing 和 Layout Shift Regions，再操作页面，闪烁区域即重绘/布局变化区；但更关键的是看 **Performance** 面板录制后的火焰图：
- 查找高亮的
Layout事件（橙色块），点开看具体调用栈 - 重点关注
Recalculate Style后紧跟Layout的组合，说明 JS 主动读写了布局属性 - 若发现
Update Layer Tree频繁出现，可能是transform: translateZ(0)之类强制提升图层滥用所致
真实瓶颈往往藏在看似无害的一行 el.offsetHeight 后面——尤其当它在循环里或事件回调中反复出现时。
