tabindex有效值仅三个：0（按DOM顺序可聚焦）、-1（仅JS聚焦）、正整数（强制插入但破坏可访问性，不推荐）；非原生元素需配合role与事件监听才真正可用。
tabindex 属性控制元素是否可聚焦、以及在键盘 Tab 导航中的顺序，不是“设了就能用”，关键看值的类型和上下文。
哪些值有效？tabindex 的三种取值含义完全不同
只有三个逻辑类别，不是随便填数字：
-
tabindex="0"：元素可聚焦，按 DOM 顺序参与 Tab 流（最常用） -
tabindex="-1"：不可通过 Tab 进入，但可通过.focus()主动聚焦（适合模态框焦点管理、动态弹出内容） -
tabindex="N"（N > 0）：强制指定 Tab 序号，但会打乱 DOM 顺序，破坏可访问性，不推荐使用
为什么 div 或 span 加了 tabindex="0" 还没反应？
加了属性只是“可聚焦”，不代表键盘操作有反馈。常见遗漏点：
- 缺少
outline样式（浏览器默认 outline 被 CSS 重置后，焦点不可见） - 没绑定
keydown或click事件处理逻辑（例如div不会自动触发提交或切换状态） - 父元素设置了
pointer-events: none或visibility: hidden，导致事件被拦截 - 元素被
display: none或aria-hidden="true"排除在可访问树外
表单控件要不要手动设 tabindex？
绝大多数情况不需要——input、button、select 等原生可交互元素默认 tabindex=0，且语义明确。
- 手动加
tabindex="0"到已支持聚焦的元素上，纯属冗余 - 若想跳过某个表单控件（比如搜索框临时禁用），应设
tabindex="-1"+disabled（注意：disabled本身会让元素失去焦点能力，tabindex反而失效） - 真正需要干预的是非语义容器（如
div role="button"），这时tabindex="0"是必须的，否则屏幕阅读器+键盘用户无法操作
最容易被忽略的是：可访问性测试工具常只检查 tabindex 是否存在，但不会验证它是否配合了 role、aria-* 和键盘事件处理——光有 tabindex="0" 不等于可操作。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
