accesskey 必然与系统快捷键冲突，因其绑定由浏览器底层合成层处理，不触发 keydown 事件，且 chrome 120+ 默认禁用、firefox macos 下被 voiceover 劫持、safari 全平台忽略，属规范留白导致的碎片化实现。
accesskey 为什么必然和系统快捷键冲突
它不是“可能冲突”，而是设计上就放弃控制权：浏览器把 accesskey 绑定交给底层合成层处理，不走 JS 事件流，也不发 keydown。Chrome 120+ 默认禁用键盘激活，Firefox macOS 下 Ctrl+Option+S 被 VoiceOver 劫持，Safari 全平台忽略——这些不是 bug，是规范留白导致的碎片化实现。
别在 document 上监听 accesskey 触发事件
根本监听不到：accesskey 激活后只改变 document.activeElement，不触发任何可捕获的事件。你写 document.addEventListener('keydown', ...) 或 element.addEventListener('focus', ...) 都收不到信号。强行补监听器（比如判断焦点是否落在某按钮上）属于事后推断，无法区分是用户按了 accesskey、Tab 切换、还是 JS 调用 .focus()。
Accessibility Review
下载
对设计或页面进行 WCAG 2.1 AA 无障碍审计。触发关键词：“audit accessibility”、 “check a11y”、 “is this accessible?” 或在审查设计时使用。
真正要防冲突，得绕过 accesskey 自己管组合键
- 用
document.addEventListener('keydown', handler)，但必须显式判断e.code（不是e.key），避免输入法或 CapsLock 干扰 - 修饰键优先用
ctrlKey/metaKey，避开altKey——Windows 下 Alt 是菜单键，macOS 下是输入法切换键 - 加
e.preventDefault()前先校验：只对已知安全组合（如Ctrl+Shift+D）拦截，保留Ctrl+T、F5等基础行为 - 动态跳过编辑态：
if (document.activeElement.matches('input, textarea, [contenteditable]')) return
快捷键逻辑必须耦合当前 UI 状态
不是写个监听器就完事。模态框弹出时，快捷键该不该生效？富文本编辑器正在输入时，Ctrl+B 是加粗还是跳转？这些都得靠状态机驱动：
例如保存操作需同时满足：!isEditing && route === '/form' && !modalOpen。漏掉任一条件，快捷键就变成不可预测的干扰源。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
