tabindex通过正数（升序入Tab流）、0（按DOM顺序入流）、-1（仅编程聚焦）控制焦点顺序；常见错误是滥用正数编号或忽略元素可聚焦性。
tabindex 属性怎么控制焦点顺序
HTML 里没有全局“焦点顺序设置”，只有靠每个可聚焦元素的 tabindex 值来逐个干预。它不是开关，而是排序指令：正数按值从小到大进入 Tab 流，0 表示按 DOM 顺序自然加入，-1 表示可编程聚焦但不进 Tab 流。
常见错误是给一堆按钮都设成 tabindex="1"，结果只有第一个生效——浏览器只认唯一最小正整数，其余被忽略。
-
tabindex="0"最安全：元素能被 Tab 到，又不破坏原有阅读顺序 - 避免
tabindex="2"、tabindex="3"这类“手动编号”：DOM 变动后极易错乱，且屏幕阅读器可能跳过非连续值 - 表单控件（
input、button、select）默认有tabindex="0"，不用额外加 - 仅当需要让
div或span接收焦点时，才显式设tabindex="0"或tabindex="-1"
为什么用了 tabindex 还是跳不过某个元素
焦点跳过往往不是 tabindex 没设对，而是元素本身不可聚焦或被屏蔽了。
典型场景：用 div 模拟按钮，加了 tabindex="0"，但没处理 Enter/Space 键响应，键盘用户按到它时没反馈，就以为“跳过了”。
立即学习“前端免费学习笔记（深入）”；
把任意文章或文档内容转换成精美的全屏翻页 HTML 演示文件（幻灯片风格）。当用户发来一篇文章、文档链接、Markdown 内容、或粘贴的文本，并且希望生成演示用的 HTML 时触发。支持任意内容来源：iWiki 链接、KM 链接、本地文件路径、直接粘贴的文本。生成的 HTML 文件保存到本地工作区，并通过企微直接发送给用户。触发词示例：帮我把这篇文章做成PPT、转成演示文档、生成HTML幻灯片、做个演示、转成可以演示的格式、article to deck、make a slide。
- 检查是否设置了
disabled或aria-disabled="true"：两者都会让元素退出焦点流 - CSS 的
visibility: hidden或display: none会让元素彻底不可聚焦；opacity: 0不影响焦点 - 父级有
inert属性（现代浏览器支持），会递归禁用所有子元素的焦点和交互 - JavaScript 主动调用了
element.blur()或阻止了focus事件
用 JavaScript 动态调整焦点顺序靠谱吗
不推荐用 JS 改 tabindex 值来“重排”焦点顺序。DOM 渲染和焦点管理不同步，容易出现 Tab 时焦点消失、卡死或跳到意外位置。
真正需要动态控制时，应该用逻辑聚焦，而不是改属性。
- 用
element.focus()显式把焦点移到目标元素，比改tabindex更直接可靠 - 模态框打开后，应立即将焦点捕获到第一个可操作项（如确认按钮），并用
inert或aria-hidden隔离背景内容 - 如果必须隐藏/显示某块区域，优先用
hidden属性而非 CSS 控制可见性，它同时影响可访问性和焦点流 - 避免在
focus事件里反复调用focus()，可能触发浏览器焦点劫持保护而静默失败
无障碍测试时焦点顺序总和视觉顺序不一致
这不是 bug，是预期行为——只要 DOM 顺序和视觉顺序一致，tabindex="0" 就能保证焦点流符合认知。所谓“不一致”，往往是 CSS Flex/Grid 重排了视觉位置，但 DOM 仍按源码顺序排列。
例如用 flex-direction: row-reverse 把按钮 B 放在按钮 A 左边，但 HTML 中 A 在前、B 在后，Tab 仍先到 A，用户会觉得“焦点跑反了”。
- 修复方法不是加
tabindex，而是调整 DOM 顺序，让 HTML 结构匹配视觉流 - 若因框架限制无法改 DOM（如 React 渲染固定顺序），可用
dir="rtl"配合text-align: right等替代方案，但需全面测试屏幕阅读器表现 - 绝对定位、
float、order等 CSS 手段都不改变可访问性顺序，别指望它们同步焦点流
最麻烦的是嵌套组件里多个 tabindex="0" 元素挤在一起，又没语义化包装——这时候焦点顺序没错，但用户根本不知道当前聚焦在哪一级。得靠 aria-label、aria-labelledby 或视觉焦点轮廓补全上下文。
