:focus-visible不生效最常见原因是浏览器根据首次交互方式（如鼠标点击）降级为仅触发:focus，这是UA启发式策略而非bug；需配合:focus使用并按正确顺序声明样式，关键场景仍须依赖:focus确保焦点可见性。
为什么:focus-visible有时不生效
最常见原因是浏览器记录了用户首次交互方式：如果页面加载后第一次操作是鼠标点击，后续一段时间内（Chrome 行为）会降级为只触发 :focus，不再判断是否键盘驱动。这不是 bug，而是 UA 的启发式策略——它假设用户已切换到鼠标模式，暂时关闭智能焦点提示。
验证方法很简单：刷新页面 → 立即按 Tab 键（不碰鼠标）→ 观察按钮或输入框是否出现 :focus-visible 样式。如果此时生效，说明逻辑正常；如果仍不生效，检查是否被 JS 主动调用了 blur() 或设置了 tabindex="-1"。
- 移动端 Safari 对
:focus-visible支持不稳定，尤其在软键盘收起后焦点状态易丢失 - 某些 React 组件库（如 Ant Design）内部用
ref.focus()模拟聚焦，但未透传「键盘上下文」，导致:focus-visible不匹配 - 不要依赖
:focus-visible单独存在——它必须和:focus配合使用，否则旧浏览器里键盘用户完全看不到焦点反馈
input:focus 和 input:focus-visible 的样式冲突怎么解
两者不是互斥关系，而是渐进增强：浏览器先匹配 :focus，再叠加 :focus-visible（如果支持）。关键在于声明顺序和视觉意图。
典型错误是写成：
立即学习“前端免费学习笔记（深入）”；
input:focus { outline: none; }
input:focus-visible { outline: 2px solid #007bff; }
这看似合理，但一旦用户用鼠标点击输入框，:focus 会清除 outline，而 :focus-visible 不触发，结果就是「没焦点样式」——键盘用户能看见，鼠标用户看不见，反而更糟。
- 正确做法是先给所有焦点状态一个基础视觉反馈（比如边框变色），再用
:focus-visible加强（比如加外轮廓） - 例如：
input:focus { border-color: #007bff; } input:focus-visible { outline: 2px solid #007bff; outline-offset: 2px; } - 避免在
:focus中设outline: none，除非你同时为:focus-visible提供了明确替代样式
哪些场景必须用:focus而不是:focus-visible
需要无条件提供焦点视觉反馈的场景，不能依赖「是否键盘触发」这个判断逻辑。
- 表单校验失败后自动聚焦到错误字段：JS 调用
el.focus()时，用户可能刚用鼠标提交，但此时必须让用户立刻看到焦点在哪 - 模态框首次打开时自动聚焦首元素：无论用户怎么打开模态框（鼠标点、键盘回车、屏幕阅读器命令），都要确保焦点位置可感知
- 自定义组件（如带搜索的下拉框）中，内部
input被封装后，外部无法控制聚焦来源，:focus-visible可能永远不触发
这些情况下，:focus 是唯一可靠的选择——它不挑触发方式，只认「当前谁有焦点」这个事实。
兼容性兜底和 polyfill 怎么选
原生 :focus-visible 在 Safari 15.4+、Chrome 86+、Firefox 84+ 支持，但 iOS Safari 15.4–16.4 存在偶发失效，安卓 WebView 更不可靠。直接上 polyfill 有风险：WICG 的 focus-visible polyfill 会往元素加 class="focus-visible"，但需手动初始化且可能干扰 SSR 渲染。
- 最稳妥的兼容方案是用
:focus做基础样式，仅对现代浏览器启用:focus-visible增强 - 不用第三方 polyfill，改用 CSS @supports 检测：
@supports (selector(:focus-visible)) { input:focus-visible { outline: 2px solid #007bff; } } - 如果项目必须支持 IE11 或老安卓 WebView，就放弃
:focus-visible，转而用 JS 监听keydown事件打标记（如data-focus-method="keyboard"），再配合 CSS 选择器控制样式
真正容易被忽略的不是语法，而是「焦点状态是否可被用户确认」——无论用哪个伪类，只要键盘用户 tab 到某个按钮却看不到任何变化，这个页面就算不上可用。
