tabindex="999"是强行插队而非最后聚焦，所有正整数tabindex元素被统一提至tab流最前端并按数值升序排列，破坏dom顺序与视觉/语义逻辑。
tabindex="999" 不是“最后聚焦”，而是“强行插队”
浏览器对 tabindex 正整数的处理逻辑很明确：所有 tabindex 值为 1–32767 的元素，会被**统一提取到 Tab 流最前端**，再按数值从小到大排序。它不关心 DOM 位置、视觉层级或语义重要性，只认数字大小。
所以 tabindex="999" 并不会让你的按钮“排在最后”，而是一旦页面里还有 tabindex="1" 或 tabindex="50"，它就会被挤到它们后面——但仍在所有 tabindex="0" 元素之前。用户从顶部开始按 Tab，焦点可能突然跳到页脚一个标着 tabindex="999" 的导出按钮，中间跳过整个主内容区。
常见错误现象：
- 多个组件各自设
tabindex="999"，结果只有第一个生效，其余被浏览器降级为tabindex="0"（部分浏览器行为） - 动态渲染卡片列表时，每个卡片底部按钮都写
tabindex="999"，焦点顺序变成“所有卡片按钮按渲染顺序集中爆发”，而非逐张浏览 - Flex/Grid 布局下视觉上在右侧的侧边栏，DOM 在源码末尾，却因
tabindex="100"被提前聚焦，键盘流和视觉流彻底割裂
正整数 tabindex 在动态渲染中根本不可靠
React、Vue 等框架挂载/卸载组件时，DOM 节点会频繁插入、移除、重排。tabindex 正数依赖的是全局静态数值对比，但实际运行时：
- 组件 A 渲染时设了
tabindex="1"，组件 B 后来挂载并设tabindex="2"，焦点顺序看似可控；但 B 卸载后，A 的tabindex="1"仍排在所有tabindex="0"元素之前，导致原本合理的 DOM 顺序被破坏 - 服务端渲染（SSR）生成的 HTML 中没有这些正数
tabindex，客户端 hydration 后才加上，焦点流在首屏和交互后不一致 - 多个第三方库各自用
tabindex="1"控制模态框，最终页面里出现十几个tabindex="1"，浏览器只保留第一个，其余退化，行为不可预测
屏幕阅读器会把 tabindex="1" 当作逻辑起点，哪怕它在页脚
辅助技术（如 NVDA、VoiceOver）依赖 tabindex 正数推断页面结构优先级。tabindex="1" 被读作“首要操作项”，但若该元素是右下角的“反馈按钮”，用户一进页面就听到“点击反馈”，完全丢失导航上下文。
更严重的是，WCAG 明确指出：人为打乱 DOM 顺序属于“认知断层”风险项。测试中发现，约 90% 的键盘用户会在遇到首个 tabindex="1" 元素不在预期位置时中断操作，返回上一页。
这不是浏览器 bug，而是你用错了工具——tabindex 正数不是导航微调器，它是强制重定向开关，且没有撤销机制。
真正可控的顺序只来自 DOM 位置 + tabindex="0"
原生可聚焦元素（<button></button>、<a href></a>、<input>）默认就按源码顺序进入 Tab 流。你要做的只是确保它们在 HTML 中的物理位置匹配用户预期路径：
- 导航栏放在
<header></header>里，它自然第一个被 Tab 到 - 主内容区紧随其后，不用加任何
tabindex - 需要键盘访问的自定义控件（如
<div role="button">），统一加 <code>tabindex="0"，不改顺序，只补能力 - 模态框等临时区域，打开时用 JS 对首个可操作子项调
.focus()，该子项需提前设tabindex="-1"（不是正数！）
复杂点在于：很多人以为“设个大数就能控制”，其实最难的部分是保持 DOM 结构与交互意图一致——这没法靠属性值偷懒，得靠组织 HTML 和管理组件挂载时机。
