防抖看“停没停”，节流看“到没到”：防抖在最后一次触发后延迟执行，适合最终状态场景；节流按固定间隔执行，适合持续反馈场景；防重复提交应选节流或开关控制而非防抖。
防抖和节流的本质区别在于“执行时机的判定逻辑不同”：防抖看的是“停没停”，节流看的是“到没到”。不是执行次数多或少的问题，而是触发与执行之间的时间关系设计不同。
防抖：等你彻底停下才响应
每次触发都重置倒计时，只有最后一次触发之后，安静等待指定时间，函数才真正执行。中间所有操作都被忽略。
- 适合场景：用户输入搜索、表单实时校验、窗口 resize 后重新布局
- 关键特征：高频输入 → 最终只执行一次，且是最后一次输入后的结果
- 注意点：若用户一直不停（比如长按键盘），函数就永远不会执行
节流：不管你怎么动，我按自己的节奏来
无论事件触发多密集，函数只在固定时间间隔内最多执行一次。它不等你停，而是主动“掐点”执行。
jm-jsjkxyjs02-zlm-405
下载
使用约定式提交（Conventional Commits）生成标准化的 Git 提交信息。适用于以下场景： (1) 暂存更改时需要提交信息； (2) 审查 diff 时希望获得结构化摘要； (3) 编写 PR 描述或变更日志（changelog）条目； (4) 用户明确要求“为本次更改编写提交信息”。 该功能会分析已暂存/未暂存的 diff，并生成按类型（type）划分范围的提交信息。
- 适合场景：滚动加载、鼠标拖拽、Canvas 动画、按钮防连点（需配合立即执行）
- 关键特征：持续触发 → 周期性执行，比如每 200ms 最多调用一次
- 注意点：有两种常见实现——时间戳版（首次立即执行）、定时器版（首次可能延迟）
怎么选？看业务对“响应及时性”和“结果准确性”的侧重
问自己两个问题：
- 这个操作是否需要反映“最终状态”？→ 选防抖（如搜索关键词，要的是用户停手后的完整词）
- 这个操作是否需要“持续反馈”或“不能漏掉关键帧”？→ 选节流（如滚动监听位置，要保证每段滚动都有响应）
一个容易踩的坑
别把“防重复提交”默认当成防抖。如果按钮点击后希望立刻禁用、立刻发请求，那其实是节流（带立即执行）或更简单的开关控制；而防抖的“等停再执行”反而会导致点击无响应。
