tabindex仅应使用0和-1：0使元素进入Tab流，-1用于编程聚焦；原生控件无需设置，伪控件需同时配role、keydown监听和:focus-visible样式；正整数会破坏焦点链。
tabindex 不是用来给元素“排号”的，复杂动态表单里硬塞 tabindex="1"、tabindex="2" 会直接破坏焦点链——浏览器只认最小正整数，其余忽略；DOM 插入新字段后顺序全乱；SSR 渲染还可能触发 hydration 警告。真正可用的只有 tabindex="0" 和 tabindex="-1"，且必须配合语义与 JS 控制。
原生控件别碰 tabindex，伪控件才需要介入
按钮、输入框、带 href 的链接这些原生可聚焦元素，默认就等效于 tabindex="0"。给它们加 tabindex="0" 是冗余，加 tabindex="-1" 是主动踢出 Tab 流——比如一个 <button> 被设了 tabindex="-1"，键盘用户就再也 Tab 不到了。
真正要加 tabindex 的，是那些用 <div role="button"> 或 <span role="checkbox"> 模拟的控件：
- 必须加
tabindex="0"，否则无法进入 Tab 流 - 必须同步加
role属性，否则屏幕阅读器读不出功能 - 必须监听
keydown，对Enter和空格键（' '）做相同响应，并调用preventDefault()防止空格触发滚动 - 必须提供
:focus-visible样式，否则键盘用户看不到焦点在哪
tabindex="-1" 不是隐藏开关，是编程聚焦的唯一入口
设成 -1 后，元素不能被 Tab 键到达，但能被 .focus() 主动聚焦——这是动态表单里控制流转时机的核心机制。
立即学习“前端免费学习笔记（深入）”；
典型场景：
- 模态框打开后，立即聚焦到第一个可操作按钮（它得有
tabindex="-1"，否则.focus()在非原生元素上会静默失败） - 折叠面板展开后，焦点要移到新暴露的首项，而不是留在触发按钮上
- 地址字段组填完后，按 Tab 不该跳进下一个
input，而是由 JS 判断逻辑，调用document.getElementById('help-btn').focus()跳到帮助按钮（该按钮需tabindex="-1"）
注意：移动端 Safari 在未触发用户手势前，.focus() 对非原生元素会静默失败；display: none 或 visibility: hidden 的元素即使有 tabindex="-1"，.focus() 也会失败。
多个 tabindex="0" 共存时，Tab 流会按 DOM 顺序线性走，不看语义层级
比如你在城市字段后面插入一个 <button tabindex="0">?，用户按 Tab 就会从城市跳进这个问号按钮，再按一次却可能跳到邮编字段——因为浏览器只按 HTML 源码顺序遍历所有 tabindex="0" 元素，中间漏掉的字段根本没机会被聚焦。
更可靠的做法是：
- 把这类辅助按钮设为
tabindex="-1" - 在上一字段（如城市
input）的blur或keydown事件里，用 JS 显式调用.focus() - 如果必须让辅助按钮参与主 Tab 流，优先把它放在 DOM 中逻辑位置该在的地方（比如紧邻城市字段），而不是靠
tabindex强行插队
动态插入/销毁节点时，tabindex 必须随生命周期同步管理
Vue/React 中用 v-if 或 && 条件渲染的元素，DOM 节点不存在时，tabindex 设置无效；节点挂载后，必须确保 tabindex 值已正确写入。
常见坑点：
- 用
opacity: 0或position: absolute; left: -9999px隐藏的元素，仍会被 Tab 到——得配tabindex="-1"或现代inert属性 -
aria-hidden="true"不影响tabindex行为，若同时存在，需显式设tabindex="-1" - 表格行内菜单因
overflow: hidden或position: absolute脱离 DOM 结构，导致 Tab 流断裂——此时不能靠tabindex修复，得用焦点管理器（focus manager）在关键节点插入不可见button占位，并监听focus事件手动委托
真正难的不是选对某个 tabindex 值，而是理解：焦点链是一条线性路径，任何试图用正整数“插队”的做法，都会在字段增删、组件复用或 SSR 场景下立刻暴露问题。
