accesskey 必然被系统/浏览器/插件劫持，无法可靠触发，必须弃用；所有稳定 SaaS 后台均改用 document 级 keydown 监听，并严格满足修饰键兼容、e.code 判断、编辑态拦截三大条件。
accesskey 不能解决冲突，它本身就是冲突源——所有“覆盖”尝试都是徒劳的，必须弃用。
为什么 accesskey 必然被系统/浏览器/插件劫持
它不走 JavaScript 事件流，浏览器底层合成层直接拦截组合键，keydown、focus、click 全部监听不到。Chrome 120+ 默认禁用键盘激活，仅暴露给屏幕阅读器 API；Firefox macOS 下 Ctrl+Option+S 被 VoiceOver 劫持为「跳到下一个表单控件」；Safari 全平台默认忽略该属性。你写的 accesskey="s" 在真实用户环境里，大概率根本没机会触发。
- Windows 用户按
Alt+S→ 触发浏览器「另存为」原生行为，你的按钮收不到任何信号 - macOS 用户按
Cmd+Space唤起 Spotlight → 整个页面键盘事件暂停，accesskey彻底失效 - 企业内网装了密码管理器或 Vimium 类扩展 → 全局监听
Alt+字母并preventDefault()，静默吞掉事件，无报错、无日志
document.addEventListener('keydown') 是唯一可控路径
所有稳定 SaaS 后台（Notion、Linear、Jira）都绕过 accesskey，直接监听 document 级 keydown，但必须满足三个硬条件：
- 修饰键判断同时检查
e.ctrlKey和e.metaKey：macOS 用户按Cmd+S，Windows 用户按Ctrl+S，只判一个会漏掉一半用户 - 按键识别必须用
e.code === 'KeyS'，不是e.key === 's'：前者对应物理按键位置，不受 CapsLock、输入法、IME 模式干扰 - 必须主动跳过编辑态：
if (document.activeElement.matches('input, textarea, [contenteditable]')) return，否则用户在输入时按Ctrl+S会意外触发保存
快捷键逻辑必须耦合当前 UI 状态
快捷键不是写个监听器就完事。它必须感知上下文，否则就是干扰源：
立即学习“前端免费学习笔记（深入）”；
- 模态框弹出时，
Ctrl+S应该失效，或转为「关闭模态框」而非「保存主表单」 - 富文本编辑器（如 Tiptap）接管了所有键盘事件，
preventDefault()后不冒泡，document监听器收不到事件——得在编辑器内部注册快捷键，或通过其插件机制注入 - React/Vue 组件卸载时未清理监听器，旧模块的
Ctrl+Shift+D和新模块的同名组合键叠加触发两次 - 路由变化后，快捷键需动态启用/禁用：
if (route === '/form' && !isEditing) { save() }
真正容易被忽略的是：accesskey 没有视觉反馈通道，无法用 CSS 选中“当前被激活的元素”，也无法用 JS 判断“用户刚按了哪个 accesskey”。你写的提示文案“保存(Alt+S)”对 macOS 用户就是错的，而改成“保存(Ctrl+Option+S)”又会让 Windows 用户困惑——没有一种写法能覆盖真实用户路径。
