节流函数中timestamp方案首次立即执行、不保证末次执行，适合首屏即时反馈；timer方案首次不执行、保证末次执行，适合需兜底操作的场景。
节流函数中，timestamp 方案和timer 方案本质都是控制函数执行频率，但触发时机、响应及时性、代码逻辑和边界行为有明显差异。选哪种不取决于“谁更高级”，而要看你更在意“首次是否立即执行”还是“最后一次是否必须执行”。
timestamp 方案：基于时间戳的被动拦截
核心思路是记录上一次执行的时间，每次调用时对比当前时间与上次执行时间的差值，大于等待间隔才执行并更新时间戳。
- 首次调用默认立即执行（可配置）
- 后续调用仅在间隔达标时才执行，不设定时器，无异步延迟
- 不保证最后一次触发被响应——如果用户停止触发，尾部的调用直接被丢弃
- 适合对“响应连续性”要求不高、但对“首屏即时反馈”敏感的场景，比如滚动监听计算位置、鼠标移动获取坐标
timer 方案：基于定时器的主动调度
核心思路是用 setTimeout 延迟执行，每次触发时清除旧定时器、设置新定时器；只有定时器到期时才真正执行函数。
- 首次调用不会立即执行（除非手动加前导执行逻辑）
- 只要在 wait 时间内持续触发，就会不断重置定时器，最终只执行最后一次（或倒数第一次）
- 能保证“最后一次有效触发后 wait 毫秒内必定执行一次”，适合需要兜底操作的场景
- 常见于搜索框输入后发请求、窗口 resize 后重新布局等需要收尾动作的场合
关键差异直观点对比
执行时机：timestamp 是“满足条件就干”，timer 是“等到最后一刻再干”。
内存开销：timestamp 无定时器，无 clearTimeout 开销；timer 需频繁创建/清除定时器。
可预测性：timestamp 执行时间点分散（每次达标即执行），timer 执行时间点集中在最后一次触发之后 wait 毫秒处。
实现复杂度：timestamp 更简洁；timer 若要支持 leading（首次立即执行）+ trailing（末次也执行），需额外状态管理，容易出错。
一个实际选择建议
如果你希望用户一滚动就立刻看到效果（比如吸顶导航变化），用 timestamp + leading。
如果你希望等用户彻底停手后再统一处理（比如调整图表尺寸、提交表单防抖+节流混合逻辑），用 timer + trailing。
不需要两者都上——多数业务场景只需一种语义清晰的节流行为，混用反而增加理解和维护成本。
