input标签不支持节流，应使用防抖；节流会丢失中间输入状态，导致搜索建议、校验等出错；正确做法是监听input事件并用防抖，必要时支持immediate模式。
input 标签本身不支持节流，必须靠 JavaScript 手动实现；强行对 input 用节流，会丢失中间输入状态，造成体验断裂——这不是优化，是 bug。
为什么 input 不该用节流
节流本质是「固定时间间隔执行一次」，但用户在输入框里连续打字时，你漏掉中间几次 input 事件，就等于漏掉字符变化。比如用户输入 "hello"，节流每 300ms 执行一次，你可能只捕获到 "h"、"he"、"hello"，中间的 "hel"、"hell" 就丢了——搜索建议、表单校验、实时计数全会出错。
- 节流适用场景：滚动位置采样、鼠标移动坐标上报、resize 后重排版
- input 的正确模式是「防抖」：等用户停顿后再响应，不是「每隔一阵子响应一次」
- 若真要用节流（极少数情况，如纯 UI 反馈类轻量更新），必须搭配
input事件 +value快照，不能依赖事件触发频率
input 事件监听必须用 'input'，别用 'change' 或 'keyup'
change 只在失焦或回车时触发，完全无法支撑实时交互；keyup 漏掉粘贴、剪切、语音输入、拖拽文本等所有非键盘操作——这些在现代浏览器中占比越来越高。
- 正确绑定：
element.addEventListener('input', handler) - 移动端 iOS Safari 对
input事件有微小延迟，但仍是唯一可靠选择 - 如需兼容旧版 IE，可用
propertychange降级，但 IE 已无实际维护价值
防抖实现要透传 this 和 arguments，否则 this 指向丢失
直接写 setTimeout(fn, delay) 会导致 fn 内部的 this 指向 window（非严格模式）或 undefined（严格模式），同时参数也收不到。
立即学习“前端免费学习笔记（深入）”；
- 错误写法：
setTimeout(fn, delay)→this错乱，arguments丢弃 - 正确写法：
setTimeout(() => fn.apply(context, args), delay)，其中context = this，args = Array.from(arguments) - 更稳妥的现代写法：
setTimeout(fn.bind(context, ...args), delay)
function debounce(fn, delay) {
let timeout;
return function(...args) {
const context = this;
clearTimeout(timeout);
timeout = setTimeout(() => fn.apply(context, args), delay);
};
}
首次输入立即执行的 immediate 场景很常见，但别默认开启
搜索框“输入即提示”、表单“输错立刻标红”，都需要首次触发立刻执行，后续再防抖。但这个行为不是通用解法——它会让服务端多扛一轮请求，且和后续防抖逻辑耦合紧密。
- 启用条件：
debounce(handler, 400, true)，第三个参数为true表示 immediate - 注意副作用：如果 handler 里有异步请求，首次立即发 + 后续延迟发，可能造成竞态（比如后发的请求先返回）
- 更稳的做法：首次用微任务
Promise.resolve().then(() => handler())，避免与定时器冲突
真正难的不是写一个防抖函数，而是判断什么时候该防抖、什么时候该节流、什么时候两者都不该用——比如输入框里做拼音联想，就得用防抖；但同一页面里监听页面滚动加载更多，就必须切到节流；混用或硬套，反而把性能优化做成性能陷阱。
