节流函数通过限制执行频率并使其对齐屏幕刷新节奏（如每16ms一次），确保更新逻辑在帧边界运行，避免主线程过载、强制同步布局及重排，但不能替代硬件加速或减轻重操作。
节流函数本身不直接更新 UI，但它决定“什么时候让更新逻辑跑”，从而深刻影响渲染是否卡顿、是否掉帧、是否响应滞后。
把高频操作对齐到屏幕刷新节奏
浏览器默认以约 60Hz（每 16.7ms 一帧）刷新画面。如果滚动、拖拽或参数调节每毫秒都触发一次 DOM 更新或 Canvas 绘制，主线程瞬间过载。节流通过限制函数执行频率，确保更新逻辑只在合适的时间点运行——比如每 16ms 最多执行一次，正好匹配一帧周期。
关键不是“少执行”，而是“在帧边界上执行”。用 requestAnimationFrame 实现的节流，天然与渲染管线同步，后台标签页还会自动暂停，避免无谓消耗。
避免强制同步布局（Layout Thrashing）
很多卡顿不是因为“执行太多”，而是因为“执行时机太差”。例如在 scroll 回调里反复读取 offsetHeight 或 getBoundingClientRect()，会强制浏览器立刻重排，打断当前帧。
立即学习“Java免费学习笔记（深入）”；
节流配合合理分工能切断这个链条：
- 滚动监听回调只做两件事：缓存当前 scrollTop、标记“需要更新”
- 真实计算和 DOM 操作全部移入 requestAnimationFrame 回调中
- 确保 layout 读取和样式写入不在同一帧内交替发生
为硬件加速铺路，而非替代它
节流解决的是“JS 执行太密”，但 UI 卡顿还常来自“绘制太重”。即使节流到位，若每次更新都写 element.style.top = y + 'px'，仍会持续触发重排。
真正流畅的组合是：
- 用 transform: translateY() 替代 top/left/margin-top
- 给动画元素加 will-change: transform（仅必要时）
- 滚动监听必须带 { passive: true }，否则浏览器强制同步阻塞
节流不能掩盖重操作，只能暴露它
一个常见误区是以为加了节流就万事大吉。其实节流只是“节流”，不是“减负”。以下操作即使被节流包裹，依然会拖垮帧率：
- 每帧遍历上千个 DOM 节点做 visibility 判断
- 在 RAF 中实时解码大图或渲染全量长列表
- 频繁读写非合成属性（如 width、height、color）
这些必须剥离：用虚拟滚动替代全量渲染，用 Web Worker 处理复杂计算，用 Image.decode() 配合懒加载控制图片资源节奏。
