节流函数必须用闭包，因为需在多次调用间私有持久地共享lastTime或timer状态；不用闭包则依赖全局变量，导致污染、竞态及多实例冲突。
节流函数为什么必须用闭包
因为节流需要在多次调用间共享一个状态（比如上一次执行的时间戳或定时器 ID），而这个状态不能暴露给外部，也不能每次调用都重置。只有闭包能自然地把 lastTime 或 timer 封装在函数作用域内，既私有又持久。
不用闭包的话，你只能靠全局变量或外部对象存状态——这会污染作用域、引发竞态，还无法支持多个节流实例独立运行（比如按钮 A 和按钮 B 各自节流）。
-
lastTime记录上一次真正执行回调的时间，用于判断是否过了间隔期 -
timer存 setTimeout 的返回值，用于在未到时间时清除待执行的延迟任务 - 闭包让每个
throttle(fn, delay)调用都拥有自己的一套状态，互不干扰
基础节流实现：时间戳版 vs 定时器版
两种主流写法，行为不同，选错会导致逻辑偏差：
-
时间戳版：首次触发立即执行，后续在
delay内的调用全部忽略，直到超过间隔才再次执行。适合“确保至少每 X 毫秒执行一次”的场景（如 resize 监听） -
定时器版：首次触发启动定时器，
delay后执行；期间重复触发会不断清除重设定时器，最终只执行最后一次。适合“保证最后一次操作后 X 毫秒再响应”的场景（如搜索框输入后发请求）
常见错误是混用两者逻辑，比如在时间戳版里又加 clearTimeout，结果状态混乱、漏执行。
示例（时间戳版）：
function throttle(func, delay) {
let lastTime = 0;
return function(...args) {
const now = Date.now();
if (now - lastTime >= delay) {
func.apply(this, args);
lastTime = now;
}
};
}
带 leading/trailing 控制的节流怎么写
原生节流没提供“首次立即执行”或“结束时补一次”的开关，但实际业务常需要。比如鼠标拖拽要立刻响应（leading），而滚动到底部加载更多又希望松手后补一次（trailing）。
关键点在于：trailing 必须配合定时器，且不能和 leading 冲突。一旦开了 trailing，就不能只靠时间戳判断——得用 timer 来兜底最后一次调用。
- 开
leading: true→ 首次调用直接执行，更新lastTime - 开
trailing: true→ 每次调用都尝试设定时器；若timer已存在则先清除，再设新的，确保只留最后一个 - trailing 的回调里要重新检查：如果距上次执行已超
delay，就跳过（避免和 leading 重复）
漏掉 clearTimeout 或误判 lastTime 更新时机，会导致 trailing 多执行或不执行。
节流函数里 this 和参数怎么正确传递
直接写 func(args) 会丢失原始调用上下文（this 变成 undefined 或 window），尤其在事件监听中很致命。
- 必须用
func.apply(this, args)或func.call(this, ...args)保留this - 箭头函数不能用作节流返回函数，因为它不绑定自己的
this，会继承外层，通常不是你想要的 - 参数展开要用
...args，别写死func(arg1, arg2)，否则不支持任意参数个数
另一个坑：如果原函数是 class 成员方法且被直接传入（如 throttle(this.handleClick, 300)），需确保 this.handleClick 没被提前绑定过，否则 apply 无效——这种情况下应在 class 构造函数里用 this.handleClick = this.handleClick.bind(this) 或改用箭头属性。
节流真正的复杂点不在闭包本身，而在「何时该执行」的判定逻辑与「执行上下文」的精确还原。多数线上 bug 都出在 trailing 行为和 this 绑定同时出问题，调试时容易只盯时间逻辑，忽略调用链上的 this 丢失。
