应结合compositionstart、compositionend事件设标志位控制keydown逻辑，合成期间跳过业务处理，compositionend后获取真实输入内容。
在组合输入法（如中文拼音输入）过程中，keydown 事件确实会频繁触发，但**不能直接依赖它来准确拦截或判断用户最终输入的内容**，因为 Composition 过程中按键行为与真实字符输入是分离的。要可靠地拦截/控制输入，必须结合 compositionstart、compositionupdate、compositionend 三个事件，并合理利用事件捕获与冒泡阶段——但关键不在于“在哪一阶段监听 keydown”，而在于**如何避免在合成期间误处理 keydown**。
理解 Composition 过程中的事件顺序
以中文输入法为例：
- 用户按下 Shift + 空格 或开始输入拼音 → 触发
compositionstart - 持续输入拼音（如
zhong）→ 多次触发compositionupdate - 按
Space确认、Enter上屏、或Esc取消 → 触发compositionend，此时才真正生成字符（如 “中”） - 在整个过程中，
keydown几乎每次按键都触发（包括z、h、o、n、g、Space），但这些按键并不对应最终输入的字符
为什么不能靠捕获/冒泡阶段“拦截” keydown 来阻止输入
keydown 是底层按键事件，浏览器不会因你在捕获或冒泡阶段调用 e.preventDefault() 就阻止输入法进入合成状态——尤其对 IME（输入法编辑器）来说，系统级行为优先级更高。即使你 preventDefault() 了 keydown，输入法仍可能继续工作，甚至导致光标错乱或输入异常。
真正有效的拦截时机是：
立即学习“Java免费学习笔记（深入）”；
- 在
compositionstart中设标记isComposing = true - 在
keydown中检查isComposing，若为true则跳过业务逻辑（如禁止某些键、自动提交等） - 在
compositionend后再处理真实输入内容（此时e.data是最终字符串）
推荐写法：用标志位 + composition 事件协同控制
无需纠结捕获还是冒泡——keydown 和 composition* 默认都是冒泡事件，绑定在相同目标（如 <input>）上即可：
const input = document.querySelector('input');
let isComposing = false;
input.addEventListener('compositionstart', () => {
isComposing = true;
});
input.addEventListener('compositionend', (e) => {
isComposing = false;
console.log('实际输入：', e.data); // ✅ 这里才是真实字符
});
input.addEventListener('keydown', (e) => {
if (isComposing) return; // ? 关键：合成中跳过所有 keydown 业务逻辑
// 此处处理非合成状态下的按键，例如：
if (e.key === 'Enter') {
handleSubmit();
}
if (e.key === 'Escape') {
clearInput();
}
});
特殊情况：需要响应合成过程中的按键（如禁用某快捷键）
如果确实需要在 compositionupdate 期间响应某个物理键（比如禁止用户在输入拼音时按 Ctrl+S 保存），可监听 keydown 并检查 e.ctrlKey && e.key === 's'，此时仍可用 preventDefault() 阻止默认行为（如浏览器保存），但不要干扰输入法本身。只要不修改输入框值、不调用 focus()/select() 等影响光标的操作，一般安全。
不复杂但容易忽略：Composition 不是 bug，是规范行为；与其对抗 keydown，不如拥抱 composition* 事件流。
