tabindex="-1"使元素可脚本聚焦但排除在tab顺序外，需手动绑定键盘事件并确保可见性与语义正确；负值均等效于-1，不可用作优先级标记，且不替代aria-hidden。
tabindex="-1" 能让元素获得脚本聚焦但不进入自然 Tab 顺序
这是最常见也最关键的用法。元素设 tabindex="-1" 后，用户按 Tab 键时完全跳过它，但它可以通过 JavaScript 主动调用 .focus() 获取焦点——比如模态框打开后自动聚焦到第一个可操作元素、或错误字段高亮后聚焦提示框。
常见错误现象：tabindex="-1" 却无法用键盘触发交互（如回车/空格），是因为它本身不支持键盘事件监听，必须手动绑定 keydown 并判断 Enter/Space；否则用户“聚焦了却点不了”。
- 只适用于需要临时聚焦、但语义上不属于导航流的元素（如关闭按钮、tooltip 容器）
- 不能替代
aria-hidden="true"：隐藏内容仍可能被屏幕阅读器读出，需配合aria-hidden或inert控制可访问性 - 若元素本身不可聚焦（如
<div>），仅设 <code>tabindex="-1"不足以让它响应.focus()—— 浏览器要求该元素至少是“可聚焦候选”（focusable candidate），而原生不可聚焦元素加tabindex就满足条件tabindex 小于 -1（如 -2、-99）和 -1 效果完全一样
规范明确指出：任何负值都等效于
-1。浏览器不会按数值大小排序，也不会因为写tabindex="-99"就“更不重要”。所有负值都只表达一个意思：排除在 Tab 顺序之外，但允许脚本聚焦。使用场景极少有理由写小于 -1 的值。反而容易引发误解，比如团队成员以为
-99是“深度禁用”，其实和-1行为零差异。- 不要用负数做“优先级标记”（如 -1 表示次要、-2 表示更次要）——无效
- 部分旧版 IE 对
tabindex 处理异常，虽现代浏览器已统一，但无必要引入兼容风险 - 代码审查中看到
tabindex="-5"可直接改为tabindex="-1"，语义更清晰
为什么不用 tabindex="0" 替代？
tabindex="0"让元素进入默认 Tab 顺序（位置由 DOM 顺序决定），适合原本不可聚焦但需键盘导航的容器（如卡片、列表项）。但它会改变用户的 Tab 流程——多一个按键才能跳过，可能打断预期节奏。典型冲突场景：一个折叠面板的标题用了
tabindex="0"，用户 Tab 到它后按空格展开，再 Tab 却跳到了面板内部第一个输入框——这本应是用户主动点击/聚焦才触发的行为。此时用tabindex="-1"+ 点击事件控制展开更安全。-
tabindex="0"适合“该元素本身就是导航目标”的情况（如自定义按钮、可选菜单项） -
tabindex="-1"更适合“聚焦只为功能服务，非导航意图”的情况（如错误提示、临时弹层） - 二者不能混用在同一元素上；重复设置以最后解析的为准
无障碍测试中容易忽略的点
设了
tabindex="-1"不等于完成了可访问性适配。很多开发者聚焦后就停了，忘了配套处理键盘交互和语义暴露。- 聚焦后必须支持 Enter 和 Space 触发主操作（按钮类）或方向键导航（菜单类）
- 若元素视觉上“消失”（
display: none或visibility: hidden），即使有tabindex="-1"也无法聚焦——浏览器跳过渲染树中不可见节点 - 屏幕阅读器是否读出该元素，取决于
role、aria-*属性，而非tabindex值本身；例如<div tabindex="-1" role="alert"> 会被朗读，而纯 <code>div不会 实际项目里，tabindex="-1"是个轻量但敏感的开关——它不改变 DOM 结构，却悄悄接管了焦点控制权。稍不注意，就会让键盘用户卡在看不见的焦点里，或者让屏幕阅读器念出一堆无关信息。用之前，先想清楚：这个聚焦，到底是给用户用的，还是只给 JS 用的。
