节流函数的核心是控制高频任务执行节奏，确保单位时间内最多执行一次，通过时间戳或定时器机制实现首次立即执行或延后执行，并需支持leading/trailing选项及处理事件复用、passive和this绑定等陷阱。
节流函数在高频任务分发中，核心是控制执行节奏，保证单位时间内最多执行一次，而不是等事件停了再执行——它不追求“最终结果”，而追求“稳定响应”。
比如滚动监听、鼠标移动、窗口 resize 这类持续触发的事件，如果每次变动都调用重绘或计算逻辑，浏览器很快就会卡住。节流的作用，就是把密集的任务“匀速摊开”，让 JS 线程有喘息空间。
关键处理逻辑：时间窗口 + 执行时机锁定
节流不是简单地“每 delay 毫秒执行一次”，而是基于两个典型策略之一来决定是否放行： - **首次立即执行 + 固定间隔**（推荐）：第一次调用立刻运行，之后至少等待 delay 时间才允许下一次执行； - **首次延后执行**：第一次也得等满 delay 才执行，适合纯节奏型场景（如动画帧同步）。实现上常用两种底层机制：
- 时间戳判断：记录上一次执行的 timestamp，当前时间减去它，若超过 delay，就执行并更新时间戳；
- 定时器开关：用一个 flag 或 timer 标识“是否处于冷却期”，触发时若未冷却则直接返回，否则设定时器并在到期后执行并重置状态。
为什么不能用 setInterval 或 clearTimeout 重置？
- setInterval 不可控：它不管事件有没有新触发，只按固定节奏跑，容易错过关键触发点，也可能在无事件时空跑； - clearTimeout 重置是防抖逻辑：每次触发都清旧定时器、建新定时器，结果变成“只要不停触发，就永远不执行”——这违背节流“必须定期响应”的初衷。带选项的健壮实现要考虑什么？
实际项目中，节流函数常支持 `leading` 和 `trailing` 两个开关： - `leading: true`（默认）→ 首次触发立刻执行； - `trailing: true` → 在冷却期结束前最后一次触发，也会补执行一次（避免滚动到底部时漏掉“加载更多”）； - 两者都开，才能兼顾即时反馈与边界完整性，尤其在 scroll 场景中很关键。高频分发中的常见陷阱
- 事件对象复用：比如 `scroll` 事件对象是浏览器复用的，节流回调里直接用 `event` 可能拿到过期值，应提前解构或深拷贝必要字段； - 缺少 passive: true：监听 scroll/resize 时不加 `{ passive: true }`，浏览器会强制同步执行回调，节流再好也白搭——这是比节流更优先的性能开关； - this 和参数丢失：闭包中没正确绑定上下文或展开 arguments，会导致函数内部 `this` 指向错误或参数为空。不复杂但容易忽略。
立即学习“Java免费学习笔记（深入）”；
