:focus-within 用于父容器监听子元素获焦，:focus-visible 专为键盘用户优化焦点样式；二者常协同使用但目的不同，需兼顾可访问性与兼容性。
focus-within 适合监听「子元素获得焦点」的容器场景
当一个容器内部任意可聚焦子元素（如 <input>、<button>、带 tabindex 的元素）被聚焦时，:focus-within 就会匹配该容器本身。它不关心焦点是否来自鼠标点击、键盘 Tab 还是脚本调用，只要子元素有焦点，父容器就“激活”。
常见错误是把它当成 :hover 的替代品，或误以为它只响应键盘焦点 —— 实际上鼠标点击 <input> 同样触发 :focus-within。
- 必须作用于**父容器**，不能直接写在可聚焦子元素上（那样没意义）
- 支持嵌套：如果
.form包含.field，而.field里有<input>，那么.form:focus-within和.field:focus-within都会生效 - 兼容性良好（Chrome 60+、Firefox 61+、Safari 15.4+、Edge 79+），但 IE 完全不支持
.card:focus-within {
box-shadow: 0 0 0 2px #007bff;
}
.card:focus-within .label {
color: #007bff;
}
focus-visible 是为「仅键盘用户」优化焦点样式的现代方案
:focus-visible 解决的是老式 :focus 的经典问题：鼠标点击按钮时也显示焦点环，视觉干扰强，且对非键盘用户无意义。:focus-visible 只在浏览器**判断当前焦点由键盘操作（Tab / Shift+Tab / 空格等）触发**时才生效，自动忽略鼠标点击或触摸。
它不是独立选择器，通常和 :focus 配合使用：先用 :focus 设默认行为（比如移除丑陋的默认 outline），再用 :focus-visible 加回有意义的键盘焦点样式。
立即学习“前端免费学习笔记（深入）”；
- 不能单独依赖
:focus-visible做功能逻辑（比如控制显隐），因为它的触发完全由 UA 决定，且可能因系统设置（如 macOS 的“按下 Tab 键以在网页中突出显示链接”开关）而关闭 - 若同时写了
:focus和:focus-visible，后者优先级更高（同层级，后声明覆盖前声明） - 需要搭配
outline: none谨慎使用 —— 移除 outline 后若未提供:focus-visible替代样式，键盘用户将彻底失去焦点指示
button:focus {
outline: none;
}
button:focus-visible {
outline: 2px solid #007bff;
outline-offset: 2px;
}
focus-within 和 focus-visible 经常一起用，但目的完全不同
比如一个下拉菜单组件：div.dropdown 包含触发按钮和隐藏的 ul.menu。你希望：点击按钮时展开菜单（鼠标操作），而键盘用户 Tab 到按钮后继续 Tab 进入菜单项（键盘操作）—— 这就需要两个伪类协同。
-
.dropdown:focus-within：用于在任意子元素（按钮或菜单项）聚焦时，保持整个.dropdown处于“激活态”，比如高亮边框、显示箭头状态 -
button:focus-visible：只给按钮加键盘专属焦点样式，避免鼠标点击时出现突兀 outline - 菜单项（
li a）自身也要写:focus-visible，否则键盘用户进入后看不到焦点位置
容易踩的坑是：只加了 :focus-within 却忘了给可聚焦子元素配 :focus-visible，导致键盘用户在容器内移动时焦点“消失”；或者滥用 outline: none 后没补 :focus-visible，直接违反 WCAG 2.4.7（焦点可见性）。
兼容性兜底和 polyfill 注意事项
:focus-within 的 polyfill（如 focus-within-polyfill）基本可用，但需注意：它依赖事件监听（focusin/focusout），无法捕获初始页面加载时已聚焦的元素（比如 URL 带 #my-input 锚点）；而且对 contenteditable 或 Shadow DOM 内部元素支持有限。
:focus-visible 的 polyfill（如 focus-visible 库）更复杂，它通过监听 mousedown 和 keydown 来模拟 UA 的判断逻辑，但存在竞态风险 —— 比如快速点击后立刻按 Tab，可能误判为“鼠标模式”而抑制焦点样式。
- 生产环境建议用
@supports selector(:focus-visible)进行特性检测，而不是全局引入 polyfill - 不要在
:focus-visible中写影响布局的样式（如height、display），它可能被 UA 动态切换，造成闪烁 - 移动端 Safari 对
:focus-visible支持较晚（iOS 15.4+），且默认不触发（需用户开启辅助功能中的“键盘”相关选项）
@supports selector(:focus-visible) {
button:focus {
outline: none;
}
button:focus-visible {
outline: 2px solid #007bff;
}
}
真正难处理的不是语法，而是判断「这个交互到底该由谁响应焦点」：是容器？是触发控件？还是列表项？漏掉其中一层，键盘用户的路径就断了。 
