H5 搜索框里拼音还在候选框挑字，联想请求就先跑了，这算输入法太快还是代码没分阶段？

先说结论：H5 搜索框里拼音还在候选框挑字，联想请求就先跑，多数不是 input 事件本身坏了，而是把组合期的值变化当成了最终输入。2026 年交付里更稳的顺序是：先判断组合期，再决定触发点，最后收口去抖和请求取消。这样做后，一次词组输入的联想请求通常落在常见区间 1～2 次，选字时结果区也不容易跳动。它适合输入过程中就会发请求、写存储或改状态的场景；只在点击提交时读一次值的表单，不必为此增加复杂度。

这类问题的麻烦不在能不能跑，而在上线后接口调用量随拼音长度上涨，结果区频繁刷新还会让用户选字时误点，实时校验也可能在没选完字时就先报错。它属于前端交互开发里典型的常识缺口：代码看着没错，事件阶段用错了。

为什么拼音没选完，请求就先跑出去

浏览器把输入拆成组合期和提交期。主流输入法在组合期每敲一个字母都会让输入框的值变化，并派发一次 input。前端如果只监听 input 就直接发请求，等于把每一次候选调整都当成了最终结果。

• 事件语义不同：input 表示值变了，不等于用户选完字了，keyup 同理。
• 平台差异：桌面 Chrome/Edge 与多数安卓输入法的 isComposing 比较可靠，部分 iOS 版本或第三方输入法存在时序偏差。
• keydown 兜不住：组合期 keydown 常为 229 或未定义，用它判断输入内容并不可靠。
• 常见误区：用值长度变化推断输完了，遇到删除、粘贴、联想词替换就会误判。

移动端软键盘的联想、纠错、整词替换会让值在一次组合里变动多次，纯靠时间去抖很难区分停顿等候选和真的输完了，所以判断依据要落在组合事件上，而不是时间上。

交付现场经验：有次搜索框改造周期只给了两天，接口限流阈值也不宽。我们先把组合期判断和去抖放在同一入口，组合结束后补一次触发，并给联想请求加版本号。结果是一个三字词组一次输入，请求次数落在常见区间 1～2 次，选字时结果区不再跳；代价是组合期没有即时联想，需要提前和产品对齐预期。

组合输入处理的三步核对

与其在页面里到处打补丁，不如把什么时候该触发业务拆成三步核对。顺序反了，就会出现去抖也加了还搜半截字的情况。

1. 判定组合期：compositionstart 置标志位，compositionend 复位，同时读事件对象的 isComposing 做二次校验，两者取或更稳。
2. 决定触发点：组合期内的 input 只更新本地展示值，不触发请求与校验；组合结束后统一触发一次，避免漏掉最后一次变更。
3. 收口副作用：触发逻辑加去抖，常见区间 200～400ms；联想请求加取消或版本号，防止旧结果覆盖新结果。

常被漏掉的是第二步的补一次和第三步的取消旧请求。前者会让一句话输完却不出结果，后者在快速改词时会把上一次的联想结果盖回来。合格线可以定为：三字词组一次输入，请求次数在经验区间 1～2 次，且返回结果与最终输入的字一致。

两种实现方式的取舍对比

实际项目通常落在两种写法上，看的是团队维护成本和交互要求，而不是哪种更新。

• 方案 A：input + isComposing 判断，组合期跳过。逻辑集中在一处，触发次数少，兼容处理点单一；代价是组合期没有即时反馈，用户可能觉得没反应。
• 方案 B：input 负责非组合期即时反馈，compositionend 负责最终触发。响应更跟手，适合联想、纠错类交互；代价是要维护标志位，逻辑分两处，改动时容易只改一半。
• 对比维度：触发次数 A 更少；交互跟手度 B 更好；实现与维护成本 A 更低；适用面 B 适合强实时场景。
• 周期与成本：已有搜索框改造，经验区间为 0.5～2 人日；若涉及埋点口径、接口去重和兼容回归，常见区间为 2～5 人日。

方案定完要跟后端对一下限流与幂等口径，否则前端去抖做了，服务端仍按原来的 QPS 评估，联调时还可能被压回来。

验收与边界：哪些该做，哪些不必

验收不要只看现在能搜出来，按可核对的口径逐条过更省事。

• 组合期不刷新结果：输入拼音过程中，结果区与校验提示保持不动。
• 选完字有一次确定触发：compositionend 之后拿到的是完整词，请求与最终输入一致。
• 请求次数可解释：连续输入三到五个词，请求数与词数在同一量级，而不是随拼音字母数上升。
• 边界操作不丢触发：删除、粘贴、候选词替换、切换输入法后，都能正常触发且不漏。

适合：搜索联想、实时校验、字数统计与自动保存、输入行为埋点，以及需要按输入内容实时请求接口的场景。不适合：只在点击提交时读取值的表单、纯数字或英文编码类输入、低频内部后台页面，以及仍处于原型验证阶段的页面。如果副作用只是本地过滤一个几百条的小列表，不做组合判断通常也能接受。

边界判断可以用一句话概括：输入过程中会向外发请求、写存储或改状态，就该处理组合期；只在提交时读一次值，则不必为此增加复杂度。

常见问题

compositionend 之后还要不要再触发一次搜索？

要。部分浏览器在组合结束时不额外派发 input，常见做法是在 compositionend 里补一次触发，或直接读当前值走同一段逻辑。

加了 isComposing 判断，iOS 上仍不生效怎么办？

部分 iOS 版本与第三方输入法的 isComposing 时序不稳定，常用兜底是自行维护组合标志位，compositionstart 置位、compositionend 复位，再叠加去抖。

英文和数字输入会不会被一起拖慢？

不会。非组合输入不进入组合期，直接走常规分支即可；注意不要把英文输入的即时反馈也一起加上长去抖。

Vue 或 React 的双向绑定能自动处理好吗？

框架常见做法能减少组合期误触发，但触发频率与请求取消仍需自己控制，联想、自动保存这类副作用不能只依赖双向绑定。

落地建议：先在搜索、校验这类副作用入口加一层组合期判断与去抖，再补一条中文输入回归用例；对接时把限流和幂等口径一起对清楚。若产品只在点击后取值，或输入不产生外部请求，就不必为此增加复杂度。上线前按平台各测一遍中文输入法，把请求次数与最终结果逐条核对，比事后排查便宜。