原生表单控件默认参与Tab导航，无需设置tabindex；显式设正数会破坏顺序逻辑，tabindex="-1"仅禁用自然聚焦但支持脚本聚焦，应配合aria属性使用；优先通过HTML结构或CSS order调整视觉与语义顺序。
原生表单控件（<input>、<button></button>、<select></select>、<textarea></textarea>）默认就参与 Tab 导航，无需任何 tabindex 设置——加了反而容易出问题。
为什么给 <input> 加 tabindex="1" 是错的
浏览器对原生可聚焦元素的默认行为等价于 tabindex="0"，它们天然按 HTML 源码顺序进入 Tab 流。一旦显式设为正数（如 tabindex="1"），就会被强制排到所有默认元素之前，但多个 tabindex="1" 之间仍按 DOM 顺序走，结果既没真正控制“第一”，又破坏了线性逻辑。
- 用户按 Tab 时，焦点可能先跳到页脚的按钮，再回到表头的输入框
- 屏幕阅读器会把
tabindex="1"元素当作导航起点，但视觉位置完全不匹配 - Safari 在 iframe 或动态渲染场景下常静默忽略正数
tabindex - React/Vue 重渲染后 DOM 顺序变化，硬编码的
tabindex="2"会让焦点停在错误字段
tabindex="-1" 不是禁用，而是保留脚本聚焦能力
设 tabindex="-1" 的元素不会出现在自然 Tab 流中，但能被 element.focus() 主动聚焦——这是校验失败后跳转焦点、模态框打开时锁定焦点的标准做法。
- 别用它替代
disabled：禁用的<input disabled>自动退出 Tab 流，更干净可靠 - 别只写
tabindex="-1"就完事：若需隐藏语义，得补aria-hidden="true"；若需屏蔽交互，得加aria-disabled="true"和pointer-events: none - 动态设置后记得同步清理：比如模态框关闭时，要把触发按钮的
tabindex="-1"改回原来值，否则下次打不开
视觉顺序 ≠ DOM 顺序时，优先重构 HTML 或用 CSS order
如果设计要求“右栏先填、左栏后填”，但 HTML 是左→右写的，不要给每个 <input> 加 tabindex="1"、tabindex="2"。这种写法会让中间的 <button></button> 被跳过，且无法响应屏幕阅读器的线性阅读流。
立即学习“前端免费学习笔记（深入）”；
- 用 Flex/Grid 的
order属性调整视觉位置，保留 HTML 语义顺序 - 必要时拆分结构：把右栏字段提前写在左栏之前，哪怕 CSS 让它显示在右侧
- 若必须 JS 动态插入字段，插入后立即调用
element.focus()并配scrollIntoView()，而不是依赖tabindex排序
真正需要干预 Tab 顺序的场景极少：只有当 DOM 顺序确实无法匹配业务逻辑，且不能通过结构调整解决时，才考虑 tabindex="0" 补位或 tabindex="-1" 临时接管——而永远不该出现 tabindex="99" 这类“最大值思维”写法。
