inert 是浏览器原生的“存在性开关”，设为 true 时元素及子树彻底退出焦点流、事件链和可访问性树；它使元素既不可见（AT）、也不可触（键盘/鼠标）、更不可达（JS focus），且仅通过 HTMLElement.inert = true/false 控制。
inert 不是视觉隐藏开关，也不是事件拦截器——它是浏览器原生的“存在性开关”：一旦设为 true，该元素及其整个子树就从焦点流、事件冒泡链、可访问性树中彻底注销。
为什么 inert 能真正锁住 Tab 焦点
浏览器在计算 tab 键顺序（focus order）时，会跳过所有 inert 元素及其后代，无论它们是否设置了 tabindex、href 或 role="button"。这和 tabindex="-1" 或 aria-hidden="true" 有本质区别：
-
tabindex="-1"只让元素“不可自然进入”，但能被 JS 主动.focus()，且不阻止键盘事件穿透 -
aria-hidden="true"只影响屏幕阅读器，对键盘导航完全无感 -
inert是唯一让元素“既不可见（AT）、也不可触（键盘/鼠标）、更不可达（JS focus）”的原生机制
典型验证方式：打开 DevTools，按 Tab 键，观察焦点是否跳过 <main inert></main> 内部所有按钮、链接、输入框——它不会停，也不会卡住。
DOM 结构错误导致 inert 失效的常见场景
最常踩的坑不是 JS 控制逻辑写错，而是 HTML 层级本身就把模态框关进了“冷冻室”：
立即学习“前端免费学习笔记（深入）”；
- 把
<dialog>或<div class="toast">嵌套在<main inert>内部 → 整个弹窗也被冻结，无法获得焦点 - 用 React/Vue 渲染时，SSR 输出没带
inert属性，hydration 后仅靠el.inert = true触发 prop mismatch，部分浏览器会忽略首次赋值 - 移动端虚拟键盘弹出时，若
inert区域包含overflow-y: auto容器，可能触发滚动锚点偏移，焦点意外落到冻结区边缘元素上
正确结构必须是兄弟关系：<main inert> 和 <dialog> 都是 <body> 的直系子节点。
JS 动态控制 inert 的硬性规则
浏览器不认字符串值，也不响应属性操作——只认 HTMLElement.inert 这个布尔属性：
- ✅ 正确：
document.getElementById('main-content').inert = isModalOpen - ❌ 无效：
el.setAttribute('inert', '')、el.inert = 'true'（字符串会被转为true，但规范明确要求忽略非布尔值） - ❌ 危险：
el.removeAttribute('inert')—— 不恢复交互能力，必须显式设为false
切换时机也很关键：必须在 dialog.showModal() 调用前完成 inert = true，否则会出现短暂的焦点逃逸到背景区域。
旧浏览器兜底不能只靠 polyfill
wicg-inert polyfill 在 Safari 16.3 及更早版本里能模拟鼠标/键盘禁用，但它不修改可访问性树——屏幕阅读器仍可能读出被“冻结”的内容，违反 WCAG A 级要求。
真实项目中，降级策略需分层处理：
- 检测支持：
if (!('inert' in HTMLElement.prototype)) { /* 手动降级 */ } - 对容器设：
el.setAttribute('aria-hidden', 'true')+el.tabIndex = -1 - 递归遍历所有可聚焦子元素（
button, [href], input:not([type=hidden]), [tabindex]:not([tabindex="-1"])），逐个设tabIndex = -1并加pointer-events: none - 焦点劫持兜底：监听
focusin，若目标落在禁用区域内，立即focus()到模态框内首个可聚焦元素
真正容易被忽略的是：动态插入的新节点（比如 Vue 组件重渲染后挂载的按钮）polyfill 不会自动接管，得手动调用 inert.apply(el)；而 IE11 中，polyfill 甚至无法正确处理 Element.focus() 的返回值类型。
