tabindex为负值（如-1）使元素不可通过Tab键聚焦，但可通过JavaScript的focus()方法主动聚焦，适用于需程序控制焦点的场景（如模态框自动聚焦），仅对原生不可聚焦元素有意义。
tabindex 为负值时的实际作用是什么
负的 tabindex（比如 tabindex="-1"）不会让元素进入默认 Tab 键流，但它能让 JavaScript 调用 focus() 主动聚焦——这是控制“可聚焦但不可 Tab 到”的核心手段。常见误用是给按钮或链接设 tabindex="-1" 后发现键盘完全无法操作，其实它本就不该靠 Tab 进入，而是留给程序逻辑（如模态框打开后自动聚焦首个输入框）或辅助技术（如屏幕阅读器通过上下文跳转）使用。
- 只对原本不可聚焦的元素（如
<div>、<span>）加tabindex="-1"才有意义；对<button>或<input>加了反而可能破坏原生焦点行为 - 若想临时移出 Tab 流又保留语义焦点能力（例如折叠面板里的控件），用
tabindex="-1"+aria-hidden="true"需谨慎配合：后者会彻底屏蔽屏幕阅读器，二者语义不一致时会造成无障碍断裂 - React/Vue 中动态渲染组件时，别在条件不满足时仅靠
tabindex="-1"“禁用”焦点——应结合disabled属性或直接不渲染该元素
正数 tabindex 的优先级陷阱
tabindex="1" 不等于“第一个 Tab 停留点”，而是“比所有未指定 tabindex 或 tabindex="0" 的元素更早获得焦点”。一旦页面中出现 tabindex="2"、tabindex="5"，浏览器会按数值升序插入 Tab 流，但**跳过所有 tabindex="0" 元素之后才处理正数序列**——这导致实际顺序和视觉布局严重脱节。
- 避免使用任何正数
tabindex，除非你完整掌控整个页面所有可聚焦元素（包括第三方组件、脚本注入的按钮等） -
tabindex="0"是安全选择：它让元素按 DOM 顺序进入 Tab 流，且保持语义结构与视觉流一致 - 如果必须重排顺序（比如表单提交按钮要放在最后但 DOM 在开头），优先用 CSS
order或 Flex/Grid 重排视觉位置，而非靠tabindex="99"强行干预
复杂表单里哪些元素不该有 tabindex
不是所有能点的元素都需要键盘可访问。盲目给每个 <div> 加 tabindex="0" 反而制造“焦点黑洞”，让屏幕阅读器用户反复陷入无操作意义的容器中。
- 纯装饰性元素（如分隔线
<hr>、图标字体<i class="icon-save">）禁止加tabindex，必要时用aria-hidden="true" - 标签关联的
<label>默认不可聚焦，也不应手动赋予tabindex；真正需要聚焦的是其绑定的<input> - 带
role="group"或role="region"的容器，若内部已有可聚焦子元素，父容器本身不应有tabindex，否则会多出一层无效焦点
验证 tabindex 是否生效的实操检查法
不要依赖浏览器开发者工具里看属性是否存在——要模拟真实键盘流。打开页面后按 Tab 键，观察焦点移动是否符合预期，同时开启 NVDA 或 VoiceOver，听读屏播报是否连贯。
- Chrome DevTools 中按
Ctrl+Shift+P（Windows）或Cmd+Shift+P（macOS），输入 “Show Accessibility” 打开无障碍树，检查焦点路径是否包含冗余节点 - 用
document.activeElement在控制台实时查看当前焦点元素，配合getComputedStyle(el).outline确认焦点样式未被 CSSoutline: none意外抹除 - 移动端 Safari 对
tabindex支持有限，iOS 上多数表单仍依赖原生键盘触发，此时重点应放在inputmode和autocapitalize等输入优化，而非强行模拟桌面 Tab 流
tabindex 策略，它们可能覆盖你的调整。与其硬改这些黑盒逻辑，不如在它们外部用 aria-describedby 或 aria-owns 显式声明焦点关系。 
