:focus-within 是CSS伪类，使父容器在任意子元素获得焦点时也进入聚焦态，解决表单高亮、下拉菜单维持展开、无障碍提示等样式统一问题。
focus-within 是什么，它能解决什么实际问题
它是一个伪类，让父容器在**任意子元素获得焦点时**也“算作聚焦状态”。不用 JS 监听 focus / blur 事件，也不用给每个可聚焦子元素单独写 :focus 规则，就能统一控制整个容器的样式反馈——比如表单区域高亮、下拉菜单展开态维持、无障碍聚焦提示增强。
怎么写 focus-within 才真正生效
必须确保子元素本身**可聚焦**，否则伪类永远不会匹配。常见失效原因就是子元素默认不可聚焦（如 div、span）且没加 tabindex。
-
input、button、select、a[href]这类原生可聚焦元素，直接套用:focus-within就行 - 自定义控件（如带
role="button"的div）必须显式加tabindex="0"，否则:focus-within不触发 - 不要写成
.container:focus-within > .child—— 它只作用于容器自身，想改子元素样式得用后代选择器：.container:focus-within .child
.search-box:focus-within {
border-color: #007bff;
}
.search-box:focus-within .search-icon {
opacity: 1;
}
focus-within 在表单场景中的典型误用
很多人以为加上 :focus-within 就能自动处理“输入框失焦后样式恢复”，但其实它**不感知失焦过程**——只要任一子元素还处于聚焦态，父容器就一直保持 :focus-within 状态。
- 多个输入框共存时，切换焦点不会导致父容器“退出”聚焦态，容易造成样式残留
- 配合
outline: none使用时，若未提供其他视觉反馈（如边框色变化），会破坏键盘用户的聚焦路径可见性 - 移动端 Safari 对
:focus-within的支持曾长期不稳定（iOS 15.4+ 才完全可靠），需检查目标环境兼容性
和 JavaScript focus/blur 事件对比时的关键差异
:focus-within 是纯 CSS 响应，不触发重排，性能好，但**无法捕获聚焦来源或执行逻辑**；JS 的 focusin / focusout 事件能精确知道哪个元素聚焦、是否来自鼠标点击，还能阻止默认行为。
立即学习“前端免费学习笔记（深入）”；
- 仅需视觉反馈 → 优先用
:focus-within，简单干净 - 需要记录聚焦位置、联动其他模块、或做防误触判断 → 必须上 JS，监听
focusin（它会冒泡，比focus更适合容器级处理） - 别混用：比如一边用
:focus-within控制边框，另一边又用 JS 给同一容器加 class 控制背景色，容易冲突且难调试
form 或带 role="group" 的 div。随意套在布局容器（如 flex 包裹层）上，会让聚焦逻辑变得不可预测。 
