tabindex="0"使非原生元素按DOM顺序自然加入Tab流，需同步添加role、监听keydown并提供:focus-visible样式；禁用正数tabindex，tabindex="-1"仅用于编程聚焦。
tabindex 值为 0 时元素能被聚焦但不改变默认顺序
当一个元素没有原生可聚焦行为（比如 <div> 或 <span>），又需要支持键盘 TAB 导航时，设 tabindex="0" 是最常用也最安全的做法。它让元素进入浏览器默认的 tab 顺序流——也就是按 HTML 文档流从上到下、从左到右的位置自然排序。
常见错误是以为 tabindex="0" 会把元素“插到第一个”，其实不会。它只是“申请加入队列”，排队位置仍由 DOM 顺序决定。
- 适用于模态框中的关闭按钮、自定义下拉触发器等需键盘操作但非原生控件的场景
- 若父容器有
tabindex="-1"，子元素即使设tabindex="0"也不会被聚焦（焦点捕获逻辑会跳过） - 注意：屏幕阅读器通常会把
tabindex="0"元素当作普通可交互元素读出，语义合理
tabindex 为正整数时强制插入 TAB 顺序，但强烈不推荐
设 tabindex="1"、tabindex="5" 等正数，会让该元素在 TAB 流中优先于所有 tabindex="0" 和无 tabindex 的元素，数值越小越靠前。但这个机制在实际项目中几乎总是带来问题。
根本原因是：TAB 顺序不再反映 DOM 结构，也不反映视觉/语义顺序，用户用键盘导航时会产生“跳来跳去”的断裂感，尤其对视障用户极不友好。
- 多个正数
tabindex值之间若存在空缺（如只用了tabindex="1"和tabindex="10"），中间不会自动补位，但浏览器仍按数值升序排列 - React/Vue 等框架中动态渲染的组件若依赖正数
tabindex控制顺序，DOM 插入时机稍有偏差就可能导致顺序错乱 - WCAG 明确建议避免使用正整数
tabindex，除非有极其特殊的、经无障碍评审确认的交互需求
tabindex="-1" 的真实用途不是“禁用”，而是“手动聚焦”
tabindex="-1" 最常被误解为“让元素不可通过 TAB 访问”，这没错，但它真正的价值在于：允许脚本调用 .focus() 主动聚焦，同时不破坏原有 TAB 流。
使用 PptxGenJS 和 Python 解析，将结构化的 HTML/CSS 幻灯片内容转换为原生、可编辑的 PowerPoint（.pptx）演示文稿。
典型场景是模态框打开后，立即将焦点移到第一个可操作元素；或 Tooltip 显示时，把焦点临时移入其中再移出。
- 不能用
tabindex="-1"来“隐藏”表单控件的键盘访问——那应该用disabled或aria-hidden="true"配合逻辑控制 -
tabindex="-1"元素无法用 TAB 进入，但可以用鼠标点击或脚本.focus()聚焦，之后按 Shift+Tab 可能退出到上一个元素（取决于浏览器实现） - 某些旧版 Safari 对
tabindex="-1"在 SVG 元素上的支持不稳定，如需兼容需额外测试
不写 tabindex 才是多数情况下的正确选择
绝大多数页面元素根本不需要显式设置 tabindex。原生可聚焦元素（<a href>、<button>、<input>、<select>、<textarea>）默认就在 TAB 流中，且顺序天然符合文档流和视觉层次。
强行加 tabindex="0" 到已有语义的按钮上，除了增加冗余属性，还可能干扰某些辅助技术对“主操作入口”的识别逻辑。
- 检查是否真有必要：先用键盘 TAB 走一遍页面，看焦点是否自然落在预期位置；如果不是，优先调整 HTML 结构顺序，而不是加
tabindex - 用 Chrome DevTools 的“Accessibility”面板或 axe 浏览器插件验证焦点顺序是否与视觉顺序一致
- 移动端 Safari 对
tabindex的处理更保守，部分tabindex="0"元素在触屏模式下仍不可聚焦，需结合role和aria-*补充语义
真正难的不是怎么配 tabindex，而是判断“要不要配”。很多团队花时间调正数 tabindex 的值，却没发现按钮本该放在标题后面，而不是塞进页脚再用 tabindex 拉回来。
