tabindex="-1" 在所有主流浏览器中均支持可编程聚焦，但需满足元素已渲染、未禁用、调用上下文为用户手势三个前提；它仅控制tab键可达性，不隐视觉或语义。
tabindex="-1" 在所有主流浏览器都支持可编程聚焦
是的，tabindex="-1" 在 Chrome、Firefox、Safari（macOS/iOS）、Edge（Chromium 和旧版）中均能稳定响应 .focus() 调用，且不破坏 Tab 键自然流。它不是实验性属性，而是 HTML5 规范明确支持的行为。
但注意：支持 ≠ 自动可用——必须满足三个前提：
- 元素已渲染到 DOM 中（不能在
display: none或未挂载的 Fragment 里调用.focus()） - 元素未被
disabled（button或input等原生控件禁用后，focus()会被忽略） - 调用
.focus()时没有被其他逻辑中断（比如模态框打开前焦点被重置、或事件循环中存在preventDefault()干扰）
为什么有时 .focus() 调用后没反应？常见失焦场景
这不是浏览器兼容问题，而是运行时条件未满足。典型现象包括：
- 控制台报错
Failed to execute 'focus' on 'HTMLElement': The element is not focusable→ 元素当前不可聚焦（如父级inert、CSSvisibility: hidden或opacity: 0不影响聚焦，但display: none会） - 焦点“闪一下又消失” → 其他代码在下一帧主动把焦点移走了（比如 Modal 组件内部有
focus-trap逻辑，或监听了focusout后强制重定向） - 键盘按空格/Enter 没响应 →
tabindex="-1"只管聚焦，不自动绑定事件；必须手动加keydown监听并处理event.key === 'Enter'或' '
移动端 Safari 对 tabindex="-1" 的特殊限制
iOS Safari（尤其是 iOS 16+）在非用户手势触发的上下文中，会静默忽略 .focus() 调用，哪怕元素带 tabindex="-1"。这是安全策略，不是 bug。
绕过方式只有一条：确保 .focus() 是在真实用户交互回调中同步执行的，例如：
-
button.addEventListener('click', () => { modalEl.focus(); })✅ -
setTimeout(() => el.focus(), 0)❌（异步、无手势上下文） -
fetch().then(() => el.focus())❌（网络回调，非用户直接触发）
动态内容（如标签页切换后聚焦）建议包装在 el.addEventListener('transitionend', handler, { once: true }) 或使用 requestAnimationFrame 延迟一帧再聚焦，仍需确保外层有用户手势链。
不要依赖 tabindex="-1" 做“视觉隐藏”或“语义屏蔽”
tabindex="-1" 不改变元素是否可见、是否被屏幕阅读器读取、是否参与布局。它只控制 Tab 键能否到达该元素。
如果你的目标是让某区域对键盘用户“不可达”，但又希望它保留在语义流中（比如模态框背景），正确做法是：
- 不给背景容器加
tabindex="-1"（这反而会让它们变成可聚焦点） - 用
inert属性（现代浏览器支持）或 JS 手动遍历移除/恢复其子元素的tabindex和focus()能力 - 配合
aria-hidden="true"控制读屏器行为（注意：仅当该区域确实无需被读取时才设）
最容易被忽略的一点：加了 tabindex="-1" 却没配 .focus() 调用，等于白加——键盘用户既不能 Tab 进去，也无法通过其他方式抵达，实际就是“不可访问”。
