tabindex 属性应写在可聚焦的 HTML 元素上，如 、、、 及 contenteditable="true" 的 ； 或 等不可聚焦元素即使设置 tabindex 也无效。
tabindex 属性写在哪？不是所有元素都支持
只有可聚焦的 HTML 元素才能响应 tabindex，比如 <input>、<button></button>、<select></select>、<textarea></textarea>，还有加了 contenteditable="true" 的 <div>。像 <code><span></span> 或纯文本 <p></p> 即使写了 tabindex="0"，按 Tab 也不会聚焦——浏览器直接跳过。
-
tabindex="-1"：元素不能通过 Tab 进入，但可用 JavaScript 调用.focus()主动聚焦（适合模态框关闭按钮、动态弹出项） -
tabindex="0"：按 DOM 顺序加入焦点流，最常用 -
tabindex="1"及正数：强行插队，破坏自然阅读顺序，屏幕阅读器可能混乱，不推荐
表单里多个 input 怎么控制 Tab 顺序？别硬写正数
默认情况下，<input> 按 HTML 源码顺序被 Tab 访问。如果视觉布局是右栏先填、左栏后填，但 HTML 是左→右写的，这时不要给每个 input 加 tabindex="1"、tabindex="2"……一来维护困难，二来会绕过其他可聚焦元素（比如中间的 <button></button>），三来在 Safari 中正数 tabindex 行为不稳定。
- 优先调整 HTML 结构顺序，让 DOM 顺序匹配逻辑顺序
- 必须调整时，只对少数关键控件设
tabindex="0"，其余保持默认（即不写tabindex） - 禁用字段（
disabled）自动从焦点流中移除，不用手动设tabindex="-1"
React/Vue 项目里 tabindex 失效？检查是否被框架劫持
某些 UI 库（如 Ant Design、Element Plus）或自定义 Hook 会主动调用 event.preventDefault() 或重置焦点逻辑，导致你写的 tabindex="0" 形同虚设。常见现象是：Tab 到某个 <input> 组件时直接跳过，或焦点卡在上一个元素不动。
- 用浏览器开发者工具检查该元素是否真有
tabindex属性（有些库会忽略传入的tabIndexprop） - 确认组件是否包裹了
role="group"或aria-hidden="true"父容器——这些会阻断焦点进入子元素 - React 中避免在函数组件顶层写
ref.current?.focus()，容易触发多次或时机错误；改用useEffect+!ref.current?.matches(':focus')判断
无障碍测试时 Tab 顺序错乱？重点查这三个地方
即使 tabindex 都写了，实际键盘导航仍可能跳步、回跳或遗漏，往往不是属性本身问题，而是结构干扰：
立即学习“前端免费学习笔记（深入）”；
- 隐藏元素没彻底移出流：
display: none或visibility: hidden的元素不会被 Tab 访问，但opacity: 0+position: absolute的还在焦点流里 - 重复 ID：两个
<input id="email">，部分屏幕阅读器只识别第一个，第二个永远无法通过标签<label for="email"></label>关联聚焦 - iFrame 内容：父页面的
tabindex不影响 iframe 里的表单，需单独处理其内部焦点逻辑
真实项目里，tabindex 最容易被当成“修 bug 的胶带”——哪块不顺就贴个 0，结果越贴越乱。它本质是声明“这个元素参与焦点管理”，而不是“我要控制 Tab 键走向”。顺序、语义、DOM 结构，才是根基。
