tabindex 仅控制元素是否可聚焦及在 Tab 流中的相对位置，不用于编号排序；tabindex="0" 最安全，使元素按 DOM 顺序加入流但需手动绑定交互与语义角色；tabindex="-1" 用于编程聚焦，非隐藏开关；禁用正整数以避免流断裂与可访问性问题。
tabindex 不是用来“给元素编号排顺序”的属性，它只决定单个元素是否可被聚焦、能否进入 Tab 导航流、以及在流中相对 DOM 顺序的位置——三者由值的正负零严格区分。
tabindex="0" 是最常用也最安全的启用方式
给 <div>、<span> 或自定义组件加 tabindex="0"，能让它按 HTML 源码顺序自然加入 Tab 流。但注意：
- 它不自动绑定交互行为：比如
<div tabindex="0">点击我</div>获得焦点后，按空格或回车不会触发任何动作，必须手动监听keydown并判断event.key === 'Enter'或' ' - 语义缺失会导致辅助技术误读：应同步添加
role="button"（或其他匹配语义的角色），否则屏幕阅读器可能只读出“div”，而非“按钮” - CSS 焦点样式不可少：务必配
:focus-visible或:focus样式，否则键盘用户看不到当前焦点在哪
tabindex="-1" 用于编程聚焦，不是隐藏元素的开关
设为 -1 后，元素无法通过 Tab 键到达，但能用 JavaScript 调用 .focus() 主动聚焦——这正是模态框、折叠面板、下拉菜单等动态组件的核心操作点：
- 模态框打开时，立即对第一个可操作元素（如确认按钮）调用
.focus()，前提是该元素有tabindex="-1"（否则默认不可聚焦） - Accordion 展开后，把焦点移到新暴露的首项，而不是留在触发按钮上
- 关闭弹层后，焦点应回退到触发它的元素（比如原“编辑”按钮），可用
document.activeElement记录或传参保存 -
tabindex="-1"不等于视觉隐藏：仅设它，元素仍可能被 Tab 到（如果 CSS 用opacity: 0或position: absolute; left: -9999px隐藏），此时需配合inert属性（现代浏览器支持）或显式移除tabindex
绝对不要用正整数 tabindex（如 1、2、5）
设 tabindex="1" 看似“想让它第一个被 Tab 到”，实际会引发不可控问题：
立即学习“前端免费学习笔记（深入）”；
- 浏览器只看是否 > 0，不严格按数值排序；多个正数时，它按数值升序排列，但若中间漏掉某个值（比如只有 1 和 3），2 不会自动补位
- 原生可聚焦元素（
<button>、<a>）默认无tabindex，它们会被挤到最后——你设了tabindex="1"的<div>确实跑前面了，但整个 Tab 流就断层了 - 组件复用或动态插入内容时，正整数必须全局重算，极易出错；SSR 渲染时客户端与服务端
tabindex值不一致，还会触发 hydration 警告 - 屏幕阅读器依赖 DOM 顺序理解上下文，强行插队会让视障用户迷失逻辑路径
禁用/隐藏元素的 tabindex 处理常被忽略
很多人以为设了 disabled 或 display: none 就万事大吉，其实边界情况很多：
-
<button disabled>自动脱离 Tab 流，无需额外处理tabindex -
aria-hidden="true"不影响tabindex行为：如果同时存在，必须显式加tabindex="-1"或删掉tabindex - 仅靠
visibility: hidden或opacity: 0隐藏的元素，仍可能被 Tab 到——必须配tabindex="-1"或inert - React/Vue 中条件渲染（如
v-if或{{ show }} && <Modal>）会导致 DOM 节点销毁重建，焦点状态丢失；优先用display: none保持节点存在，或在卸载前记录document.activeElement
真正难的不是写对某个 tabindex 值，而是理解：焦点流是一条线性、不可跳变的路径，DOM 顺序就是默认规则。任何试图用正整数“插队”的做法，都在对抗这个底层逻辑。
