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，就像给自行车装了发动机却没配刹车和方向盘。
