只监听input事件会误判拼音输入法的中间状态，因compositionstart/end标志输入法组合模式，需用isComposing标志位协同过滤，防抖应包裹业务逻辑而非仅input监听，且须处理移动端滞后、表单提交兜底及动态节点重绑定。
直接监听 input 事件无法区分拼音输入法的中间状态和最终上屏内容，必须配合 compositionstart 和 compositionend 事件做状态过滤，否则会把 “sh”“shang”“shanghai” 当成有效输入反复触发逻辑。
为什么只绑 input 事件会误判拼音过程
中文输入法下，用户敲 “bei jing”，浏览器会在每次拼音变化时都触发 input 事件，但此时 input.value 是 “bei” 或 “beij”，不是 “北京”。这些中间值既不能用于搜索，也不该触发校验或请求——它们只是输入法的临时缓冲，不是用户真实意图。
-
compositionstart触发时，input.value通常还是旧值，但标志着输入法进入组合模式 -
compositionend触发时，input.value才真正更新为上屏后的汉字（如 “北京”），且该事件总在最后一次input之后发生 - Safari 对
event.target.isComposing支持不完整，不能依赖它替代标志位
compositionstart/compositionend 必须和 input 协同使用
只监听 compositionend 不够：它不覆盖粘贴、删除、英文直输等场景；只监听 input 又太多余。正确做法是用标志位桥接两者。
- 声明一个闭包变量
let isComposing = false，不要挂全局或组件this上 - 在
compositionstart回调里设isComposing = true - 在
compositionend回调里设isComposing = false，并立即调用业务函数（比如doSearch(input.value)） - 在
input回调里加守卫：if (!isComposing) { doSearch(input.value) } - 别在
compositionstart里清防抖定时器——用户可能中途切走，再回来继续输，清了就丢操作
防抖 + 中文过滤的组合写法容易漏掉关键点
单纯给 input 加防抖（比如 300ms 延迟）仍会把拼音串发出去；单纯等 compositionend 又会丢失英文、粘贴等非组合输入。二者必须嵌套。
立即学习“前端免费学习笔记（深入）”；
- 防抖函数应包裹实际业务逻辑，而不是只包
input监听器 -
compositionend触发后，要手动调用一次防抖后的函数，传入当前input.value - 移动端需注意：iOS Safari 的
input.value在compositionend后可能滞后一帧，稳妥做法是用setTimeout(() => { /* 再读一次 */ }, 0)微任务延迟取值 - 提交表单前务必兜底检查：
if (input.isComposing || isComposing) { e.preventDefault(); setTimeout(() => form.submit(), 0); }
最常被忽略的是初始化同步和动态节点绑定——新插入的 input 要重新监听这三类事件；已有默认值的输入框，得手动触发一次 input 事件或补校验，否则初始状态永远不进逻辑。这些细节不处理，上线后第一周就会收到用户反馈“搜不到”“点提交没反应”。
