accesskey触发后没反应，大概率是被浏览器或系统静默拦截，因其仅聚焦不触发事件；应弃用并改用document.addEventListener('keydown')监听，配合e.code判断、修饰键检查及编辑态跳过。
accesskey 触发后没反应，大概率是被浏览器或系统吞了
不是你代码写错了，而是 accesskey 本身不参与事件流，只负责把焦点移到元素上——它不发 click，也不触发 keydown，更不会绕过浏览器菜单键（比如 accesskey="f" 在 Firefox 中直接跳到地址栏）。Windows 下按 Alt+f、macOS 下按 Ctrl+Option+f，这些组合早被系统/浏览器预占，静默拦截，无提示、无日志。
常见失效场景包括：
-
accesskey="s"在 Chrome Windows 下可能激活地址栏而非你的按钮 -
accesskey="r"在 Safari macOS 上默认完全忽略，除非用户手动开启「辅助功能 → 使用键盘快捷键导航」 - 企业环境里，1Password、Okta 插件会全局监听
Alt+x类组合并调用e.preventDefault()，你的页面收不到任何信号
别修 accesskey，直接换掉它：用 document.addEventListener('keydown')
所有稳定项目（CodeSandbox、GitHub Codespaces、VS Code Web）都已弃用 accesskey 做快捷键路由。真正可控的方案是监听 document 级 keydown，但必须满足三个硬约束：
- 用
e.code判断按键，比如e.code === 'KeyR'；别用e.key，后者在中文输入法下常为空或大小写错乱 - 显式检查修饰键：
e.ctrlKey && e.shiftKey，避开Alt系列（Windows 菜单键、macOS 输入法切换键） - 动态跳过编辑态：
if (document.activeElement.matches('input, textarea, [contenteditable]')) return，防止用户写注释时误触运行
如果必须保留 accesskey，只当它是个无障碍兜底入口
accesskey 不该承载核心操作逻辑，只适合给高频、低风险动作配一个可访问性入口，例如「清空输出」或「跳转帮助」。要让它不翻车，得严格守这几条：
立即学习“前端免费学习笔记（深入）”；
- 值必须是单个 ASCII 字符（
a–z、0–9、-、=），accesskey="ctrl+s"这种写法会被浏览器静默忽略 - 绑定对象必须可聚焦：
<button>可以，<div>必须加tabindex="0"，<span>加了也没用 - 避免与 MDN 列出的 reserved access keys 冲突，比如
f（查找）、t（新标签页）、w（关闭窗口） - UI 上必须显式标注，例如：
<button accesskey="c">清除(Alt+C)</button>；否则用户根本不知道这个键存在
测试 accesskey 是否真生效，不能只靠自己点一点
它是否起作用，取决于目标用户的实际环境，不是开发机配好了就行：
- 在无痕模式下测试，禁用所有插件（尤其密码管理器和翻译工具）
- 换系统：Windows 试
Alt+s，macOS 试Ctrl+Option+s，注意 VoiceOver 可能劫持h（跳标题）、l（跳链接） - 用控制台实时验证：
document.activeElement是否等于你的目标元素；如果没变，说明组合键压根没落到页面 - 别信「支持列表」——Chrome 120+ 默认禁用键盘激活，需手动打开
chrome://flags/#enable-access-keys并重启
真正难的不是写监听，而是让快捷键在富文本编辑、模态框弹出、多 tab 切换、输入法激活等真实场景下不误触发、不丢失上下文。这些细节不处理，accesskey 或 JS 监听都会变成不可维护的定时炸弹。
