:focus-visible 更靠谱，因为它仅在tab导航、辅助技术等真正需要可见焦点时生效，避免鼠标点击时突兀显示焦点框；需用:focus:not(:focus-visible)隔离鼠标触发样式，并确保自定义元素设tabindex和键盘事件监听。
focus-visible 为什么比 :focus 更靠谱
因为 :focus 一触发就加样式，键盘用户和鼠标用户全中招——鼠标点一下按钮，焦点框突兀弹出，体验割裂。:focus-visible 只在真正需要可见焦点时才生效，比如 Tab 导航、Shift+Tab 回退、辅助技术（如屏幕阅读器）触发焦点，而鼠标点击、触摸操作默认不激活它。
实操建议：
- 别直接替换所有
:focus，先保留原有:focus样式作兜底（尤其老浏览器） - 用
:focus-visible覆盖键盘/辅助技术用户的焦点样式，视觉上更克制（比如只加 2px 蓝色外框，不改背景色） - chrome 86+、firefox 83+、safari 15.4+ 原生支持；旧版 Safari 需配合 focus-visible polyfill，但注意 polyfill 会监听 mousedown，可能干扰自定义右键菜单或拖拽逻辑
如何避免 focus-visible 和 :focus 冲突导致样式错乱
常见错误是写成这样：
button:focus { outline: 2px solid #000; }<br>button:focus-visible { outline: 2px solid #007aff; }结果鼠标点击后先触发 :focus，再被 :focus-visible 覆盖——但某些场景下（比如快速点击+松手），:focus-visible 不触发，只剩黑框，风格不统一。
正确做法是「隔离 + 降级」：
立即学习“前端免费学习笔记（深入）”；
- 用
:focus:not(:focus-visible)显式隐藏鼠标/触摸触发的焦点样式：button:focus { outline: none; }<br>button:focus:not(:focus-visible) { outline: none; }<br>button:focus-visible { outline: 2px solid #007aff; outline-offset: 2px; } - 确保
outline不被父元素overflow: hidden截断，加outline-offset预留空间 - 若组件内有
input或textarea，它们原生支持:focus-visible，但需检查是否被 css reset 重置了outline
focus-visible 在 button 和自定义可聚焦元素上的差异
button、a[href]、input 等原生可聚焦元素默认响应 :focus-visible；但 div[tabindex="0"]、span[role="button"] 这类自定义元素，必须满足两个条件才触发：
- 明确设置了
tabindex（哪怕为0或-1） - 绑定了键盘事件处理（如
keydown监听Enter/Space），否则部分浏览器认为“不可交互”，不给:focus-visible - 别忘了加
role属性（如role="button"），否则屏幕阅读器无法识别其语义，:focus-visible失去无障碍意义 - React/Vue 中动态渲染的元素，要确保
tabindex在挂载时已存在，而非靠 js 后续添加——否则首次 Tab 进入可能不触发:focus-visible
性能与 SSR 场景下的 focus-visible 注意点
服务端渲染（SSR）页面初始 HTML 里没有焦点状态，:focus-visible 是纯客户端伪类，不会影响首屏 HTML 结构。但容易踩的坑是：
- 用 JS 检测
document.hasFocus()或监听focusin来做样式切换，反而破坏原生行为，且增加 JS 执行负担 - CSS-in-JS 库（如 Emotion、Styled Components）若开启 ssr，需确认其支持
:focus-visible的服务端解析——多数现代库已支持，但老版本可能把该伪类当无效规则丢弃 - 如果用了 polyfill，注意它会在
document.body插入一个隐藏div并监听全局事件，对首屏 LCP 无影响，但若页面大量动态增删节点，可能引发微小重排
最稳的路径就是纯 CSS + 原生支持检测，polyfill 仅作为渐进增强，不参与核心逻辑判断。