accesskey按了没反应，因其仅尝试聚焦元素且现代浏览器普遍禁用：chrome 120+默认仅向屏幕阅读器暴露，firefox需手动开启辅助选项，safari需用户在系统设置中启用；真正可用的快捷键须用keydown全局监听并结合preventdefault、焦点管理与ui显式标注。
accesskey 为什么按了没反应
因为 accesskey 本就不触发操作，只尝试聚焦元素——而这个“尝试”在现代浏览器里大概率失败。Chrome 120+ 默认禁用键盘激活，仅向屏幕阅读器暴露；Firefox 需手动开启辅助选项；Safari 在 macOS 上默认不响应，除非用户进「系统设置 → 辅助功能」启用导航快捷键。更现实的问题是：你按 Alt+S，Chrome 可能直接跳转到地址栏，你的按钮根本收不到事件。
真正可用的快捷键必须用 keydown 监听
全局监听 document.addEventListener('keydown', handler) 是唯一可控路径，但细节决定成败：
- 用
e.key判断按键，不是e.code或已废弃的e.keyCode——e.key === 's'能正确识别 QWERTY/AZERTY 布局下的字母语义 - 组合键优先查布尔属性：
if (e.ctrlKey && e.key === 's')，而非拼接字符串或依赖物理键位 - 必须先排除输入场景：
if (e.target.matches('input, textarea, [contenteditable]')) return，否则用户在编辑时被意外拦截 - 调用
e.preventDefault()仅限你明确支持的组合，比如Ctrl+S；别拦Ctrl+T，拦了也无效，还可能破坏用户预期
单手操作要考虑焦点流与语义完整性
快捷键不该只是“执行动作”，而要维持键盘用户的操作闭环：
- 触发后必须先
.focus()目标元素，再.click()——否则屏幕阅读器无法播报状态变化，且用户无法用Enter/Space复用操作 - 目标元素得是原生可聚焦控件：
<button></button>、<input>天然支持；<div role="button"> 必须加 <code>tabindex="0"，否则.focus()无效 - 若快捷键打开面板（如帮助），优先用
<dialog></dialog>元素并调用.showModal()——它自动处理Esc关闭、焦点锁定和无障碍语义，比手写 div + aria 更可靠 - 避免在
<input>上直接绑定快捷逻辑——焦点不在它身上时监听失效；所有快捷键逻辑应统一走document级监听 - 绝对避开：
Ctrl+T、Ctrl+W、Ctrl+R、F5、F12、Alt+Tab（macOS 是Cmd+Tab） - 慎用系统级高频键：
Ctrl+S（保存）、Ctrl+F（查找）、Alt+F4（关闭窗口）——即使你preventDefault()，用户也可能因习惯性操作而困惑 - 移动端无
accesskey支持，keydown监听在软键盘弹出后也基本失效，单手操作需另配手势或大点击区域，别指望键盘快捷键覆盖全平台
哪些快捷键组合绝对不能碰
有些组合浏览器强占，硬劫持会静默失败或引发异常：
最常被忽略的一点：快捷键本身不可发现。用户不知道它存在，就不会用。无论用 accesskey 还是 keydown，都得在 UI 上显式标注，比如按钮旁加 (Ctrl+S)，或在设置页提供可配置快捷键列表——否则，再稳的实现也是摆设。
