accesskey 仅实现焦点转移，不触发操作；可靠快捷键需用 keydown 监听并手动处理组合键逻辑，同时避开系统冲突、标注提示、降级兼容。
accesskey 不是网页快捷键的可靠实现方式，它只负责把焦点移到元素上，不触发点击、提交或任何业务逻辑；真要实现 Ctrl+S 保存、Ctrl+Enter 运行这类行为，必须用 keydown 监听。
accesskey 按了没反应？先确认它本就不该“触发操作”
这是最常被误解的一点：加了 accesskey="s"，按 Alt+S（Windows）或 Ctrl+Option+S（macOS）后按钮获得焦点，仅此而已。用户还得再按 Enter 或 Space 才能触发 click 事件——它不是热键，而是辅助导航入口。
- 常见错误现象：
button加了accesskey却没弹窗、没保存、没跳转，其实是预期行为，不是 bug - 浏览器拦截严重：Chrome 中 Alt+S 默认跳地址栏，Firefox 中 Alt+Shift+S 可能被扩展劫持，Safari 默认禁用且需手动开启「在网页中使用键盘快捷键」
- 值写错会静默失效：
accesskey="ctrl+s"（必须单字符）、accesskey=" "（空格）、accesskey="?"（非 ASCII）全被忽略
哪些元素能响应 accesskey？别乱绑
accesskey 只对可聚焦元素生效，不是所有标签都支持。默认不可聚焦的元素（如 div、span、tr）加了也白加。
- ✅ 天然可聚焦：
button、a、input、textarea、select - ✅ 可手动激活：
div或span加tabindex="0"后才响应 - ❌ 无效绑定：
table、tr、td、span（无tabindex）、label（无 for 属性或包裹内容） - ⚠️ 注意：
tabindex="-1"的元素不能通过accesskey聚焦，只能用 JS.focus()主动调用
真正可用的快捷键必须用 keydown 实现
监听 document 上的 keydown，才能绕过 accesskey 的平台限制和语义局限，实现确定性行为。
- 判断组合键用
e.ctrlKey && e.key === 's'，别用e.code === 'KeyS'（AZERTY 键盘下会错） - 先排除输入场景：
if (['INPUT', 'TEXTAREA', 'SELECT'].includes(e.target.tagName) || e.target.isContentEditable) return - 只对明确注册的快捷键调
e.preventDefault()，比如 Ctrl+T 就不该拦——拦了也无效，还破坏体验 - 触发操作前建议先
.focus()目标元素，再.click()，这样屏幕阅读器能播报状态变化 - Mac 用户用
e.metaKey，Windows/Linux 用e.ctrlKey，别混用或硬写 Ctrl 文字
如果仍要用 accesskey，这些细节决定它是否“不拖后腿”
它不是功能开关，只是个可选的辅助提示。想让它至少不干扰体验，得避开系统级冲突、提供视觉反馈、并降级处理。
- 避开易冲突字母：
accesskey="w"（Chrome 窗口管理）、accesskey="n"（新建标签）、accesskey="r"（刷新），优先选z、x、q或数字1–9 - 必须显式标注：
<button accesskey="s">保存</button>[<code>Alt+S]，否则用户根本不知道存在这个快捷键 - 多个相同值行为未标准化：Firefox 聚焦第一个，Chrome 可能跳过，务必保证全站唯一
- 移动端完全不支持：iOS Safari / Android Chrome 均忽略
accesskey，别为触屏设备做任何假设
真正复杂的是上下文判断——什么时候该让快捷键生效，什么时候该放行（比如用户正在输入时按 Ctrl+S 应保存当前编辑框内容，而非整个页面）。这没法靠 accesskey 解决，只能靠你写的 keydown handler 里那几行条件逻辑。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
