accesskey不是快捷键方案而是可访问性机制，存在聚焦不触发、跨平台行为分裂、被插件劫持等问题，应弃用并改用满足e.code判断、修饰键检查、编辑态跳过三大约束的keydown监听体系。
accesskey 不是快捷键方案，而是可访问性辅助机制——它只聚焦、不触发、不可监听、跨平台行为分裂，强行用于热键管理必然冲突。大型项目应弃用，改用可控的 keydown 监听体系。
为什么accesskey在Chrome/Firefox/Safari中必然触发不一致
同一段 accesskey="s"，不同环境实际生效组合键完全不同，且无统一标准可依赖：
- Chrome Windows/Linux：按
Alt+s，但 Chrome 120+ 默认禁用键盘激活，需手动开启「设置 → 高级 → 按访问键聚焦元素」 - Firefox Windows/Linux：必须按
Alt+Shift+s，缺一不可；macOS 下还可能被 VoiceOver 的Ctrl+Option+s劫持 - Safari macOS：默认完全忽略
accesskey，用户必须先进入「系统偏好设置 → 辅助功能 → 键盘 → 使用键盘快捷键导航」手动启用 - 所有平台下，
Alt+f、Alt+e等键几乎必然被浏览器菜单或系统功能抢占，静默失效，无日志、无提示
如何避免accesskey被密码管理器或企业插件劫持
企业环境里，accesskey 组合键常被第三方插件直接吞掉，根本不到达页面：
- 1Password、Bitwarden 等密码管理器默认全局监听
Alt+字母组合，用于唤起填充面板 - Okta、Cisco AnyConnect 等安全插件会注册同名快捷键并调用
e.preventDefault()，你的按钮收不到焦点 - 截图工具（Snipaste）、翻译插件（沙拉查词）同样劫持
Alt+x类组合，且不暴露监听逻辑 - 验证方法：关闭所有扩展后重试；或用 Hotkey Detective（Windows）/ EventViewer（macOS）确认该组合是否已被其他进程注册
真正可用的热键管理：用document.addEventListener('keydown')替代
绕过 accesskey，直接监听 keydown 是唯一能落地的方案，但必须满足三个硬约束：
立即学习“前端免费学习笔记（深入）”；
- 用
e.code判断按键，而非e.key——e.code对应物理键位，不受 CapsLock、输入法、IME 影响（如e.code === 'KeyS'比e.key === 's'可靠） - 显式检查修饰键：
e.ctrlKey && e.shiftKey && e.code === 'KeyD'，避开Alt系列（Windows 菜单键 / macOS 输入法切换键） - 动态跳过编辑态：
if (document.activeElement.matches('input, textarea, [contenteditable]')) return，防止误触 - 必须耦合当前 UI 状态：模态框打开时禁用主界面快捷键，富文本编辑器聚焦时接管事件，路由变化后清理旧监听器
用户自定义热键时最易忽略的兼容点
当提供「快捷键设置页」时，真正的难点不在存储配置，而在运行时还原和冲突检测：
- 不能只存
{ "save": "ctrl+s" }，要拆解为{ mod: ["ctrl"], code: "KeyS" }，否则中文输入法下ctrl+s可能触发五笔候选窗而非保存 - 用户设了
ctrl+k唤起命令面板，但当前焦点在contenteditable区域内时，需主动降级为esc清空输入框，而非静默忽略 - 多个模块注册相同组合键（如两个组件都监听
ctrl+enter），必须有优先级调度或明确报错提示，不能叠加触发 - DevTools 控制台打开时，部分浏览器会临时禁用
keydown监听，这不是 bug，是设计行为——需在 UI 上提供手动触发入口作为 fallback
