tabindex="0"应仅加在需键盘聚焦的非原生可聚焦元素上，如<div role="button">、<h3 role="tab">、自定义折叠面板标题等，须同步配role属性、keydown监听及:focus-visible样式；原生可聚焦元素（button、input等）无需添加，避免干扰焦点管理。
tabindex="0"该加在哪些元素上才真正有用
只加在本不该可聚焦、但业务又需要键盘进入的容器上，比如<div role="button">、<h3 role="tab">、自定义折叠面板标题。原生<button>、<a href>、<input>本来就进 Tab 流，加了反而可能干扰 SSR hydration 或 React 焦点管理。
常见错误是给纯展示文本或图标容器加tabindex="0"，结果屏幕阅读器多读一遍“无意义 div”，键盘用户多停一次却无事可做。
- 必须同步加
role属性（如role="button"），否则辅助技术读作“段落”或“无名容器” - 必须监听
keydown，对Enter和Space做响应；Space要e.preventDefault()，否则页面滚动 - CSS 中若移除了
outline，得补:focus-visible { outline: 2px solid #007bff; }，否则焦点不可见
tabindex="-1"不是隐藏开关，是聚焦入口
tabindex="-1"的唯一合法用途：让一个元素不能被 Tab 键碰到，但能被.focus()主动聚焦。模态框打开后聚焦第一个按钮、选项卡切换后聚焦内容区首项、代码编辑器激活时聚焦<textarea>——全靠它。
常见错误包括：
立即学习“前端免费学习笔记（深入）”；
- 给整个
tabpanel容器设tabindex="-1"，结果.focus()落在空容器上，用户按 Tab 还是跳到页面其他地方 - 目标元素还没渲染完成（比如异步加载的表单字段）就调
.focus()，DOM 找不到，静默失败 - 聚焦后元素被
overflow: hidden或position: absolute遮挡，没配element.scrollIntoView({ block: 'nearest' })，用户看不见焦点在哪
为什么永远不要用 tabindex="1"
写tabindex="1"不会让它变成“第一个被 Tab 到的元素”，只会把它塞进所有正数里排最小——但多个tabindex="1"仍按 DOM 顺序走，和没设一样。更糟的是，一旦混入tabindex="0"的链接或按钮，Tab 流变成“正数 → 0 值 → 其他”，完全失控。
真实影响包括：
- 移动端 Safari 直接无视大部分
tabindex="0"，tabindex="1"更无效，还可能触发警告 - React/Vue 动态插入新组件后，硬编码的正数无法重算，焦点跳转错乱
- 屏幕阅读器把第一个
tabindex="1"当作逻辑起点，如果它是页脚的“导出按钮”，用户一进页面就听到“导出”，主编辑区上下文全丢
Grid/Flex 布局中焦点顺序和视觉顺序不一致怎么办
tabindex="0"不会改变元素在 DOM 中的位置，也不会让它“跳到第一个”。它只表示：这个原本不可聚焦的<div>或<article>可以被 Tab 键选中，并按 HTML 源码顺序进入焦点流——哪怕它在视觉上被grid-template-areas或order移到了右下角。
如果你的网格项是动态插入（比如 React 中 map 渲染），DOM 顺序可能和预期不同，此时必须检查实际生成的 HTML 结构。
- 只对有交互意图的网格项加
tabindex="0"，比如可点击的卡片、可展开的面板标题 - 必须同步加
role，如role="button"或role="region"，否则屏幕阅读器无法识别语义 - 避免给纯展示型网格项（如头像容器、图标
<span>）加tabindex="0"，这会增加无意义的焦点停顿 - 如果网格项包裹了原生可聚焦元素（如内部有
<button>），外部容器不该再设tabindex="0"，否则造成双重焦点
scrollIntoView是否执行、role是否匹配交互类型、focus()后是否被遮挡——这些环节任何一个断掉，键盘用户就会卡住。 
