tabindex="-1"的核心作用是使元素可被脚本聚焦但不进入tab导航流；典型场景包括模态框、下拉容器、自定义tab行为组件及锚点定位；不可用tabindex="0"或省略，因前者破坏导航节奏，后者使非可聚焦元素无法focus()。

tabindex="-1" 的核心作用是：让一个元素能被 element.focus() 编程聚焦，但完全不进入键盘 Tab 导航流 —— 它不是“禁用焦点”，而是“隔离焦点入口”。

什么时候必须用 tabindex="-1"

典型场景是那些本身不可聚焦、又需要临时接管焦点的容器类元素：

• 模态对话框（<div role="dialog">）打开时，必须把焦点设进去，否则屏幕阅读器不会读、键盘操作会漏出到背景 <li>下拉菜单的根容器（<code><div class="dropdown">），内部有可聚焦项，但容器本身不该被 Tab 到 <li>自定义 Tab 键行为的组件（比如用 <code>ArrowDown 切换选项），需确保只有当前激活项在 Tab 流中，其余用 tabindex="-1" 排除
• 通过 id 链接跳转定位的锚点（如 <a href="#section1"></a>），目标 <section id="section1"></section> 若非语义化控件，需加 tabindex="-1" 才能被 focus() 滚入视口并触发读屏

为什么不能用 tabindex="0" 或省略

tabindex="0" 会让元素按 DOM 顺序加入 Tab 流，可能破坏预期导航节奏；省略则对 <div>、<code><span></span> 等非表单/非链接元素完全无效 —— 它们压根无法被 focus()。

• tabindex="0"：安全但“太开放”，Tab 用户会意外停在不该停的位置（比如空容器、装饰性区域）
• 无 tabindex：对 <div> 类元素，<code>element.focus() 直接静默失败，控制台无报错，但焦点没动
• tabindex="-1"：精准控制 —— 只响应脚本调用，不干扰用户自然 Tab 行为

常见错误与副作用

很多人以为 tabindex="-1" 会让元素“不可见”或“被忽略”，其实它完全不影响渲染、事件监听和语义：

• 不会触发 aria-hidden="true"，也不会等价于 display:none 或 visibility:hidden
• 仍能响应 focus、blur 事件，且 :focus CSS 伪类依然生效（需注意浏览器兼容性）
• 若在模态框内误给所有子项都设 tabindex="-1"，会导致整个框无法键盘操作 —— 必须至少保留一个可 Tab 的项（如关闭按钮）
• 动态插入的元素（如 JS 创建的弹窗）若忘了加 tabindex="-1"，focus() 就会失败，且不易排查

实际写法与检查要点

直接写在 HTML 中最稳妥，避免依赖 JS 注入时机：

<div id="modal" role="dialog" tabindex="-1">
  <button id="close-btn">Close</button>
  <p>Content</p>
</div>

• 打开弹窗后立即执行：document.getElementById('modal').focus()
• 检查是否生效：按 Tab 键确认焦点不落在该 <div> 上；再手动调用 <code>.focus()，看是否滚动到位、是否触发 focus 事件
• 别混用正数：tabindex="1" 是反模式，会打乱自然顺序，WCAG 不推荐
• 注意 SSR/ hydration 场景：服务端渲染时已带 tabindex="-1"，比客户端 JS 补更可靠

真正容易被忽略的是：它不改变视觉状态，也不阻止鼠标点击 —— 所以你得自己补 :focus-visible 样式，否则键盘用户根本看不到焦点在哪。