accesskey 必然与系统快捷键冲突，因其绑定由浏览器底层合成层处理，不经过 js 事件流，chrome 120+ 默认禁用、firefox macos 下常被 voiceover 劫持、safari 全平台忽略，属规范留白导致的碎片化实现。
accesskey 为什么必然和系统快捷键冲突
它不是“可能冲突”，而是浏览器把绑定逻辑交给底层合成层处理，不走 JS 事件流，也不发 keydown。Chrome 120+ 默认禁用键盘激活，Firefox macOS 下 Ctrl+Option+S 常被 VoiceOver 劫持，Safari 全平台忽略——这些不是 bug，是规范留白导致的碎片化实现。
哪些键位在各平台都高危，必须避开
别碰系统级保留键，否则用户按了根本没反应，还查不出错：
-
accesskey="f"：Chrome/Firefox 中直接触发「查找」（Ctrl+F），accesskey 被静默吞掉 -
accesskey="t"：几乎所有浏览器中与「新建标签页」（Ctrl+T）冲突 -
accesskey="w"：Chrome 中默认关闭当前窗口/标签页，优先级远高于你的按钮 -
accesskey="r"：Firefox/Edge 中常被「刷新」劫持；accesskey="1"～accesskey="9"在 Chrome 中对应标签页切换 -
accesskey="s"：Windows 下Alt+S多数跳地址栏，macOS 下Cmd+S是「另存为」原生行为，抢不到控制权
真正能落地的替代方案：用 keydown 监听绕过 accesskey
要实现「按 Ctrl+S 就保存」这种确定性行为，必须放弃 accesskey，改用 JS 主动监听：
- 监听
document.addEventListener('keydown', handler)，而不是等accesskey触发 - 判断组合键用
e.ctrlKey && e.key === 's'（不用e.code，避免 AZERTY 键盘错判） - 先过滤输入场景：
if (['INPUT', 'TEXTAREA', 'SELECT'].includes(e.target.tagName) || e.target.isContentEditable) return - 只对已知安全组合调
e.preventDefault()，比如Ctrl+Shift+D，别拦Ctrl+T或F5 - 操作前建议显式
.focus()目标元素，再.click()，保证屏幕阅读器可播报
如果非要用 accesskey，这三条底线不能破
仅限合规补丁或 legacy 模块迁移场景，且必须守住：
- 值只选冷门字符：
accesskey="z"、accesskey="x"、accesskey="0"（0在 Safari 中是「跳至主内容」的 WCAG 推荐值） - 必须显式标注 UI：
<button accesskey="z">撤销</button>(Alt+Z)，不能只靠属性存在 - 必须加
aria-label或title，否则焦点到了用户也不知道干啥；同时确保元素天然可聚焦（<button></button>、<a></a>、<input>），别绑在没tabindex="0"的<div> 上 真正的兼容难题不在代码怎么写，而在你无法控制用户开了什么插件、系统是否启用 VoiceOver、浏览器 flag 是否开启——<code>accesskey的行为边界从来就不是开发者能定义的。
