tabindex为负数（如-1）使元素可被脚本聚焦但不进入tab导航流；常用于模态框、下拉容器等需程序化接管焦点的非原生可聚焦元素，不可替代disabled或aria-disabled。
tabindex 为负数时会发生什么
负值（如 tabindex="-1"）让元素可被脚本聚焦（element.focus()），但不会进入自然 Tab 流。这常用于模态框中临时聚焦某个按钮，或隐藏导航链接又保留程序化访问能力。
常见错误是误以为 tabindex="-1" 能“禁用”键盘访问——它只是跳过 Tab，不阻止 click 或 keydown；若需完全屏蔽，得配合 aria-disabled="true" 和样式 pointer-events: none。
- 只写
tabindex="-1"不等于禁用交互 - 屏幕阅读器仍可能读取该元素，除非加
aria-hidden="true" - React/Vue 中动态设置
tabindex="-1"后，记得在条件变化时同步更新，否则焦点行为会滞后
tabindex 大于 0 的顺序怎么算
正数 tabindex（如 tabindex="2"）会强制元素插入 Tab 流，且按数值升序排列；但所有正数元素都会排在默认可聚焦元素（如 <a href></a>、<button></button>）之后，无论它们在 DOM 中的位置如何。
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
这意味着：tabindex="1" 的 <div> 一定比 <code><button></button> 更晚获得焦点，哪怕 <button></button> 在它后面渲染。这种“重排序”极易破坏线性阅读逻辑，尤其对屏幕阅读器用户。
- 多个相同正数（如都设
tabindex="3"）时，按 DOM 顺序聚焦，不是随机 -
tabindex="0"是最安全的值：保持自然 DOM 顺序，同时让非表单元素可聚焦 - 避免使用
tabindex="99"这类“最大值思维”，它无法保证最后聚焦，反而制造维护陷阱
哪些元素默认能被 Tab 键聚焦
原生可聚焦元素包括：<a href></a>、<button></button>、<input>、<select></select>、<textarea></textarea>、<iframe></iframe>。它们无需 tabindex 就参与 Tab 流。
而 <div>、<code><span></span>、<p></p> 等默认不可聚焦，加 tabindex="0" 才能进 Tab 流——但必须同步提供键盘操作支持（如 Enter 触发点击、Space 切换状态），否则违反 WCAG 2.1 键盘可访问原则。
-
tabindex="0"+role="button"是常见组合，但必须监听keydown处理Enter/Space - 用
contenteditable="true"的<div> 默认可聚焦，此时再设 <code>tabindex可能冲突 - CSS 的
outline: none会隐藏焦点指示，务必用:focus-visible替代，否则键盘用户无法感知当前焦点 - 不要在 iOS Web App 中依赖
tabindex构建核心导航流 - IE11 下
element.focus()对tabindex="-1"元素无效，需降级为tabindex="0"再聚焦 - Vue/React 中用
ref调用focus()前，先检查element.tabIndex !== -1，避免 IE 报错
移动端 Safari 和旧版 IE 的 tabindex 兼容细节
iOS Safari 对 tabindex 支持有限：默认只聚焦表单控件和链接；即使设了 tabindex="0"，<div> 在触摸模式下也不会被 Tab 导航到（除非开启“辅助功能 > 键盘 > 全键盘访问”）。IE11 则完全忽略负值 <code>tabindex 的脚本聚焦能力。
这意味着靠 tabindex 实现的键盘导航，在移动 Safari 上大概率失效；更可靠的方式是用 role="application" 配合手动管理焦点，或直接依赖原生可聚焦元素。
tabindex 当成“开关”来用——它只是调节焦点入口的阀门，不解决交互语义、焦点样式、屏幕阅读器播报这些配套问题。一个 tabindex="0" 的 <div>，没配 <code>role、没处理键盘事件、没视觉焦点反馈，比不加还糟糕。
