saas后台禁用accesskey而应监听document级keydown事件，因accesskey受浏览器/插件/系统干扰不可控；需同时判ctrlkey/metakey、用e.code而非e.key、跳过编辑态，并与焦点栈、编辑模式、路由状态耦合。
别在 SaaS 后台里用 accesskey 做快捷键系统——它不是防冲突的问题，而是根本不可控、不可测、不可维护。
为什么 accesskey 在 SaaS 后台里必然失效
大型 SaaS 后台的用户环境高度碎片化：Windows + Chrome、macOS + Firefox、企业定制版 Edge、带密码管理器/截图工具/翻译插件的浏览器……而 accesskey 的触发逻辑完全依赖这些环境的底层行为，且无任何反馈通道：
- Chrome 120+ 默认禁用键盘激活，仅暴露给屏幕阅读器 API，
document.activeElement不变，页面无任何视觉响应 - Firefox macOS 版中，
accesskey="s"被 VoiceOver 的「跳到下一个表单控件」快捷键（Ctrl+Option+S）劫持，你的按钮收不到焦点 - 企业内网常预装安全插件，它们全局监听 Alt+字母组合，直接
event.preventDefault()吞掉事件，不抛错、不 log - 用户打开多个标签页后，焦点可能卡在某个
<input>上，此时按任何accesskey都无效——因为浏览器只把组合键发给当前聚焦元素的上下文
document.addEventListener('keydown') 是唯一可落地的方案
所有靠谱的 SaaS 后台快捷键系统（如 Notion、Linear、Jira）都绕过 accesskey，直接监听 document 级事件。但必须满足三个硬条件才能避免冲突：
- 修饰键判断必须同时检查
e.ctrlKey和e.metaKey：macOS 用户按 Cmd+S，Windows 用户按 Ctrl+S，只判一个会漏掉一半用户 - 按键识别必须用
e.code === 'KeyS'，而不是e.key === 's'：前者对应物理按键位置，不受 CapsLock、输入法、IME 模式影响 - 必须主动跳过编辑态：通过
document.activeElement判断是否落在<input>、<textarea></textarea>或contenteditable元素内，是则 return
如何让快捷键逻辑不被模态框、富文本编辑器、第三方组件破坏
SaaS 后台常见「快捷键突然失灵」，往往不是监听器挂错了，而是上下文被隔离：
- Modal 组件常调用
focus()锁定内部首个可聚焦元素，导致document的keydown仍能收到事件，但业务逻辑误判为「非主界面状态」而静默退出 - 富文本编辑器（如 Slate、Tiptap）会接管所有键盘事件，
preventDefault()后不冒泡，document监听器收不到任何信号 - React/Vue 组件卸载时未清理监听器，旧快捷键逻辑残留，和新模块的同名组合键叠加触发两次
- 正确做法：快捷键逻辑必须与焦点栈、编辑模式、路由状态耦合。例如保存操作应检查
!isEditing && !hasUnsavedForm && routeIsMainPage三重条件
真正难的不是写监听器，而是让快捷键在「用户刚点开弹窗、正在输入、切换了 Tab、打开了 DevTools 控制台」这些瞬间依然可预测、不打断、有反馈。这要求快捷键系统本身就是一个状态机，而不是一堆散落的 if (e.code === 'KeyS') {...}。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
