tabindex 的核心作用是控制元素能否被 tab 键聚焦及是否支持脚本聚焦，而非微调顺序；tabindex="0" 使非表单元素按 dom 顺序进入 tab 流，需配合 role 和键盘事件；tabindex="-1" 仅允许脚本聚焦；严禁使用正数 tabindex，以免破坏可访问性。
tabindex 不是用来“微调” Tab 顺序的工具，而是决定一个元素“能不能被 Tab 到”以及“是否该由脚本控制聚焦”的开关。滥用正数 tabindex 会破坏键盘导航的可预测性，尤其在组件复用或动态渲染场景下，几乎必然导致焦点跳转混乱。
tabindex="0" 是让非表单元素支持键盘导航的正确起点
div、span、article 等默认不参与 Tab 流，加 tabindex="0" 才能让它按 DOM 顺序自然进入 Tab 键循环。这不是“增强功能”，而是补足语义缺失——比如一个自定义 <div role="button">，没 <code>tabindex="0" 就等于对键盘用户不可见。
- 只对有明确交互意图的容器使用，如可点击卡片、折叠面板标题、标签页按钮
- 必须配套实现
Enter和Space键响应，否则键盘用户点不动 -
role="button"不自动带来聚焦能力，tabindex="0"和role要成对出现 - 避免给纯装饰性元素（如图标
<span class="icon"></span>）加tabindex="0"，这会让屏幕阅读器多读一遍无意义内容
tabindex="-1" 是脚本聚焦的唯一安全通道
tabindex="-1" 的作用很窄：禁止 Tab 键到达，但允许 JavaScript 调用 .focus()。这是模态框、展开面板、快捷跳转等场景的刚需。
- 模态框打开后，立即对第一个可操作元素（如确认按钮）调用
.focus()，它必须已设tabindex="-1" - Accordion 展开后，焦点应移至其内部首个可交互子项，不是父容器本身
- 用
aria-hidden="true"隐藏的区域，仍需显式设tabindex="-1"，否则可能意外被 Tab 到 - 仅靠
opacity: 0或position: absolute; left: -9999px隐藏的元素，仍会出现在 Tab 流中，必须加tabindex="-1"或现代inert属性
绝对不要用正数 tabindex（如 tabindex="1"）
浏览器默认按 HTML 源码顺序进行 Tab 导航。强行插入 tabindex="1"、tabindex="2" 会打乱这个顺序，造成焦点跳跃不可预测——尤其是当 DOM 动态更新、组件被多次挂载时，Tab 流会彻底失控。
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
- 导航栏在源码顶部，就让它第一个被 Tab 到；主内容区紧随其后，别因视觉权重高就设
tabindex="1" - 侧边栏、页脚等结构性次要区域，天然应在 Tab 流靠后位置，保持源码顺序就是最佳实践
- 正数 tabindex 在 SSR + hydration 场景下极易与服务端生成的顺序冲突，引发焦点错位
- 屏幕阅读器用户依赖文档流理解页面结构，人为打乱顺序等于剥夺他们的上下文感知能力
禁用/隐藏状态下的 tabindex 处理最容易出错
很多 bug 出现在“以为设了 tabindex 就万事大吉”，却忽略了元素实际是否可用、是否可见。
-
<button disabled></button>自动脱离 Tab 流，无需额外设置tabindex -
display: none或visibility: hidden的元素，即使有tabindex="0"也不会被 Tab 到 -
aria-hidden="true"不影响tabindex行为，若同时存在，必须显式设tabindex="-1"或移除 - 用
inert属性（Chrome 105+、Firefox 111+ 支持）比手动管理tabindex更可靠，它会递归禁用整个子树的焦点和交互
真正难的不是写对那行 tabindex="0"，而是在组件生命周期中持续维护焦点逻辑：展开时聚焦哪、关闭后回哪、错误时跳哪、移动端虚拟键盘弹出时如何稳住焦点——这些细节一旦松动，键盘用户的体验就断在了最基础的一环。
