tabindex="0"仅使非可聚焦元素按dom顺序加入tab流，不改变视觉顺序；tabindex="-1"专用于编程聚焦；正整数tabindex应禁用，wcag明确反对；原生可聚焦元素无需额外tabindex。
tabindex="0" 不改变 DOM 顺序，只补可聚焦能力
很多人加 tabindex="0" 是为了“让 div 可 Tab 到”，但误以为它能按视觉位置重排焦点流。实际它只做一件事：把原本不可聚焦的元素（如 div、span）按当前 HTML 源码顺序纳入 Tab 流——哪怕这个 div 在 CSS Grid 里被 order 推到右下角，焦点仍会先停在它前面的、DOM 更靠前的元素上。
常见错误现象：
- 网格项加了
tabindex="0"，但焦点顺序和视觉布局不一致 - React/Vue 动态渲染后，Tab 顺序和开发时预想的不一样
根本原因是：浏览器只读 DOM 树，不读 CSS 布局。解决办法不是调 tabindex，而是检查生成后的 HTML 结构是否符合语义流。如果必须调整顺序，优先重构 DOM 位置，而不是用 tabindex 补救。
tabindex="-1" 是编程聚焦的硬性前提，不是“隐藏开关”
设 tabindex="-1" 的元素不会出现在 Tab 键循环里，但它也不是“禁用”或“不可见”。它的唯一作用是：让 .focus() 调用生效。没设这个，对非原生可聚焦元素（比如 div 里的 input）调 .focus() 会静默失败或被忽略。
典型使用场景：
- 模态框打开后，立即聚焦到第一个
button或input—— 目标元素必须提前带tabindex="-1" - 折叠面板展开后，焦点要落到新内容首项，不能留在触发按钮上
- 选项卡切换后，焦点需移进
role="tabpanel"内部首个可操作子元素
注意：tabindex="-1" 不等于视觉隐藏。仅设它，若元素还用了 opacity: 0 或 position: absolute; left: -9999px，仍可能被 Tab 到 —— 此时必须配合 inert 或显式移除该属性。
正整数 tabindex（如 "1", "2"）在任何场景下都应禁用
设 tabindex="1" 并不能让元素“第一个被 Tab 到”，只会把它和所有其他正数项一起提到整个 Tab 流最前面，再按数值升序排。结果往往是页脚的“导出”按钮比主编辑区还早被聚焦，键盘用户一进页面就听到“导出”，完全丢失上下文。
更严重的问题来自动态场景：
- 多个组件复用时，不同实例的
tabindex="1"按 DOM 插入顺序排，今天从上到下，明天从左到右 - SSR 渲染时服务端与客户端生成的正数值不一致，触发 hydration 警告
- 屏幕阅读器依赖文档流理解逻辑结构，人为插队会让视障用户迷失路径
WCAG 明确反对使用正整数 tabindex。真要控制焦点入口，靠的是 DOM 位置 + tabindex="-1" + JS 主动聚焦，而不是给一堆元素硬编号。
原生可聚焦元素永远优于自定义 + tabindex 组合
button、a[href]、input 这些原生元素默认等效于 tabindex="0"，自带聚焦、Enter/Space 触发、disabled 语义、角色支持。给它们加 tabindex="0" 是冗余；加 tabindex="-1" 是主动踢出 Tab 流；加正整数则直接破坏流。
真正需要 tabindex 的，只有两类：
- 有交互意图但非原生的容器，比如
<div role="button"> —— 必须配 <code>tabindex="0"+role+keydown监听 +:focus-visible - 需要 JS 精准接管焦点的目标节点，比如模态框内首个输入框 —— 必须提前设
tabindex="-1"
最容易被忽略的细节是：焦点接管必须发生在 DOM 渲染完成之后。异步加载的内容，.focus() 调用得包一层 requestAnimationFrame 或 setTimeout(..., 0)，否则目标元素还没挂载，调用无效。
