必须用 input 事件，因其能捕获粘贴、拖入、输入法上屏、语音输入等 keyup 和 change 无法覆盖的全部输入行为；防抖需清除前序定时器并闭包保存 timer，延迟建议 300ms；中文输入法需配合 compositionstart/end 控制触发时机。
input 标签本身不防抖，防抖是 JavaScript 层的控制逻辑。直接监听 input 事件 + 手写或调用防抖函数，才是真实生效的方案；用 onkeyup 或 change 会漏掉粘贴、输入法上屏、语音输入等关键场景。
为什么必须用 input 事件而不是 keyup
用户行为远不止敲键盘：input 能捕获粘贴（Ctrl+V）、剪切、拖入文本、中文输入法上屏、语音转文字、长按选择替换——这些操作都不会触发 keyup。而 change 要等失焦，连续删改时 UI 响应明显滞后。实测中，input 是唯一覆盖全部输入路径的事件。
- 移动端软键盘收起瞬间也会触发一次
input，需在 handler 中判断event.target.value.trim() === ''后清空建议列表 - IE11 不支持
input？可 fallback 到propertychange，但仅当目标环境明确包含 IE11 时才加 - 别在
input回调里直接发请求或渲染 DOM，先过防抖层
debounce 函数怎么写才不出错
核心就两点：每次触发前清除上一个定时器；闭包保存 timer 变量。手写时最容易漏掉 clearTimeout，导致多个定时器并发执行，结果互相覆盖或重复请求。
- 延迟设
300ms 是经验值：短于200ms 用户感知不到“停顿”，长于500ms 明显卡顿 - 函数签名建议为
debounce(fn, delay = 300)，避免硬编码，方便不同搜索框复用 - 不要把
event对象直接传进setTimeout回调——它会被回收，应在闭包内取event.target.value - 示例最小可用结构：
function debounce(fn, delay = 300) {
let timer = null;
return function (e) {
clearTimeout(timer);
timer = setTimeout(() => fn(e.target.value), delay);
};
}
document.getElementById('search').addEventListener('input', debounce(doSearch, 300));
中文输入法（IME）期间要不要触发搜索
要等上屏完成再触发。否则用户打“张三”，过程中会先触发 “zhang”、“zhangs”、“zhangsa” 等无意义拼音串，既浪费请求又污染建议列表。
立即学习“前端免费学习笔记（深入）”；
- 监听
compositionstart标记进入输入法组合状态 - 监听
compositionend，在回调里手动调用一次防抖后的函数（传入e.target.value） - 在
input的防抖 handler 中加判断：if (isComposing) return;，避免组合过程中重复触发 - 注意：Safari 对
compositionend的触发时机略有差异，建议加setTimeout(..., 0)保底
防抖后怎么安全更新 datalist 或建议列表
datalist 是只读匹配源，不能实时高亮，但可以动态增删 option。问题在于：直接 innerHTML = '' 清空再插入，若用户快速切换焦点，可能造成 DOM 状态与输入值错位。
- 清空建议容器时，用
document.getElementById('suggestions').innerHTML = ''比循环removeChild更快更稳 - 每个
<option value="..."></option>的value必须是字符串，数字或对象要显式.toString() - 过滤时统一转小写：
item.name.toString().toLowerCase().includes(keyword.toLowerCase())，防止null或undefined崩溃 - 如果用自定义下拉列表（非
datalist），定位必须用getBoundingClientRect()动态计算，不能写死top: 100%
防抖不是加个 setTimeout 就完事——它和输入法状态、事件绑定方式、DOM 更新节奏强耦合。漏掉任意一环，都可能在 iOS 上键盘闪退、在 Chrome 里建议残留、或在用户连打时返回错误结果。
