键盘事件失效主因是JS逻辑或DOM状态问题，如preventDefault误用、焦点锁定、contenteditable异常、监听器未委托或丢失；应通过捕获阶段断点和activeElement定位根源。

不是硬件冲突，绝大多数情况是 JavaScript 事件监听逻辑或 DOM 状态导致的键盘事件被拦截、吞掉或未触发。

为什么 keydown / keypress 监听器突然不生效

常见现象：页面加载后按键盘无反应，console.log 完全没输出；但鼠标点击、滚动等其他事件正常。根本原因往往不是浏览器或系统级禁用，而是事件流在到达目标前就被阻止了。

• event.preventDefault() 在父级（如 body 或模态框容器）上被无条件调用，且未加判断条件
• 某个第三方库（如 react-modal、focus-trap）启用了焦点锁定（focus trapping），主动 preventDefault 所有非可聚焦元素的键盘事件
• 页面存在 contenteditable="true" 的空 div 或富文本区域，获得焦点后却未正确处理键盘输入，导致事件“卡住”
• 监听器绑定在动态插入的元素上，但未用事件委托，DOM 更新后监听器丢失

如何快速定位哪个脚本在吞键盘事件

打开 Chrome DevTools → Elements 面板 → 右键任意元素 → Break on > attribute modifications，然后在控制台执行：

document.addEventListener('keydown', e => { debugger; }, true);

这个 true 表示捕获阶段监听，能最早拦截事件。触发后看调用栈，重点关注：

Article To Html

文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。

下载

立即学习“前端免费学习笔记（深入）”；

• 是否进入某个 node_modules 的 UI 库内部函数（如 Modal.handleKeyDown）
• 是否在 document 或 body 上有重复绑定且含 preventDefault 的监听器
• 当前 document.activeElement 是什么？如果是 iframe、input 或意外的 div[contenteditable]，就说明焦点不在预期位置

tabindex="-1" 和 focus() 导致键盘不可用的典型场景

很多组件（下拉菜单、Tooltip）靠 tabindex="-1" + element.focus() 实现键盘可访问性，但若后续未正确管理焦点状态，就会让键盘“失灵”——按键仍发生，但没元素接收。

• 手动调用 el.focus() 后，没有同时绑定 keydown 处理逻辑（比如方向键导航）
• 弹出层关闭时，未将焦点恢复到触发按钮，导致焦点“丢失”到 body（而 body 默认不可键盘交互）
• tabindex="-1" 元素获得焦点后，CSS 设置了 outline: none 且无替代焦点样式，开发者误以为没响应，实则是焦点存在但不可见
• 在 Shadow DOM 内部设置 tabindex，但宿主元素未设 tabindex，导致无法通过 Tab 进入该影子根

兼容性与现代写法建议

老代码常用 keypress 判断字符输入，但它已被废弃，且在 Safari 和部分中文输入法下行为异常；keydown 更可靠，但需注意 event.key 和 event.code 区别：

• 用 event.key === 'Enter' 判断语义键（受 CapsLock、Shift 影响）
• 用 event.code === 'Enter' 判断物理键位（不受输入法和大小写影响）
• 中文输入场景下，compositionstart/compositionend 必须监听，否则 keydown 会收到大量中间码，误触发快捷键
• React 中避免在 useEffect 里反复 addEventListener 而不 removeEventListener，会导致监听器堆积并干扰事件流

真正难排查的，往往是多个小配置叠加的效果：一个 focus()、一个 preventDefault()、一个没清理的监听器、再加一个 contenteditable，四者合谋让键盘看起来“坏了”。动手前先查 activeElement 和捕获阶段断点，比换键盘有用得多。