accesskey 不适合大型 SaaS 后台快捷键系统——它无法监听、不触发 click、跨平台行为分裂、静默失效无提示；应改用 keydown + preventDefault 构建可控快捷键体系。
accesskey 不适合用在大型 SaaS 后台的快捷键系统中——它无法监听、不触发 click、跨平台行为分裂、且静默失效无提示，强行使用只会增加不可控故障点。
为什么 accesskey 在 SaaS 后台里必然冲突
大型后台通常需支持 Windows/macOS/Linux + Chrome/Firefox/Edge/Safari + 多语言键盘 + 屏幕阅读器 + 企业级扩展（如 Okta 插件、内部监控工具），而 accesskey 的触发逻辑完全依赖这些环境的叠加规则：
- Chrome v120+ 默认禁用键盘激活，仅暴露于可访问性 API，用户按
Alt+S不会聚焦，只可能被屏幕阅读器读出 - Firefox macOS 下
Ctrl+Option+S常被 VoiceOver 或系统「聚焦我的光标」快捷键劫持 - Safari 全平台忽略
accesskey，除非用户手动开启「偏好设置 → 辅助功能 → 使用键盘快捷键导航」——SaaS 用户不可能全员配置 - 企业密码管理器（如 1Password）默认监听所有
Alt+X组合，accesskey="l"（登录）会被直接吞掉，无日志、无报错
accesskey 只聚焦不执行，和后台操作需求根本错位
SaaS 后台的快捷键目标通常是“按下即生效”：比如 Ctrl+Shift+D 删除选中行、Cmd+K 唤起命令面板。但 accesskey 的行为是固定的：
-
<button accesskey="d">删除</button>按下对应组合键后，按钮仅获得焦点，仍需再按Enter或Space才触发 click - 无法用 JavaScript 监听
accesskey被激活事件——没有onaccesskey回调，keydown也捕获不到，因为浏览器在合成层就截断了 - 若强行补 JS：
document.addEventListener('keydown', e => { if (e.ctrlKey && e.shiftKey && e.key === 'd') btn.click() })，那accesskey属性本身已无存在必要
真正可控的快捷键方案：用 keydown + preventDefault 实现
大型后台应绕过 accesskey，直接用原生 keydown 事件构建快捷键系统，关键控制点如下：
立即学习“前端免费学习笔记（深入）”；
- 统一注册入口：在顶层组件或路由守卫中绑定
document.addEventListener('keydown', handler)，避免多个模块重复监听 - 显式声明修饰键：优先用
Ctrl/Cmd+ 字母组合（如Ctrl+S），避开Alt系列——因Alt在 Windows 是菜单焦点键，在 macOS 是输入法切换键，冲突率极高 - 加
e.preventDefault()阻止浏览器默认行为（如Ctrl+T新建标签页），但仅对已知安全组合启用，避免影响用户基础操作 - 动态禁用逻辑：当焦点落在
<input>或<textarea>内时，自动跳过快捷键响应，防止误触（可用document.activeElement.matches('input, textarea')判断） - 提供运行时快捷键面板：按
?弹出当前上下文可用快捷键列表，内容由 JS 动态生成，而非靠accesskey的静态属性推导
如果必须保留 accesskey（如满足某项审计要求）
仅限极少数高频、不可替代的全局动作，且必须配合严格约束：
- 值只用冷门数字：
accesskey="7"、accesskey="9"，避开a、f、s、t、n、w、l及全部功能键字符 - 元素必须原生可聚焦：
<button>、<input>可直接用；<div>类容器必须加tabindex="0"并手动绑定click或keydown - UI 必须显式标注：
搜索（<strong>Alt+7</strong>），且该文案需随平台动态切换（Windows 显示Alt+7，macOS 显示Ctrl+Option+7） - 上线前必须实测六种环境组合：Chrome Win / Firefox Win / Chrome macOS / Firefox macOS / Edge Win / Safari macOS，并关闭全部扩展
真正麻烦的不是写代码，而是每次发版后都要重新验证所有平台的快捷键是否被新版本浏览器或新装插件悄悄劫持——这个维护成本远高于从零实现一套 keydown 系统。
