防抖按钮必须显式设置 type="button"，避免默认 submit 行为干扰；debounce 函数需复用实例而非每次新建；延迟值推荐 300–500ms，配合 disabled 或 loading 视觉反馈确保用户体验。
防抖点击的按钮必须用 type="button"
直接写 <button>点我</button> 是危险的——在表单里它默认是 type="submit"，点一下可能意外触发表单提交，打断防抖逻辑。哪怕没表单，也建议显式声明 type="button"，避免浏览器默认行为干扰。
常见错误现象：防抖函数明明写了，但点击后页面刷新或跳转；或者防抖生效了，但控制台报错 Uncaught TypeError: Cannot read property 'preventDefault' of undefined（因为误把 click 事件绑定在 submit 行为上，又试图调 e.preventDefault()）。
- 正确写法：
<button type="button" id="search-btn">搜索</button> - 如果按钮在
<form></form>内，不加type="button"就算加了防抖也没用——提交动作早于防抖延迟执行 - 不要用
<input type="button">做防抖按钮，它不支持子元素（比如图标），语义和可维护性不如<button></button>
debounce() 函数不能每次点击都新建实例
防抖的核心是共享一个定时器引用，靠闭包维持状态。如果每次绑定事件都调用一次 debounce(clickHandler, 300)，每个调用都会生成独立的 timer 变量，旧定时器无法被清除，防抖就失效了。
典型错误写法：btn.addEventListener('click', debounce(handleSearch, 300)) —— 这里 debounce() 立即执行，返回的是一个新函数，但每次绑定都重新执行一遍，timer 不共享。
立即学习“前端免费学习笔记（深入）”；
- 正确做法：先创建防抖函数实例，再绑定：
const debouncedClick = debounce(handleSearch, 300); btn.addEventListener('click', debouncedClick); - 或者用箭头函数包裹但确保不重复定义：
btn.addEventListener('click', () => debouncedClick())（不推荐，绕远） - 注意：如果按钮会动态增删（如列表中多个按钮），每个按钮应有独立的防抖实例，不能共用同一个
debouncedClick
防抖延迟值不是越小越好，500ms 是多数场景安全起点
设成 100ms 看似响应快，但用户双击、误触、触屏手指悬停都容易被过滤掉；设成 1000ms 又会让操作明显“卡顿”。实际中，300–500ms 是平衡点击意图识别与响应及时性的常见区间。
性能影响很直接：延迟值越大，用户感知到的“等待”越明显；延迟越小，越容易漏判真实点击意图，反而导致重复触发（比如用户快速连点两下，200ms 防抖可能只过滤掉中间一次，仍执行两次）。
- 搜索框类操作可用
300ms：用户输入后稍作停顿再请求，体验顺滑 - 提交/购买类按钮建议
500ms：给用户留出“确认是否真要点”的余量，降低误操作率 - 移动端需额外 +100ms：触摸响应比鼠标慢，且手指面积大，连点更常见
防抖按钮要配合视觉反馈，否则用户会反复点击
防抖让点击不立刻响应，但 DOM 没任何变化时，用户不知道“系统收到了”，本能就会再点——这直接破坏防抖效果。必须提供即时视觉反馈，比如按钮置灰、加 loading 动画、文字变“提交中…”。
常见错误：只做防抖，不改按钮状态。用户点完无反应，3 秒后才弹 toast，期间已点了 5 次，防抖只拦住 4 次，第 5 次仍发请求。
- 最简方案：
btn.disabled = true+ 样式opacity: 0.6，成功后再恢复 - 更友好方案：用
data-loading属性控制 CSS 动画，避免禁用导致键盘焦点丢失 - 注意：禁用按钮后，
click事件仍会触发（只是不执行默认行为），所以防抖逻辑必须在disabled判断之后，或干脆在防抖函数开头加if (btn.disabled) return
clearTimeout 和 setTimeout，而是把「用户意图」和「系统响应节奏」对齐——延迟值、视觉反馈、DOM 状态三者必须同步，缺一不可。 
