该用:focus-within而非:focus时，是当需让整个表单容器在任意子控件获焦时高亮；:focus-within支持焦点冒泡至容器，:focus仅作用于自身元素。
什么时候该用 :focus-within 而不是 :focus
当你想让「整个表单容器」在任意子输入控件获得焦点时高亮，而不是只高亮当前聚焦的 <input> 或 <textarea></textarea> 本身，:focus-within 就是唯一合理选择。它天然支持冒泡式焦点捕获——只要容器内任一可聚焦子元素（包括 input、textarea、select、带 tabindex 的元素）处于聚焦态，容器就匹配该伪类。而 :focus 只作用于自身，无法向上影响父级样式。
:focus-within 的兼容性与基础写法
现代浏览器（Chrome 65+、Firefox 61+、Safari 15.4+、Edge 79+）都已原生支持，但 IE 完全不支持，如需兼容旧环境需降级方案（比如 JS 监听 focusin/focusout 事件加 class）。基础写法非常直接：
.form-group:focus-within {
border: 2px solid #007bff;
box-shadow: 0 0 6px rgba(0, 123, 255, 0.2);
}
注意：必须确保容器本身可被渲染（不能是 display: none），且子元素确实能获取焦点（例如 input[disabled] 不会触发 :focus-within）。
容易被忽略的触发条件和陷阱
:focus-within 的行为依赖真实焦点流，不是靠 JS 模拟或点击就能触发。常见踩坑点：
- 子元素没设置
tabindex且本身不可聚焦（比如纯<div> 包裹的 <code><label></label>），则不会激活父容器 -
label元素点击后焦点落在关联的input上，这能正常触发 —— 但前提是for和id正确配对，或input是label的子元素 - 使用
autofocus属性时，页面加载后若该元素自动聚焦，:focus-within会立即生效，但 SSR 或 hydration 阶段可能因 DOM 渲染顺序导致样式短暂不生效 - 如果表单容器内有多个可聚焦元素（如
input+button），只要其中任一获得焦点，样式就会应用 —— 这是特性，不是 bug，但需确认是否符合设计预期
配合 :has() 做更精细的控制？先别急
有人会想：“能不能只在有错误的输入获得焦点时才高亮？” 这就需要组合逻辑。目前 :focus-within 无法过滤子元素状态，但可以叠加类名手动控制，例如：
.form-group.error:focus-within {
border-color: #dc3545;
}
而 :has()（如 .form-group:has(input:focus)）虽语义更清晰，但 Safari 对 :has() 的支持直到 16.4 才稳定，且部分场景下性能开销更大。现阶段更稳妥的做法仍是用 JS 设置临时 class，或接受 :focus-within 的“宽泛触发”本质。
真正要注意的是：别把 :focus-within 当成视觉反馈的万能开关。它解决的是「容器响应子元素焦点」这一具体问题，一旦涉及校验状态、多步骤交互或键盘导航细节，就得靠 JS 补位 —— CSS 再聪明，也管不了焦点从哪儿来、到哪儿去。
