Esc键在多层Modal中“只关最外层”或“不响应”，本质是UI框架、浏览器焦点管理与自定义键盘监听的层级冲突；需检查焦点状态、事件冒泡控制、监听器注册顺序及是否启用中心化Esc调度。
esc 键在多层 modal 弹窗中“只关最外层”或“完全不响应”，本质不是按键失灵，而是系统与前端框架对 esc 事件的捕获、拦截和传播逻辑存在层级冲突。它既非硬件问题，也非 sublime 那类内核硬编码行为，而是 ui 框架（如 react、vue、ant design、element plus）、浏览器原生 focus 管理、以及自定义键盘监听三者叠加作用的结果。
明确 Esc 事件的默认行为边界
浏览器本身对 Esc 没有全局关闭弹窗的强制逻辑。它的原始语义只是触发 keydown 事件，是否响应、响应谁、是否阻止冒泡，全由 JS 主动控制：
- 原生
<dialog>元素：Esc 默认关闭自身，且会自动event.stopPropagation()，不透传给外层 - React 组件（如 AntD Modal）：通常在
useEffect中监听document.addEventListener('keydown', ...)，并手动判断event.key === 'Escape' - 若多个 Modal 同时挂载，且都监听了 document 级 Esc，则后注册的监听器可能先执行（取决于挂载顺序），造成“抢响应”现象
- 如果某层 Modal 调用了
event.preventDefault()或event.stopImmediatePropagation()，则内层 Modal 就永远收不到 Esc
检查 Modal 的焦点与 Trap Focus 实现
现代 Modal 普遍启用焦点陷阱（Focus Trap），即强制键盘 Tab 流只在弹窗内部循环。但很多实现会忽略 Esc 的传播路径：
- 确认当前激活的 Modal 是否真正获得了
document.activeElement（可在控制台运行document.activeElement查看） - 若焦点不在该 Modal 内部（比如卡在 body 或 input 失焦状态），Esc 监听可能失效——因为部分框架只在 Modal 获得焦点后才启用 Esc 响应
- 检查所用 UI 库文档：Ant Design 的
maskClosable和keyboard属性是否同时为true；Element Plus 的close-on-press-escape是否被父级覆盖 - 自定义 Modal 若用
createPortal渲染到document.body，需确保其事件监听器未被其他同级 Portal 覆盖
统一 Esc 响应调度器（推荐方案）
避免各 Modal 各自监听 document，改用中心化管理：
- 维护一个栈式 Modal 列表（例如
modalStack = [modalA, modalB, modalC]），每次打开/关闭时 push/pop - 全局只注册一个
document.addEventListener('keydown', e => { if (e.key === 'Escape') { const top = modalStack[modalStack.length - 1]; top?.handleEscape?.(); } }) - 每个 Modal 实例暴露
handleEscape方法，负责自身关闭逻辑，并决定是否继续向下传递（例如仅关闭当前层，不 pop 栈） - 配合
useEffect清理函数，在组件卸载时从栈中移除自己，防止内存泄漏或误触发
排查第三方脚本干扰
某些工具库或监控 SDK（如 Sentry、FullStory、Clarity）会劫持全局事件以采集用户行为：
- 临时禁用浏览器扩展（尤其键盘增强、快捷键管理类），再测试 Esc 行为
- 在开发者工具 → Application → Service Workers 页面，点击 “Unregister” 清除可能缓存的干扰脚本
- 使用无痕窗口启动页面，排除插件与本地存储影响
- 检查是否有全局
document.onkeydown = ...覆盖了默认行为（控制台执行getEventListeners(document).keydown可查看所有监听器）
