:focus-within在深层嵌套时仍生效，只认祖先-后代DOM路径是否连续，失效主因是display:contents、display:none、pointer-events:none或框架透传焦点失败等打断焦点流的问题。
深层嵌套时:focus-within仍生效，但必须满足祖先-后代DOM路径连续
只要父容器在 DOM 树中真实包裹可聚焦子元素（哪怕隔了 3–4 层），:focus-within 就能捕获——它不关心层级深度，只认「是否在子树内」。但常见失效不是因为嵌套深，而是中间某层样式或结构打断了焦点流。
检查以下几点：
-
display: contents会移除该元素的盒模型，导致浏览器无法将焦点“归因”到其父级，直接让:focus-within失效 -
visibility: hidden或opacity: 0不影响触发，但display: none会让子元素完全不可聚焦，:focus-within永远不激活 - 若中间层用了
pointer-events: none，鼠标点击无法聚焦子元素（键盘 Tab 仍可能进入），造成“点不动就以为没反应”的错觉 - React/Vue 中自定义组件若没把
tabindex或ref正确透传给底层<input>，视觉上像有输入框，实际焦点根本没落进去
.card:focus-within 不生效？先确认子元素是否真获得了焦点
:focus-within 不是预测器，它只响应「此刻已有焦点」的状态。很多情况下样式没变，不是选择器写错了，而是焦点压根没落到你认为的位置。
快速验证方法：
立即学习“前端免费学习笔记（深入）”；
- 用 DevTools 的 Elements 面板选中目标
<input>，看右下角的 Styles 面板里是否有:focus规则高亮——没有，说明它没真正聚焦 - 按 Tab 键，观察焦点是否真的进入该字段；如果跳过了，检查它是否被
tabindex="-1"锁住，或父级有inert属性 - 在控制台执行
document.activeElement，确认返回值是不是你预期的那个元素 - 子元素设置了
outline: none且没提供其他视觉反馈，人眼误判“没聚焦”，但:focus-within已经生效
避免写 .card:focus-within * 这类宽泛选择器
深层结构里用通配符容易引发意外交互，比如你想高亮卡片背景，结果连内部的 <button>、<i> 图标都被覆盖了颜色或透明度。
更安全的做法：
- 明确限定作用范围：
.card:focus-within > .card-body或.card:focus-within .form-group - 用 BEM 命名隔离样式影响：
.card--focused配合 JS fallback 时也更容易复用 - 如果需动态控制多个子模块，优先考虑用
:focus-within切换父级 class，再由该 class 控制后代样式，而非直接在:focus-within规则里写一堆嵌套声明
iOS Safari ≤15.4 和 IE 完全不支持，JS fallback 必须监听 focusin/focusout
现代浏览器（Chrome 60+、Firefox 61+、Edge 79+、Safari 15.4+）已稳定支持 :focus-within，但 iOS 15.4 及更早版本 Safari 仍缺失——这意味着大量 iPhone 用户看不到效果。
仅监听 focus/blur 事件是无效的，因为它们不冒泡；正确 fallback 方式是：
- 在父容器上监听
focusin（冒泡版 focus），收到后添加is-focusedclass - 监听
focusout，并在事件relatedTarget不在父容器内时移除 class（防止子元素间切换焦点时误清） - 不要只给父容器绑
focus：它收不到子元素的聚焦信号，这是最常被忽略的逻辑断点 - 若需区分具体哪个子元素聚焦，
:focus-within无能为力，得靠event.target记录
真正难的不是写出 .card:focus-within，而是确认焦点确实落到了你写的那个 <input> 上——它可能被 tabindex、CSS 显示属性或框架封装逻辑悄悄拦住了。
