能，但不能通过tab键到达；tabindex="-1"允许脚本调用.focus()却排除在默认tab顺序外，适用于模态框关闭按钮等需程序聚焦但不参与自然导航的场景。
tabindex 为负数时元素能被聚焦吗
能，但不能通过 Tab 键到达。这是最常被误解的一点：tabindex="-1" 的作用是“允许脚本调用 .focus()，但排除在默认 Tab 顺序之外”。比如模态框打开后自动聚焦到关闭按钮，又不想让用户按 Tab 就跳进去——这时候就用 -1。
常见错误现象：给按钮加了 tabindex="-1"，再用键盘 Tab 测试，发现完全跳过它，以为“失效”了；其实只是设计如此。
- 只在需要程序控制聚焦（如
element.focus()）但不参与自然导航流时用-1 -
tabindex="0"是最安全的“加入默认顺序”方式，兼容性好，语义清晰 - 避免
tabindex="1"或更高正数——会打乱 DOM 顺序，导致不可预测的焦点跳跃
原生可聚焦元素为什么有时不响应 Tab 键
因为它们被禁用了，或者父容器截断了焦点流。像 button、a[href]、input 这些原生可聚焦元素，默认有 tabindex=0，但一旦设置 disabled（如 <button disabled></button>），就会彻底退出焦点管理，连 .focus() 都无效。
另一个典型场景是 overflow: hidden + tabindex="0" 的子元素：滚动容器没设 tabindex，内部元素即使可聚焦，Tab 到它时页面可能不滚动，导致焦点“消失”在视口外。
立即学习“前端免费学习笔记（深入）”；
-
disabled状态下元素既不能鼠标点击，也不能被键盘聚焦 - 用
aria-disabled="true"替代disabled可保留聚焦能力，适合需要键盘操作但逻辑禁用的场景 - 滚动容器若含可聚焦子项，建议自身也设
tabindex="0"，确保 Tab 过程中能滚动到位
如何让自定义组件（div）正确进入 Tab 顺序
加 tabindex="0" 是起点，但不够。光能聚焦不代表可交互——你得同时处理键盘事件，尤其是 Enter 和 Space，否则屏幕阅读器用户和键盘用户会卡住。
比如一个用 <div role="button"> 模拟的按钮，只加 <code>tabindex="0"，按空格没反应，就是半残废。
- 必须配
role属性（如role="button"、role="checkbox"）来声明语义 - 监听
keydown，对Enter和Space做相同触发（注意Space要preventDefault()，否则会触发滚动） - 加上
aria-pressed或aria-checked等状态属性，让辅助技术感知当前状态
移动端 Safari 对 tabindex 的特殊限制
它默认只允许原生可聚焦元素获得焦点，除非用户主动点击过页面（即触发过“输入上下文”）。这意味着：纯靠 JS 设置 tabindex="0" 的 div，在未触屏前调用 .focus() 会被静默忽略。
这不是 bug，是 Safari 的主动保护策略。绕过方式有限，且都有代价。
- 首次加载后，引导用户轻点一下任意可聚焦区域（哪怕是个透明
input），之后.focus()才生效 - 用
contenteditable="true"临时激活上下文（不推荐，副作用大） - 更稳妥的做法：避免依赖自动聚焦，改用视觉提示 + 显式操作引导（如“点击此处开始”）
真正麻烦的不是怎么加 tabindex，而是不同浏览器对“谁该被聚焦”“什么时候能聚焦”的隐式规则不一致。尤其在混合使用 role、aria-* 和原生属性时，一个没对齐，焦点就悄无声息地掉进黑洞里。
