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

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

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

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

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

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

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

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

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


htmlppt.skill
把任意文章或文档内容转换成精美的全屏翻页 HTML 演示文件（幻灯片风格）。当用户发来一篇文章、文档链接、Markdown 内容、或粘贴的文本，并且希望生成演示用的 HTML 时触发。支持任意内容来源：iWiki 链接、KM 链接、本地文件路径、直接粘贴的文本。生成的 HTML 文件保存到本地工作区，并通过企微直接发送给用户。触发词示例：帮我把这篇文章做成PPT、转成演示文档、生成HTML幻灯片、做个演示、转成可以演示的格式、article to deck、make a slide。
下载
• 它把
  或 强行塞进 Tab 序列，用户可能意外停在空容器、装饰区甚至隐藏区域
• 若多个自定义组件都用 tabindex="0"，Tab 流就变成“所有 div 都排队”，失去语义优先级
• 省略 tabindex 对
  类元素直接导致 .focus() 失败——控制台无报错，但焦点没动，极难排查
• tabindex="0" 必须配套 role（如 role="button"）、键盘事件监听（keydown 判断 Enter/ ）、以及 :focus-visible 样式，缺一不可

正整数 tabindex 是危险信号

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

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

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