防抖函数不直接避免重绘，而是通过延迟执行减少重绘次数；它仅在用户操作停止后触发一次dom更新，从而将多次重排重绘压缩为一次。
防抖函数本身不直接避免重绘，它通过控制函数执行时机，间接减少触发重绘的次数。真正导致重绘的是你在 resize、scroll 或 input 回调里做的 DOM 操作或样式变更（比如改宽高、显示隐藏元素、调用 chart.resize()）。防抖的作用是：让这些操作只在用户“停手”后执行一次，而不是在拖拽窗口或滚动过程中反复执行。
关键点在于：防抖不是渲染优化手段，而是事件调度策略。它的价值体现在“削峰填谷”——把几十次无意义的中间状态，压缩成一次最终状态的响应。
防抖如何切断重绘链路
- 浏览器在调整窗口时每秒可能触发 30~60 次
resize事件 - 如果每次都在回调中调用
element.style.width = '100%'或chart.resize()，就会连续触发重排（reflow）→ 重绘（repaint）→ 合成（composite） - 防抖后，只有最后一次尺寸稳定后的回调被执行，中间所有变化被忽略，重绘自然只发生一次
实际配置防抖的要点
- 使用合理延迟：一般 100~250ms 足够覆盖人眼感知的“停止”间隙，太短起不到过滤作用，太长会让响应显得迟钝
- 确保防抖包裹的是真正引发重绘的操作：比如
updateLayout()、renderChart()、recalculateGrid()，而不是仅做日志打印或状态赋值 - 不要对防抖函数重复绑定：同一个事件监听器多次添加防抖包装，会导致 timer 变量隔离，清不掉旧定时器
推荐写法（兼顾可读与健壮）
const handleResize = debounce(() => {
// ✅ 这里放真正会操作 DOM 或触发渲染的逻辑
chart?.resize();
updateSidebarWidth();
recalculateResponsiveColumns();
}, 160);
window.addEventListener('resize', handleResize);
-
debounce函数内部必须用clearTimeout清除前序定时器，否则多个setTimeout并行，仍会漏执行或错执行 - 如果使用 Lodash，建议加
leading: false, trailing: true（默认即如此），确保只在结束时响应
容易被忽略的配套动作
- 避免在防抖回调里读取频繁变动的 DOM 属性（如
offsetHeight），这类读取会强制同步触发重排 - 把样式变更批量处理：比如用
classList.toggle()替代逐个设style.xxx，或用requestAnimationFrame对齐渲染帧 - 对图表、Canvas 等重绘大户，resize 后优先调用其原生
.resize()方法（如 ECharts 的chart.resize()），比手动重绘更高效
本质上，防抖只是“节流重绘请求”的第一道闸门。它有效，但必须配合合理的 DOM 操作方式，才能真正减轻浏览器压力。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
