accesskey在云端ide中根本无法捕获快捷键，因其仅触发焦点转移而不参与keydown事件链，所有主流云端ide均采用document级keydown监听并结合e.code、编辑态判断与上下文耦合来实现可控快捷键。
accesskey在云端IDE里根本捕获不到快捷键
它不是“没生效”，而是压根不参与快捷键逻辑链——accesskey只负责把焦点移到元素上，不触发click或keydown事件，更不会穿透到编辑器内部。你在<button accesskey="r">运行</button>上按Alt+R，焦点确实跳过去了，但编辑器仍在监听自己的keydown流，完全收不到这个信号。
真实现象包括：accesskey触发后编辑器光标不动、快捷键提示无响应、组合键被浏览器吞掉（比如Ctrl+S保存页面而非触发IDE保存）、Mac下Ctrl+Option+R直接被系统级快捷键拦截。
- 所有主流云端IDE（CodeSandbox、StackBlitz、GitHub Codespaces）均未使用
accesskey实现核心快捷键 -
accesskey值必须是单字符，无法表达Ctrl+Shift+F这类多键组合 - 编辑器容器（如
monaco-editor或codemirror）本身会调用e.preventDefault()并阻止冒泡，document级监听都收不到，accesskey更不可能穿透
为什么不能靠accesskey做快捷键路由
因为它的行为不可编程、不可干预、不可取消：你无法在accesskey触发前判断当前是否处于编辑态，也无法跳过模态框弹出时的误触发，更没法和编辑器的editor.getAction('editor.action.formatDocument').run()这种API对齐。
典型冲突场景：
对设计或页面进行 WCAG 2.1 AA 无障碍审计。触发关键词：“audit accessibility”、 “check a11y”、 “is this accessible?” 或在审查设计时使用。
- 用户正在
<textarea></textarea>里写代码注释，按Alt+R本该运行，结果焦点跳到按钮上，输入中断 - 富文本插件（如Tiptap）接管了
keydown，accesskey连focus都失败 - React组件卸载后
accesskey绑定残留，新面板打开时旧快捷键仍可触发（但执行的是已销毁的回调）
真正要监听的只有document.addEventListener('keydown')
所有稳定可用的云端IDE快捷键系统，底层都是直接监听document级keydown，再结合上下文过滤。关键不是“怎么加监听”，而是“怎么让监听不翻车”：
- 必须用
e.code而非e.key：前者对应物理按键（'KeyR'），不受CapsLock、输入法、IME影响；后者（'r'或'R'）在中文输入法下常为空或乱码 - 必须主动排除编辑态：
if (e.target.matches('input, textarea, [contenteditable]')) return - 必须耦合焦点栈：检测当前是否在
modal、dialog或codemirror实例内，避免快捷键跨上下文误执行 - 修饰键判断要严格：
e.ctrlKey && e.shiftKey && e.code === 'KeyF'，不能只靠e.key === 'f'加一堆toLowerCase()
accesskey唯一能用的场景：无障碍跳转入口
如果你真要用accesskey，只建议放在三个地方：@#@#@#@#@#@#@#@#@#@0、<button accesskey="s">保存文件</button>、<input type="search" accesskey="k" placeholder="搜索符号">。仅此而已。
注意这些细节：
- 显式标注快捷键：
保存文件 (Ctrl+S)比保存文件多一行文案，但用户立刻知道怎么用 - 避开系统冲突键：
accesskey="f"在Firefox里打开书签栏，accesskey="t"在Chrome里新建标签页，统统绕开 - 测试必须覆盖开启VoiceOver/NVDA的场景：某些屏幕阅读器会重映射
accesskey，甚至完全忽略它
复杂点不在监听器怎么写，而在每次键盘按下时，你要同时确认：焦点在哪、编辑器是否激活、当前路由是否允许该操作、有没有弹窗遮挡——accesskey连第一个问题都答不上来。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
