tabindex="-1" 使元素可编程聚焦但不参与Tab顺序，常被误认为禁用焦点；tabindex="0" 安全纳入Tab流；正数tabindex是反模式；无tabindex时仅语义化控件默认可聚焦。
tabindex="-1" 能让元素获得焦点但不进 Tab 顺序
这是最常被误解的值。很多开发者以为 tabindex="-1" 是“禁用焦点”，其实它只是把元素从默认 Tab 流中移除，仍可通过 JavaScript 主动调用 .focus() 或点击触发焦点——这对模态框关闭按钮、下拉菜单项等需要键盘操作但不该出现在自然 Tab 序列里的元素非常关键。
常见错误现象：tabindex="-1" 后按 Tab 键跳过了该元素，于是误以为“失焦了”，结果发现键盘操作（比如按空格）没响应，其实是忘了绑定 keydown 事件或没处理 Enter/Space。
- 适用场景：下拉选项、Tooltip 触发按钮、Modal 的 Close 按钮
- 不能替代
disabled属性——tabindex="-1"不影响表单提交、不阻止点击、也不改变样式 - 配合
aria-hidden="true"要小心：如果视觉可见但aria-hidden="true"，屏幕阅读器会忽略，即使它能键盘聚焦
tabindex="0" 是最安全的“可聚焦但无序”方案
值为 0 表示元素按 DOM 顺序加入 Tab 流，不改变原有结构，也不需要手动管理索引。比写 tabindex="1" 或更高更可靠——因为负数和正数混用极易导致 Tab 顺序错乱，尤其在动态插入节点后。
使用场景：自定义组件如 <my-button></my-button>、卡片式区域、需要键盘导航的图表容器。
立即学习“前端免费学习笔记（深入）”；
- 它不会改变语义层级，但会让原本不可聚焦的元素（如
<div>）支持 <code>Tab进入和Enter触发 - 注意：必须同时提供键盘事件处理，否则用户 Tab 进去却无法操作，体验比不可聚焦还差
- 避免在文本段落内给每个
<span></span>加tabindex="0"——这会极大拖慢屏幕阅读器遍历速度 - 现代框架（React/Vue）中，动态渲染常导致 DOM 插入顺序和 tabindex 数值不一致，结果就是 Tab 顺序随机
- 无障碍测试工具（如 axe）会直接报
tabindex value is not zero or negative警告 - 唯一合理用法：极少数全键盘操作的单页应用，且所有交互区域由同一套焦点管理逻辑统一控制
-
contenteditable="true"的元素会自动获得tabindex="0"，无需额外设置 -
disabled的<button></button>或<input>会被自动排除出 Tab 流，哪怕写了tabindex="0" - 用 CSS
visibility: hidden或opacity: 0隐藏但未移除 DOM 的元素，若带tabindex，仍会进入 Tab 流——应改用display: none或aria-hidden="true"
tabindex 大于 0 是反模式，除非你完全掌控整个页面焦点流
写 tabindex="2" 或 tabindex="100" 看似能“优先聚焦”，实则破坏可访问性。浏览器会先按数值从小到大排一遍正数，再按 DOM 顺序排 0 和负数——一旦其他组件也随意设正数，Tab 顺序就彻底失控。
典型错误现象：首页 Banner 的 CTA 按钮设了 tabindex="1"，但用户 Tab 到一半突然跳回页脚链接，因为某个第三方评论组件悄悄加了 tabindex="3"。
没有 tabindex 时，哪些元素天然可聚焦？
不是所有 HTML 元素默认能进 Tab 流。只有语义化表单控件和链接才原生支持：比如 <a href></a>、<button></button>、<input>、<select></select>、<textarea></textarea>。而 <div>、<code><span></span>、<article></article> 这类容器默认不可聚焦，也不能通过键盘触发。
容易踩的坑是：只加了 role="button" 却漏掉 tabindex="0"，导致屏幕阅读器说“这是一个按钮”，但键盘用户根本 Tab 不进去。
