强制同步布局（FSL）由读写交替触发，非DOM操作本身问题；offset/client/scroll类属性、getBoundingClientRect()及需布局的getComputedStyle()字段会强制flush layout，应先批量写再批量读，并可借助requestAnimationFrame对齐渲染时机。
强制同步布局（FSL）不是 DOM 操作本身的问题，而是读写顺序不当触发的性能陷阱。它发生在 JavaScript 修改样式或结构后，又立刻读取 offset、client、scroll 或 getBoundingClientRect 等依赖布局的属性，迫使浏览器中断脚本、立即计算 layout，造成卡顿和掉帧。
哪些读操作会触发强制同步布局
只要当前样式未刷新（比如刚执行完 style 修改），以下任一读取都会强制 flush style + layout：
- offset 类：offsetTop、offsetLeft、offsetWidth、offsetHeight
- client 类：clientTop、clientLeft、clientWidth、clientHeight
- scroll 类：scrollTop、scrollLeft、scrollWidth、scrollHeight
- getComputedStyle() 中任何需布局计算的字段（如 width、height、left、transform）
- getBoundingClientRect() —— 最典型的高危调用
而 className、textContent、dataset、style.color 这类纯写或不依赖 layout 的读取，完全安全。
核心原则：先批量写，再批量读
关键不是“分离”动作，而是避免「写 → 读 → 写 → 读」的交替模式。浏览器能高效批量处理样式变更，但一次读取就会清空 layout 缓存，让后续所有写也陷入同步路径。
- ❌ 错误示例（循环中混用）：
for (let i = 0; i el.style.left = `${i * 10}px`;
console.log(el.offsetHeight); // 每次都强制回流
} - ✅ 正确做法（两阶段）：
// 所有写操作集中完成
items.forEach((item, i) => {
el.style.left = `${i * 10}px`;
});
// 所有读操作统一进行（且只读一次，缓存复用）
const height = el.offsetHeight;
const rect = el.getBoundingClientRect();
进阶技巧：对齐渲染时机
即使做了读写分离，如果“读”发生在浏览器尚未完成 layout 的阶段，仍可能触发 FSL。更稳妥的方式是借助 requestAnimationFrame：
- 在 RAF 回调中读取，确保它运行在浏览器 layout 阶段之后、绘制之前
- 注意：RAF 并不自动保证 layout 已完成——若此前有未 flush 的样式变更（如刚设了 style），仍会触发 FSL
- 可组合使用：先批量写 → requestAnimationFrame → 在回调中批量读
辅助手段：DocumentFragment 和 CSS 批量控制
虽然不直接解决 FSL，但能减少 layout 触发频次，间接降低风险：
- 用 DocumentFragment 批量插入节点，把多次 appendChild 合并为一次重排
- 优先用 class 切换代替内联 style 修改，配合 CSS 变量或 transition 控制动画
- 避免在 scroll 或 resize 事件中频繁读写布局属性；必要时加节流，并将读写严格分阶段
