能，focus-within 只能选中最近的可聚焦祖先元素，该祖先不能被 tabindex="-1" 或 display: none 等属性阻断焦点冒泡路径。
focus-within 能直接选中父容器吗
能，但有个硬性前提：父容器必须是 focus-within 的**最近祖先元素**，且该祖先本身不能被 tabindex="-1" 或其他方式“拦住”焦点冒泡路径。浏览器只向上找第一个满足条件的可聚焦容器，不会跨过 display: none、visibility: hidden 或 pointer-events: none 的父级——这些都会中断 :focus-within 的触发。
- 常见错误现象：
div.form-group:focus-within没生效，其实是form外层套了个div且没设tabindex="0"，导致焦点“卡”在中间层，没传到目标div - 使用场景：表单校验状态提示、输入框激活时展开帮助文本、卡片式表单项高亮整个区块
- 兼容性注意：IE 完全不支持，Edge 79+、Chrome 60+、Firefox 61+、Safari 15.4+ 支持；如需兼容旧版 Safari（focusin 事件手动加类
input 获焦但 focus-within 不触发？检查这些地方
不是所有表单控件都能自然触发 :focus-within，关键看它是否真的获得了“可聚焦状态”。比如 <input disabled>、<textarea readonly></textarea>、或被 tabindex="-1" 显式禁用的元素，都不会让父级进入 :focus-within 状态。
- 常见错误现象：点击
<select></select>后父容器没变色，其实是该select被包裹在label里，而label没设display: block或position: relative，导致样式没生效（不是逻辑问题，是渲染层级干扰） - 参数差异：不需要额外 JS 绑定，但必须确保子元素本身可聚焦——
tabindex="0"可以让div、span等非表单元素也触发:focus-within，不过要小心破坏可访问性 - 性能影响：零运行时开销，纯 CSS 计算，比监听
focus/blur事件更轻量
嵌套表单里 focus-within 怎么精准控制作用范围
多个 form 或 fieldset 嵌套时，:focus-within 会从获得焦点的元素一路向上冒泡，直到遇到第一个匹配的选择器。所以选择器越具体，越不容易误中。
- 使用场景：一个页面有多个“地址编辑区块”，每个都含
input[name="street"]，需要只高亮当前正在编辑的那个区块 - 实操建议：
.address-block:focus-within比div:focus-within更安全；如果区块内还有子表单（如“收货地址”里嵌“发票信息”），就给子表单容器加class="invoice-section"并单独写.invoice-section:focus-within - 容易踩的坑：用
form:focus-within时，如果form内部有button[type="submit"]获焦，也会触发——这通常符合预期；但如果只想响应输入类控件，就得改用更细粒度的容器类名，别依赖语义标签本身
focus-within 和 JavaScript focusin 事件怎么配合用
纯 CSS 的 :focus-within 无法捕获焦点离开的精确时机（比如用户 Shift+Tab 回退到上一个元素），这时候得靠 JS 补位。但没必要重写整套逻辑，只需监听 focusin 和 focusout，并在父容器上同步加/删一个临时类，比如 has-focus，CSS 里写 .form-group.has-focus 作兜底。
立即学习“前端免费学习笔记（深入）”；
- 常见错误现象：用
focus事件代替focusin，结果子元素获焦时父容器没收到事件——因为focus不冒泡，focusin才冒泡 - 实操建议：优先用
:focus-within，只在需要“离开时执行某操作”（比如提交前验证、关闭下拉菜单）时才引入 JS；避免同时用两者控制同一视觉状态，容易打架 - 兼容性补充：Safari :focus-within 不可用，此时 JS 是唯一选择；可以用
@supports not selector(:focus-within)做特性检测后加载降级逻辑
真正容易被忽略的是 tabindex 的隐式行为：哪怕没写 tabindex，input、select 这些原生控件默认可聚焦，但它们的父容器不会自动变成“可聚焦上下文”——:focus-within 的触发完全依赖 DOM 结构和聚焦流是否畅通，而不是你写了什么 class。
