accesskey 无法覆盖浏览器默认快捷键，会静默失效；不同浏览器激活组合不一致，无法统一提示；无法监听其触发事件；可控快捷键需自行用 keydown 实现。
accesskey 从不覆盖浏览器默认快捷键，它只是被静默丢弃
你写 accesskey="s"，指望 Alt+S 触发按钮，结果 Chrome 直接弹出“另存为”——这不是 bug，是设计如此。accesskey 没有“覆盖权”，它的组合键在合成层就被系统或浏览器拦截，根本不会到达你的页面逻辑。Chrome/Firefox/Safari 都把 Ctrl+S、Alt+F4、Cmd+W 这类组合键划为“不可劫持区”，accesskey 值只要撞上这些，就注定失效。
常见静默失效组合包括：
- accesskey="s" → 被 Ctrl+S / Alt+S（Chrome 保存）吃掉
- accesskey="t" → 被 Ctrl+T（新标签页）拦截
- accesskey="f" → Firefox 地址栏聚焦优先级更高
- accesskey="r" → Chrome/Firefox 刷新行为抢占
不同浏览器对同一 accesskey 的激活组合根本不一致
你无法用一套说明文案覆盖所有用户。同一个 accesskey="h"，在真实环境中触发方式如下：
- Chrome/Windows：Alt+H（但若系统启用了“高对比度模式”，可能被禁用）
- Firefox/Windows：Alt+Shift+H（且若启用
accessibility.typeaheadfind，会直接跳搜索） - Safari/macOS：Ctrl+Option+H（但需用户手动开启「使用键盘快捷键访问网页项目」）
- VoiceOver 启用时：H 被重映射为“跳到标题”，你的按钮收不到任何信号
这意味着你在按钮旁写“Alt+H”的提示，对 macOS 用户就是错的；改成“Ctrl+Option+H”，又会让 Windows 用户困惑。没有统一路径。
想监听 accesskey 是否被按下？根本做不到
很多人试图在 document 上监听 keydown 或给元素加 focus 事件来捕获 accesskey 行为，结果全失败。原因很直接：
- accesskey 激活不触发 keydown、keypress 或 keyup
- 它只悄悄修改 document.activeElement，连 focusin 都不一定可靠（有些浏览器不派发）
- 你看到元素获得焦点，可能是 Tab 切换、JS .focus()、还是 accesskey，三者完全无法区分
所以所谓“accesskey 触发后自动点击”，只能靠轮询或 focus 后加延时判断，属于事后推测，稳定性差、易误判。
立即学习“前端免费学习笔记（深入）”；
真正可控的快捷键必须绕过 accesskey 自己实现
如果你需要 Ctrl+Enter 提交、Ctrl+Shift+D 删除这类明确行为，唯一靠谱路径是：
- 用 document.addEventListener('keydown', handler)
- 显式检查 e.code（不是 e.key），避免输入法干扰
- 只对 e.ctrlKey && e.code === 'Enter' 这类已知安全组合调用 e.preventDefault()
- 动态跳过编辑态：if (document.activeElement.matches('input, textarea, [contenteditable]')) return
- 必须耦合 UI 状态：模态框打开时禁用全局快捷键，富文本编辑器中 Ctrl+B 应加粗而非跳转
accesskey 唯一还剩一点价值的场景，是作为 WCAG 合规的语义锚点——比如给搜索框配 accesskey="s"，并确保它 focus 后按 Enter 就能搜。但它永远不该是你快捷键逻辑的主干。
