:focus-visible 只在键盘导航时显示焦点轮廓，鼠标点击不触发，兼顾可访问性与美观；需配合:focus使用，推荐:focus:not(:focus-visible)写法。
鼠标点击时不想出现蓝色焦点圈？用 :focus-visible 精准控制
浏览器默认会在键盘操作（如 Tab）触发焦点时显示焦点轮廓，但鼠标点击也常意外触发 :focus，导致难看的蓝色/虚线圈。直接用 outline: none 会破坏可访问性——屏幕阅读器和键盘用户就“迷路”了。:focus-visible 就是为此而生：它只在真正需要视觉焦点提示的场景（主要是键盘导航）生效，鼠标点击、触摸、右键等行为不会激活它。
- 必须配合
:focus使用，否则无效；推荐写法：:focus:not(:focus-visible)或:focus-visible单独定义样式 - 不能靠 JS 模拟判断“是否键盘触发”，浏览器原生识别输入方式，更可靠
- 旧版 Safari（:focus 降级兜底
- 示例：去掉鼠标点击输入框的焦点圈，但保留 Tab 导航时的可见轮廓
input:focus:not(:focus-visible) { outline: none; }<br>input:focus-visible { outline: 2px solid #007aff; }
为什么 :focus 和 :focus-visible 同时存在还经常打架？
因为两者匹配逻辑不同：:focus 是“只要元素获得焦点就匹配”，而 :focus-visible 是“获得焦点 *且* 浏览器判定当前交互方式需要可见焦点提示”才匹配。它们不是互斥，而是叠加判断。常见冲突点在于：某些框架（如 React）或自定义组件手动调用 element.focus()，此时若没键盘上下文，:focus-visible 可能不触发，导致你写的 :focus-visible 样式“失效”——其实不是失效，是条件没满足。
- 手动 focus 元素后，如果紧接着用户按 Tab，
:focus-visible才会生效；纯 JS 调用不会自动开启“键盘模式” - Chrome/Firefox 对“首次页面聚焦”的处理较宽松，可能鼠标点击后也短暂触发
:focus-visible，属正常行为 - 测试时别只点鼠标，务必用 Tab 键验证是否真有可见焦点，这是唯一可信的检验方式
兼容性差怎么办？简单安全的降级方案
不支持 :focus-visible 的浏览器（比如 Safari ≤15.3）会直接忽略该规则，所以必须提供 fallback。最稳妥的做法不是“全盘禁用 outline”，而是用 :focus 做基础样式，再用 :focus-visible 覆盖增强——这样老浏览器有基本焦点提示，新浏览器有智能控制。
- 避免写
:focus { outline: none; }+:focus-visible { outline: ... }，这会让老浏览器完全没焦点样式 - 推荐结构：
button:focus { outline: 2px solid #999; }<br>button:focus-visible { outline-color: #007aff; } - 可用
@supports (selector(:focus-visible))包裹增强样式，但没必要——不支持时自然跳过，不影响功能 - 如果项目强依赖旧 Safari，可考虑轻量 polyfill（如
focus-visiblenpm 包），但仅限必要场景
React/Vue 组件里怎么用不翻车？
框架组件常封装了 focus()、autoFocus 或透传 tabIndex，容易干扰 :focus-visible 的检测逻辑。核心原则：别在组件初始化时强行 focus，除非明确知道用户正用键盘操作。
立即学习“前端免费学习笔记（深入）”；
- 移除不必要的
autoFocus={true}，尤其表单首字段——它在页面加载时触发 focus，但无输入上下文，:focus-visible很可能不激活 - 自定义按钮/卡片组件若加了
tabIndex="0"，确保它真需要键盘操作；否则去掉，避免无意中引入焦点管理负担 - 用
useEffect或onMounted调用ref.focus()时，加个简单判断：if (isKeyboardMode()) ref.focus()（需自行实现isKeyboardMode，监听keydown记录状态） - CSS 层面保持简洁，别在组件 scoped style 里重复覆盖全局
:focus-visible行为
实际应用中最容易被忽略的是：焦点管理不是纯样式问题，它牵扯到输入设备检测、用户意图推断和可访问性保障。哪怕只改一行 outline，也要想清楚——这个焦点，到底是给谁看的。
