:focus-within 失效的常见原因包括子元素不可聚焦、pointer-events: none 阻断事件、click 中 preventDefault/stopPropagation 干扰焦点、纯 CSS 无法区分聚焦目标、iOS Safari 兼容性问题。
focus-within 触发条件不满足时的常见表现
当父容器设了 :focus-within，但点击子元素（比如 input 或 button）后样式没生效，大概率是子元素本身不能获得焦点。例如：div、span 默认不可聚焦，即使加了 tabindex="0"，若被 pointer-events: none 或 disabled 阻断，事件也无法冒泡到父级触发 :focus-within。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 检查子元素是否真正获得了焦点：用浏览器 DevTools 的 Elements 面板看该元素是否有
:focus状态高亮 - 确保子元素是可聚焦的原生控件（
input、button、select），或显式添加tabindex="0"且未被禁用 - 避免在子元素上设置
pointer-events: none或opacity: 0同时又依赖其触发焦点逻辑
子元素 click 事件阻止 focus 获取导致 focus-within 失效
某些场景下，子元素绑定了 click 事件并调用了 e.preventDefault() 或 e.stopPropagation()，这会干扰浏览器默认的 focus 行为。比如自定义下拉菜单的 toggle 按钮，点了之后没聚焦输入框，父容器自然不会进入 :focus-within 状态。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 不要在 click 中无条件调用
e.preventDefault()，除非你明确知道它会阻止 focus - 如需保持点击行为又想触发 focus，手动调用
input.focus()（注意时机：确保 DOM 已就绪，避免在异步回调中漏掉） - 对非表单子元素（如图标
svg）做交互时，别让它“抢走”焦点，改用role="button"+tabindex="0"+ 显式.focus()控制
用 JavaScript 辅助匹配 focus-within 的样式边界
CSS 的 :focus-within 是声明式的，无法动态判断“当前哪个子元素获得了焦点”。当需要差异化响应（比如只在 input 聚焦时显示提示，而在 button 聚焦时不显示），纯 CSS 不够用，得靠 JS 补位。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 监听父容器的
focusin事件（注意不是focus，它不冒泡），通过e.target判断具体聚焦元素 - 用 class 切换代替纯
:focus-within：给父容器动态加data-focus-target="input"这类属性，再写对应 CSS 规则 - 避免频繁操作 class 影响性能；可节流
focusin，或只在必要时更新
const container = document.querySelector('.form-group');
container.addEventListener('focusin', (e) => {
const target = e.target;
container.dataset.focusTarget = target.tagName.toLowerCase();
});
移动端 Safari 对 focus-within 的兼容性陷阱
iOS 15.4+ 才开始支持 :focus-within，且在 contenteditable 区域或软键盘唤出后行为不稳定。更隐蔽的问题是：Safari 有时不会在 tap 后立即触发 focus，导致 :focus-within 延迟生效甚至不生效。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 对关键交互降级处理：用
:active+:focus组合模拟，或 JS 监听touchstart后主动.focus() - 避免依赖
:focus-within实现核心功能（如表单验证提示），优先保障键盘导航和屏幕阅读器可用性 - 测试时务必真机连接 Safari Web Inspector，不要只信桌面模拟器
:focus-within 很方便，但它的触发完全依赖浏览器对“焦点获取”的真实判定。一旦中间环节被事件拦截、属性屏蔽或平台限制打断，样式就会静默失效——这种失效没有报错，也不抛异常，最容易被忽略。 
