原生表单控件（input、button、select、textarea）默认参与Tab导航，无需设tabindex；加tabindex="1"会强制前置、破坏DOM顺序、导致Safari兼容问题及动态渲染焦点错乱，仅非原生元素需tabindex="0"并配role与键盘事件。
原生表单控件（input、button、select、textarea）默认就参与 Tab 导航，**不需要手动设 tabindex**；强行加正数（如 tabindex="1"）反而破坏顺序、引发兼容性问题。
为什么给 input 加 tabindex="1" 是错的
浏览器默认按 HTML 源码顺序聚焦，这和视觉布局一致，也符合屏幕阅读器逻辑。加 tabindex="1" 会把该控件插到整个页面所有默认可聚焦元素之前——哪怕它在 DOM 最底下，用户一按 Tab 就跳到这儿，中间的按钮、链接全被跳过。
- Safari 对正数
tabindex支持不稳定，尤其在 iframe 或动态渲染后常静默失效 - React/Vue 中组件重渲染可能改变 DOM 插入顺序，但
tabindex="2"还卡在旧位置，焦点跳到错误字段 - 多个控件设相同正数（如都为
tabindex="1"），仍按 DOM 顺序走，不是“并列第一”，白配 -
disabled的input自动退出 Tab 流，比手动设tabindex="-1"更干净可靠
什么情况下才该用 tabindex="0"
只用于非原生可聚焦元素，比如用 div 模拟的按钮、下拉触发器、自定义复选框容器等。它不改变顺序，只是“申请加入”默认 Tab 流，排队位置完全由 DOM 位置决定。
- 必须同步加语义属性，例如
<div role="button" tabindex="0">，否则屏幕阅读器读作“div” - 必须监听
keydown，对Enter和Space做相同响应，并对Space调用e.preventDefault() - CSS 若移除了 outline，得补
:focus-visible { outline: 2px solid #007bff; }，否则键盘用户看不见焦点 - 别给
label加tabindex="0"——它本身不可聚焦，应通过for或嵌套绑定到对应input
表格里怎么让整行可 Tab 切换
直接给 <td> 或 <tr> 加 tabindex="0" 是可行起点，但要注意：iOS Safari 默认不支持 <tr> 聚焦，得用降级方案。
立即学习“前端免费学习笔记（深入）”；
- 给
<tr tabindex="0">加:focus-within样式控制高亮，别只靠:focus——因为焦点实际落在内部按钮上时，整行也需保持状态 - 操作按钮（如编辑、删除）必须是原生
<button>，且作为<tr>的最后一个子元素，确保 Tab 进入行后，再按一次 Tab 就落到它上面 - 移动端 Safari 不认
<tr tabindex="0">，得在第一行加一个隐藏的、带tabindex="0"的代理按钮，初始化后主动.focus()，绕过 Safari 的聚焦限制 - 若需方向键导航（上下左右切换单元格），必须拦截
keydown并手动.focus()目标控件，tabindex本身不提供这个能力
真正影响 Tab 顺序的，只有两件事：DOM 书写顺序，和是否为原生可聚焦元素。所有花哨的 tabindex 数值，都是在对抗这个基础规则——多数时候，改 HTML 结构比硬编码数值更可靠、更少出 bug。
