HTML无原生快捷键，冲突源于JavaScript监听、浏览器行为、编辑器及系统快捷键叠加；应监听document.body而非document，用KeyboardEvent.code而非key判断按键，动态检测焦点状态以控制快捷键启用时机。
HTML 本身没有快捷键，所谓“冲突”是 JavaScript 监听、浏览器原生行为、编辑器或系统快捷键三层叠加的结果。直接改 accesskey 或在 document 上硬绑 keydown 不仅无效，还容易让 Ctrl+S 保存失灵、Alt+Tab 切页卡住。
为什么 document.addEventListener('keydown') 经常收不到按键
不是监听器写错了，而是事件根本没到达你那里：
- 焦点停在
<button>或<input>上时，document不触发keydown；换成监听document.body更稳定 -
<input>和<textarea>会吞掉Enter、Arrow、Tab等键，除非你在目标元素上显式调用event.preventDefault() - React/Vue 等框架可能接管事件委托，
document上的 handler 被绕过，而document.body更贴近底层捕获流
用 KeyboardEvent.code 而不是 KeyboardEvent.key 做判断
event.key 返回的是字符（如 "a" 或 "A"），受 Caps Lock、输入法、键盘布局影响；中文输入法下按 Ctrl+A 可能返回 "Process" 或空字符串，拦截直接失效。而 event.code 表示物理按键位置（如 "KeyA"、"ControlLeft"），跨平台一致：
- 判断 Ctrl+S：用
event.code === 'KeyS' && (event.ctrlKey || event.metaKey)，别用event.key === 's' - 区分 Ctrl+Backspace（删前一个词）和 Ctrl+Delete（删后一个词）：前者触发
event.code === 'Backspace'，后者才是'Delete' - Firefox 某些版本中
Ctrl+Shift+Tab的code可能返回'Tab'，必须补上event.shiftKey && event.ctrlKey才可靠
如何只在非编辑状态下启用快捷键
用户正在打字时，你不该劫持 Ctrl+Z——那该由输入框自己处理。必须动态判断当前上下文：
立即学习“前端免费学习笔记（深入）”；
- 检查焦点是否落在可编辑区域：
['INPUT', 'TEXTAREA', 'SELECT'].includes(document.activeElement?.tagName) - 对
contenteditable元素，额外加一层判断：document.activeElement?.isContentEditable - 在 React 中，不要把
onKeyDown写在 JSX 根 div 上；应在useEffect里挂document.addEventListener，卸载时务必removeEventListener - 移动端 iOS Safari 对
contenteditable的keydown支持不稳定，必要时监听beforeinput并检查event.inputType === 'historyUndo'做兜底
accesskey 几乎不该用，替代方案更可控
accesskey="s" 在 Chrome/mac 需 Alt+Option+S，Firefox/win 是 Alt+S，Safari 又不同；它还和系统级快捷键（Cmd+T、Alt+Tab）冲突，且无视觉反馈，屏幕阅读器用户可能误触发。真正可落地的可访问性提升点是：
- 提供跳过链接：
<a href="#main-content" class="skip-link">跳到主要内容</a>，配合tabindex="-1"和 CSS 显示逻辑 - 确保所有交互元素有明确焦点顺序，用
tabindex="0"让非语义元素可聚焦，tabindex="-1"控制临时聚焦 - 复杂组件（如富文本工具栏）用
role="toolbar"+aria-orientation="horizontal"+ 键盘导航逻辑（Tab 进入、Arrow 切换、Space/Enter 触发） - 禁用
accesskey，转而用统一的useHotkeyHook 管理快捷键启用状态，比如编辑模式开启时才响应 Ctrl+Z，表单提交中则自动禁用
最常被忽略的一点：快捷键逻辑不是独立模块。它必须和焦点管理、表单脏检查、编辑模式开关实时联动——否则 modal 弹出后焦点被锁，你的全局监听器还在等一个永远不来的 keydown。
