tabindex="0"该加在哪些元素上才真正有用
只加在本不该可聚焦、但业务又需要键盘进入的容器上，比如<div role="button">、<code><h3 role="tab"></h3>、自定义折叠面板标题。原生<button></button>、<a></a>、<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></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 值 → 其他”，完全失控。
浏览器对正整数的处理逻辑是：所有 > 0 的值优先于默认可聚焦元素，再按数值升序排列；但多个相同值（如都写tabindex="1"）时，仍按 DOM 顺序聚焦——你以为排好了，其实没排。
- SSR 渲染时，服务端生成的顺序和客户端 hydration 后的
tabindex值极易不一致，引发焦点错位警告 - 组件复用或动态插入新元素后，正整数必须全局重算，几乎不可维护
- 屏幕阅读器依赖文档流理解上下文，强行把页脚按钮塞到第一个位置，等于剥夺其结构感知能力
表格行怎么加 tabindex 才不翻车
<tr>默认不可聚焦，加<code>tabindex="1"或tabindex="-1"都没用——前者打乱全局顺序，后者不进 Tab 流。唯一安全方式是tabindex="0"，让它按 DOM 位置自然进入 Tab 流。
操作按钮必须作为该行最后一个子元素，且必须是原生<button></button>（默认可聚焦、语义明确、自动响应 Enter/Space）。若用<div role="button">替代，则需同步加<code>tabindex="0"、role="button"、keydown监听。
- 动态显示的操作菜单建议用
:focus-within控制可见性，而非仅靠tabindex="0"
- 若菜单是 JS 动态插入的，
<tr>获得焦点后需立即对按钮调<code>.focus()，此时按钮必须带tabindex="-1"（否则.focus()静默失败）
- 移动端 Safari 对非原生元素的
.focus()有手势限制，需提前验证是否触发了用户交互
复杂点在于：tabindex不是独立生效的属性，它和role、aria-*、事件监听、CSS 焦点样式、DOM 插入时机、hydration 状态全部耦合。漏掉其中任一环，键盘用户就会卡住，而你本地测试时可能完全察觉不到。
<tr>默认不可聚焦，加<code>tabindex="1"或tabindex="-1"都没用——前者打乱全局顺序，后者不进 Tab 流。唯一安全方式是tabindex="0"，让它按 DOM 位置自然进入 Tab 流。
操作按钮必须作为该行最后一个子元素，且必须是原生<button></button>（默认可聚焦、语义明确、自动响应 Enter/Space）。若用<div role="button">替代，则需同步加<code>tabindex="0"、role="button"、keydown监听。
- 动态显示的操作菜单建议用
:focus-within控制可见性，而非仅靠tabindex="0" - 若菜单是 JS 动态插入的，
<tr>获得焦点后需立即对按钮调<code>.focus()，此时按钮必须带tabindex="-1"（否则.focus()静默失败） - 移动端 Safari 对非原生元素的
.focus()有手势限制，需提前验证是否触发了用户交互
复杂点在于：
tabindex不是独立生效的属性，它和role、aria-*、事件监听、CSS 焦点样式、DOM 插入时机、hydration 状态全部耦合。漏掉其中任一环，键盘用户就会卡住，而你本地测试时可能完全察觉不到。
