防抖不直接优化重排，而是通过延迟执行减少重排次数；典型应用是窗口缩放时压缩密集resize触发为一次稳定后的布局切换，并配合class切换、读写分离和requestanimationframe进一步优化性能。
页面布局切换本身不直接用防抖优化重排，而是用防抖控制触发切换的时机，从而减少不必要的重排次数。
防抖不是用来“优化重排”，而是避免频繁触发重排
布局切换（比如根据屏幕宽度切换 grid / flex / block）通常通过修改 class 或 style 实现。每次修改都可能引发重排，但真正伤性能的是在短时间内反复执行——例如 resize 事件每秒触发几十次，若每次都调用 layoutSwitch()，就会连续触发多次重排。
防抖的作用是：把密集的 resize 触发“压缩”成一次稳定后的执行，确保只在用户停止调整窗口后才运行布局逻辑。
典型场景：窗口缩放时切换布局模式
错误写法（无防抖，极易卡顿）：
- 监听 resize，每次触发都读取 window.innerWidth、修改 container.className
- 浏览器可能一秒内重排 50+ 次，尤其在拖拽窗口边缘时
正确做法（加防抖）：
- 用 debounce 包裹布局切换函数，延迟 250ms 执行
- 只要用户还在拖动窗口，计时器就不断重置；松手后 250ms 才真正执行
- 这样就把 N 次潜在重排，压缩为最多 1 次
配合防抖的布局切换最佳实践
单纯防抖还不够，要和布局优化手段配合使用：
- 用 class 切换代替直接改 style：
el.classList.toggle('layout-grid')比el.style.display = 'grid'更轻量 - 读写分离：如果需要根据当前尺寸做判断，先一次性读完所有尺寸（如 innerWidth、offsetHeight），再统一写类名或样式
- 避免在防抖回调里读取 offsetTop/clientWidth 等强制重排属性；如必须读，缓存一次结果复用
- 复杂布局计算可进一步用 requestAnimationFrame 延迟到下一帧，让浏览器有机会合并渲染
一个可直接用的防抖布局切换示例
以下代码监听 resize，在停止调整 200ms 后更新布局，并避免同步读写冲突：
- 定义防抖函数：
const debouncedLayout = debounce(updateLayout, 200) -
updateLayout()内部先读取window.innerWidth，再批量应用 class - 绑定事件：
window.addEventListener('resize', debouncedLayout) - 注意：debounce 返回函数需保持引用，以便后续能正确移除监听器
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
