tabindex="0"仅解决可聚焦问题，不解决该不该聚焦或聚焦后是否合理；滥用会导致语义混乱、Tab顺序断裂、键盘无响应及移动端兼容问题。

tabindex=0 不是万能方案，它只解决“可聚焦”问题，不解决“该不该聚焦”或“聚焦后是否合理”。 很多开发者加了 tabindex="0" 就以为交互闭环了，结果键盘用户在页面里按 Tab 键时卡在一堆无意义的 div 或 img 上，反而更难操作。

为什么 tabindex="0" 不能乱用

它把一个原本不可聚焦的元素强行塞进自然焦点流，但浏览器不会判断这个元素有没有交互逻辑、是否需要键盘响应、是否有 role 或事件绑定。常见后果包括：

• 屏幕阅读器把纯展示 div 当成可操作控件读出来，造成语义混乱
• Tab 键顺序被大量 tabindex="0" 元素打断，用户要按十几次才能到达主按钮
• 没有配套的 onkeydown 或 role，键盘按下去没反应，只留下一个孤零零的焦点框
• 移动端 Safari 对 tabindex="0" 的支持不稳定，某些 img 或 span 加了也不触发 :focus

哪些场景真该用 tabindex="0"

不是“想让它亮一下就加”，而是满足以下任一条件时才考虑：

• 自定义控件有明确交互行为（如 div 模拟按钮），且已绑定 onclick 和 onkeydown（含 Enter/Space）
• 非交互元素需临时获得焦点用于 JS 控制（如 details 展开后聚焦到第一个子项）
• 图像需支持键盘导航并提供替代操作（如图库中用方向键切换，此时 tabindex="0" + role="button" + aria-label 缺一不可）
• 组件内部需要保持 DOM 顺序但视觉位置浮动（如侧边栏菜单项用 position: absolute，仍需按源码顺序聚焦）

tabindex="-1" 比 "0" 更常用的实际理由

多数时候你真正需要的不是“让元素进 Tab 流”，而是“让元素能被 JS 聚焦”。比如模态框打开后把焦点移到第一个输入框、表单验证失败后跳转到错误字段——这些都不该靠 tabindex="0" 实现，因为：

• tabindex="-1" 元素不会出现在 Tab 键序列里，不干扰用户原有导航习惯
• 调用 element.focus() 后，它能立刻获得焦点，且焦点离开后自动释放（不像 tabindex="0" 可能被反复 Tab 进来）
• 配合 inert 或 aria-hidden 使用时更安全，避免焦点落入隐藏区域
• 现代框架（React/Vue）中管理焦点逻辑时，tabindex="-1" 是默认推荐值，比如 ref.current?.focus() 前通常先确保目标有 tabindex="-1"

自然焦点顺序比 tabindex 数值更重要

用户按 Tab 键时，依赖的是文档源码顺序（source order），不是视觉顺序或 CSS 排列。这意味着：

• 浮动、Flex 或 Grid 改变视觉位置，不影响 tabindex="0" 元素的 Tab 顺序
• 如果主操作区在 HTML 末尾，但视觉上在顶部，加了 tabindex="0" 会让用户先 Tab 到页脚再回到顶部，体验断裂
• 真正合理的做法是调整 HTML 结构本身：把关键交互元素提前写入 DOM，而不是靠 tabindex="1" 强行提权（这已被 W3C 明确列为反模式）
• 用 document.activeElement 检查当前焦点位置，比盲目加 tabindex 更能暴露结构问题

最常被忽略的一点：焦点管理不是加个属性就完事，它必须和 role、aria-*、键盘事件处理、视觉反馈样式形成闭环。一个只有 tabindex="0" 的 div，就像给自行车装了发动机却没配刹车和方向盘。