inert在动态加载时失效的根本原因是时机错位或API误用：DOM未就位、hydration未完成时设置，或使用setAttribute而非element.inert = true；新插入节点需手动设inert，且必须确保元素已挂载再赋值。
inert 属性在动态加载时失效，根本原因不是它“没起作用”，而是你很可能在 DOM 尚未就位、或框架 hydration 未完成时就设置了 inert，或者用了错误的 API 方式。
动态加载中 inert 失效的典型现象
页面刚渲染完，按钮仍可点击、Tab 键能聚焦到被“禁用”的区域、屏幕阅读器仍在播报内容——即使你写了 element.inert = true 或服务端输出了 inert 属性。这不是浏览器 bug，而是时机或方式错位：
- React/Vue SSR 渲染时 HTML 有
inert，但客户端 hydration 后 JS 没同步状态，触发prop mismatch，框架自动移除属性 - JS 在
DOMContentLoaded前执行，目标元素还没生成，document.getElementById('main')返回null - 用了
el.setAttribute('inert', '')，浏览器识别为字符串值，不触发 inert 行为 - 动态插入的子元素（如通过
innerHTML或appendChild添加）不受父级inert影响——inert只作用于已有子树，新插入节点需手动设inert或确保插入前父容器已生效
确保动态加载时 inert 真正生效的关键操作
不是“加了就完事”，而是要卡准时机、用对 API、覆盖新增节点：
anything-to-html
下载
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
- 服务端必须输出带
inert的 HTML（如<main inert></main>），客户端 hydration 后立即执行mainElement.inert = isModalOpen，保持状态一致 - 纯 JS 动态场景下，等元素真实挂载后再设：用
MutationObserver监听目标容器，或在requestIdleCallback/setTimeout(..., 0)中延迟赋值，避开渲染队列竞争 - 必须用
element.inert = true，永远不用setAttribute、toggleAttribute或inert="true" - 若后续动态插入新 DOM（如模态框内加载远程表单），插入后立刻对其父容器再执行一次
parent.inert = true——这会重新遍历并封禁新增子节点
为什么 pointer-events: none + tabindex="-1" 在动态加载里更危险
这种组合看似“兜底”，但在动态场景下反而放大问题：
立即学习“前端免费学习笔记（深入）”；
-
pointer-events: none不阻止focus()调用，JS 仍可能主动让新插入的input获得焦点，而用户看不见、Tab 也进不去，形成“焦点黑洞” -
tabindex="-1"只影响单个元素，新插入的button若没显式设tabindex，默认可聚焦，且无法被aria-hidden隐藏 - 辅助技术可能报出“元素可聚焦但
aria-disabled="true"”，违反 WCAG 4.1.2，而inert是原生语义，无此矛盾 - 滚动容器（如
overflow-y: auto的div）加pointer-events: none后无法滚动，但inert不影响滚动行为
真正容易被忽略的是：inert 不是“开关”，它是 DOM 子树的“存在性声明”——浏览器只在元素已存在于文档树、且 inert 属性被正确设置时，才将其从交互和可访问性上下文中剔除。动态加载时，你得先确保它“存在”，再让它“不存在”。
