tabindex="-1"使元素可编程聚焦但不进入Tab流，tabindex="0"则按DOM顺序自然加入Tab流；二者设计意图与逻辑截然不同，不可混淆。

tabindex="-1"和tabindex="0"行为完全不同

两者不是“程度差异”，而是设计意图和运行逻辑的彻底区分：tabindex="-1"让元素**可编程聚焦但不进 Tab 流**；tabindex="0"让元素**按 DOM 顺序自然加入 Tab 流**。混淆它们会导致键盘用户卡在不该停的位置，或脚本调用 .focus() 静默失败。

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

典型场景是那些需要被脚本主动聚焦、但又不该出现在用户自然 Tab 导航路径里的元素：

• 模态框容器（<div role="dialog">）打开时，需立即 <code>.focus() 进去，但它本身不是操作项
• 下拉菜单的根容器（<div class="dropdown">），内部有按钮/选项，但容器不该被 Tab 到 <li>锚点定位目标（如 <code><section id="faq"></section>），非语义化元素加 tabindex="-1" 才能 .focus() 滚入视口并触发读屏
• 关闭按钮（<button aria-label="Close"></button>）设为 tabindex="-1" 后，仍可点击、可空格/回车触发，但不会打断 Tab 节奏

常见错误：给整个弹窗所有子元素都加 tabindex="-1"，结果没有一个能被 Tab 到，键盘操作完全失效。

为什么 tabindex="0" 不能替代 "-1"

tabindex="0" 看似“安全”，但在动态焦点管理中会破坏预期节奏：


Wechat Article Html
将 Markdown 文章转换为微信公众号兼容的纯 HTML 格式。当用户要求"转成微信格式"、"生成公众号文章 HTML"、"排版到微信草稿箱"、"微信粘贴格式"时触发。输出带内联样式的纯 HTML，微信编辑器可直接渲染，无需额外适配。支持标题、段落、列表、粗体、行内代码、表格、引用块、代码块、配图的完整转换。
下载

立即学习“前端免费学习笔记（深入）”；

• 它把 <div> 或 <code><span></span> 强行塞进 Tab 序列，用户可能意外停在空容器、装饰区甚至隐藏区域
• 若多个自定义组件都用 tabindex="0"，Tab 流就变成“所有 div 都排队”，失去语义优先级
• 省略 tabindex 对 <div> 类元素直接导致 <code>.focus() 失败——控制台无报错，但焦点没动，极难排查
• tabindex="0" 必须配套 role（如 role="button"）、键盘事件监听（keydown 判断 Enter/ ）、以及 :focus-visible 样式，缺一不可

正整数 tabindex 是危险信号

写 tabindex="1" 或 tabindex="5" 不会让元素“更优先”，反而大概率引发焦点流断裂：

• 浏览器先排所有正数（升序），再排 0 和 -1（按 DOM 顺序）；原生可聚焦元素（<button></button>、<a></a>）默认无 tabindex，会被挤到最后
• 动态插入节点后，正数必须全局重算，否则顺序错乱；SSR 渲染时客户端与服务端值不一致，还会触发 hydration 警告
• 多个组件库各自设正数，Tab 流立刻失控——你设了 tabindex="1"，第三方弹窗也设了 tabindex="1"，结果两个都变成“第一个”

真正容易被忽略的是：tabindex="-1" 不等于视觉隐藏，也不阻止点击或表单提交；它只隔离 Tab 入口。要禁用交互，该用 disabled 或 inert，而不是靠 tabindex 假装控制。