节流的核心目标是确保函数在指定时间间隔内最多执行一次；其前导型立即执行、后置型延迟至周期末执行、双触发型兼顾首尾，时间戳+状态机实现更精准，避免定时器堆积或漏判临界触发。
节流（throttle）的核心目标是控制函数执行频率，确保在指定时间间隔内最多只执行一次。但当事件在节流周期即将结束的瞬间再次触发（比如在剩余 5ms 时又来一次），就可能打破“每 N ms 最多一次”的预期——这时不是要不要执行的问题，而是“该不该立刻执行、还是等下一个周期、还是插队执行”，这本质上是优先级调度问题。
明确节流策略类型：前导/后置/双触发
边界行为差异源于节流实现逻辑本身：
- 前导型（leading）：周期开始时立即执行一次，之后拒绝直到周期重置。此时“周期末尾触发”会被直接丢弃，无边界争议。
- 后置型（trailing）：周期结束时才执行最后一次回调。若新事件发生在倒计时最后时刻（如还剩 1ms），它会刷新定时器，把执行推迟到下个周期末尾——看似延迟了，实则保证了“至少间隔 N ms”。
- 双触发型（leading + trailing）：首次触发立即执行，后续触发若落在周期中则被忽略，但周期末尾若有挂起调用，则补执行一次。此时“末尾触发”可能触发 trailing 执行，需注意是否与 leading 冲突。
用时间戳+状态机替代定时器硬等待
单纯依赖 setTimeout 容易在高频触发下堆积或漏判边界。更精准的做法是记录上次执行时间，每次触发时动态计算：
FastAPI Flask Proxy
下载
FastAPI + Flask 混合部署最佳实践，解决路由定义、API 代理等常见问题，适用于同时运行 FastAPI API 与 Flask 前端的场景。
- 若当前时间 − 上次执行时间 ≥ 间隔阈值 → 立即执行并更新时间戳；
- 否则，检查是否已安排 trailing 执行：没安排就设定时器，已安排则跳过（避免重复设）；
- 关键细节：定时器回调里要重新校验“当前时间 − 上次执行时间 ≥ 阈值”，防止因延迟导致误执行。
对“临界触发”做显式标记与合并
当检测到两次触发间隔极短（如
- 将本次调用参数与上一次缓存合并（如鼠标位置取最新值、输入内容取最新字符串）；
- 仅刷新 trailing 定时器，不触发 leading；
- 避免因微小抖动反复重置节流窗口，造成视觉或逻辑不连贯。
优先级不是靠抢，而是靠约定
所谓“精准排列优先级”，实际是定义清楚三件事：
- 用户意图优先级：例如 resize 事件中，最终尺寸比中间过程更重要 → 选 trailing；
- 响应及时性优先级：如拖拽跟随，首帧必须跟上 → 必须启用 leading；
- 系统资源优先级：高频输入（如键盘连按）应抑制 trailing，防卡顿 → 可配置为 leading-only。
没有通用最优解，只有场景适配。真正需要“精准”的地方，是把策略选择显式暴露为配置项，而非在运行时动态竞争。
