accesskey 在各平台和浏览器中触发方式不统一且常被系统/扩展劫持，移动端完全不支持且无法检测，可靠方案是用 keydown 事件自定义快捷键并严格判断修饰键、按键码和焦点状态。
accesskey 在 Windows/macOS/Linux 下的触发组合根本不同
同一个 accesskey="s"，在真实用户环境里可能对应四种以上激活方式：Alt+S（Chrome/Windows）、Ctrl+Option+S（Safari/macOS）、Alt+Shift+S（Firefox/Windows）、Ctrl+Option+Shift+S（某些 Firefox/macOS 配置）。这不是浏览器 bug，而是 HTML 规范没强制约定组合键，各实现自行决定。用户看到按钮上写的“（Alt+S）”，在 macOS 上按了毫无反应——不是他错了，是你写的提示本身就不覆盖真实路径。
系统和浏览器原生快捷键会直接吞掉 accesskey
你设了 accesskey="t"，但用户一按就开了新标签页；设了 accesskey="r"，页面却刷新了。这不是代码问题，是浏览器把组合键优先交给了自身功能处理，accesskey 根本没机会被识别。常见冲突包括：
-
accesskey="f"→ 被 Chrome 地址栏聚焦劫持 -
accesskey="1"–"9"→ 多数浏览器绑定到标签页切换 -
accesskey="c"→ 和 macOS 系统「拷贝」Cmd+C 冲突，尤其当焦点在可编辑区域时 - 密码管理器、Vim 插件（如 Vimium）、截图工具等扩展常全局监听
Alt+字母，直接preventDefault()吞掉事件，不报错也不透传
移动端完全不支持，且无法降级感知
iOS Safari 和 Android Chrome 全面忽略 accesskey 属性，连 focus() 都不会触发。更麻烦的是：没有 JS 事件、没有 DOM 变化、也没有控制台警告，你没法在运行时检测“当前环境是否支持”。写个 if ('accessKey' in document.body) 毫无意义——这个属性永远存在，只是行为被静默禁用。试图用 UA 判断平台再开关逻辑，既不可靠（UA 可伪造），又维护成本高（iOS 新版本可能某天“部分支持”，但行为仍是黑洞）。
真正能落地的规避方案只有绕开 accesskey 自己管
别在 button 上写 accesskey 然后指望它工作。要实现可靠快捷操作，必须用 document.addEventListener('keydown', handler)，并满足三个硬条件：
立即学习“前端免费学习笔记（深入）”；
- 修饰键判断同时检查
e.ctrlKey和e.metaKey，不能只看一个 - 按键比对用
e.code === 'KeyS'，不用e.key——避免 CapsLock、输入法、IME 导致误判 - 开头就加防护：如果
document.activeElement.matches('input, textarea, [contenteditable]')为真，直接return
复杂点在于：这个监听器不能是孤立模块。它得知道当前是否弹出模态框、富文本编辑器是否处于编辑态、路由是否在表单页——漏掉任一状态判断，快捷键就会在不该生效时触发，或在该生效时静默失败。
