accesskey仅将焦点移至元素，不触发动作，且因浏览器差异、系统冲突、元素不可聚焦等原因极易失效，不建议作为核心交互手段。
accesskey 能绑定快捷键，但不是“按了就触发动作”，它只负责把焦点移到对应元素上——而且这个行为在现代浏览器中高度受限、极易失效，不建议作为核心交互手段。
为什么 accesskey="s" 按了没反应
常见现象：写了 <input accesskey="s">，Windows 下按 Alt+S 却没聚焦，甚至弹出浏览器保存对话框。
- 浏览器默认快捷键劫持：Chrome 中
Alt+F打开菜单、Alt+S在部分版本中会触发“另存为”，直接拦截掉你的accesskey - 元素不可聚焦：只有原生可交互元素（
<input>、<button></button>、<textarea></textarea>、<select></select>）才支持；<div> 或 <code><span></span>加了也无效 - 重复值冲突：页面里多个元素用了同一个
accesskey值（如都写accesskey="n"），浏览器通常只响应第一个 - macOS 需用
Ctrl+Option+S，不是Alt+S；Safari 默认禁用，必须手动在「偏好设置 → 辅助功能」中开启“使用键盘快捷键导航” - 正确做法是给
<label></label>加accesskey，并用for属性绑定<input id>：<label for="search" accesskey="s">搜索</label><input id="search"> -
for的值必须和input的id完全一致（大小写敏感），否则绑定失败 - 这样按快捷键后，焦点落在
<label></label>上，点击或回车又能自然聚焦到关联控件，语义清晰，屏幕阅读器也能读出“搜索（快捷键 S）” - 避免用
s、f、n这类易冲突字母；推荐q、x、0等冷门字符 - 优先用
keydown，不是keyup：后者有延迟，且无法及时e.preventDefault() - 必须判断当前焦点位置：
if (['INPUT', 'TEXTAREA', 'SELECT'].includes(document.activeElement?.tagName) || document.activeElement?.isContentEditable) return;，否则用户在编辑框里按 Ctrl+S 就会触发你的逻辑 - 跨平台修饰键别写错：
e.metaKey对应 macOS 的 Cmd 键，e.ctrlKey对应 Windows/Linux 的 Ctrl；混用会导致 Mac 用户失效 - 记得加
e.preventDefault()，否则F5刷新、Ctrl+T新标签页等系统行为照常发生 - 可以考虑用的地方：
@#@#@#@#@#@#@#@#@#@0、搜索框<label accesskey="s">搜索</label>、返回顶部按钮 - 绝对不该用的地方：表单提交按钮（用户更习惯回车）、模态框内操作（焦点已被限制）、带副作用的动作（如“删除”——
accesskey只聚焦，不触发，反而误导） - 所有用了
accesskey的地方，UI 上必须显式标注，例如“搜索(Alt+S)”，否则 99% 的用户根本不知道它的存在 - Chrome 117+ 已默认禁用
a、e等键的accesskey，防止网页劫持地址栏——这意味着你写的accesskey="a"在新版 Chrome 里直接被忽略
accesskey 和 label 怎么配才真正可用
单独给 <input> 加 accesskey 是半残操作。用户按完快捷键后光标进了输入框，但完全不知道这是干啥的——缺少上下文。
替代 accesskey 的 JavaScript 快捷键更可控
如果目标是“按 Ctrl+Shift+H 打开帮助面板”，而不是“跳转到某个元素”，那必须用 keydown 监听——accesskey 根本做不到。
哪些地方真该用 accesskey，哪些地方绝对不该
它不是被废弃的属性，而是适用场景极窄：仅限高频、全局、无歧义的核心跳转入口，且必须配合视觉提示。
