:focus-within 更省事，因其是CSS原生伪类，父容器内任意可聚焦子元素获焦即自动生效，免JS绑定、class管理及竞态问题，一行CSS即可实现表单卡片高亮等效果。
focus-within 为什么比监听每个 input 更省事
因为 :focus-within 是 CSS 原生伪类，父容器只要内部任意可聚焦子元素获得焦点，它就自动生效——不用写 JS 绑定 focus/blur、不用管理 class 切换、也不用担心事件冒泡或 focus 移动时的竞态问题。
典型场景是表单卡片：用户点进某个 <input>，整个卡片边框变色、背景微调、提示文字上浮。如果手动监听，得为每个字段加事件，还要处理初始状态、键盘 tab 切换、点击 label 触发 focus 等细节；而 :focus-within 一条 CSS 就覆盖全部。
- label 关联 input（
for+id）时，点击 label 也会触发父级:focus-within - 包含
contenteditable元素或带tabindex的 div 同样算“可聚焦子元素” - Firefox 从 61+、Chrome 65+、Safari 15.4+ 支持，IE 完全不支持——若需兼容 IE，不能只靠它
父容器必须是「可聚焦上下文」才能生效
:focus-within 不会向上穿透到 display: none 或 visibility: hidden 的祖先，也不会作用于被 pointer-events: none 阻断的容器。更关键的是：父容器本身不能是不可渲染的“幽灵节点”，比如纯文本包裹的 <span></span>（没设 display 或 padding），可能因无盒模型而视觉无反应。
- 确保父容器有明确的盒模型：至少设
display: block或inline-block，并有可感知的尺寸（哪怕只是padding: 1px） - 避免套在
<label></label>里再套:focus-within——label 默认不可聚焦，且多数浏览器不把它当 focus 上下文 - 如果父容器是
<fieldset></fieldset>，注意部分旧版 Safari 对legend子元素的 focus 处理异常，建议用<div> 包裹 <h3>和 :focus 冲突时样式优先级怎么算</h3> <p>当同时写 <code>.form-group:focus-within和.form-group input:focus，它们不互斥，但最终渲染取决于具体声明顺序和 specificity。容易踩的坑是：想让父容器高亮时隐藏 placeholder，结果写了.form-group:focus-within input::placeholder { opacity: 0; }，却忘了 placeholder 是伪元素，继承自 input，不是父容器的后代。立即学习“前端免费学习笔记（深入）”；
-
:focus-within选择器本身 specificity 和:focus相同（都是 1 个伪类），所以谁在后面谁覆盖 - 改 placeholder 要直接写在 input 上：
.form-group:focus-within input::placeholder是合法的，但前提是 input 确实在该父容器内 - 别试图用
:focus-within控制子元素的:focus状态（比如.form-group:focus-within input:focus）——这等于双重限定，实际永远成立，纯属冗余
键盘操作下 focus-within 的边界行为
Tab 切换时，焦点离开最后一个 input，父容器的
:focus-within会立刻失效；但如果用户 Shift+Tab 回退到前一个 input，它又立即恢复。这个响应是即时的，但有个例外：当焦点移到父容器自身（比如给它加了tabindex="0"），此时:focus-within仍成立，但逻辑上已不属于“子元素聚焦”——容易误判交互意图。- 不要给父容器设
tabindex，除非你真需要它被键盘聚焦（比如做可折叠表单项） - 移动端软键盘弹出后，iOS Safari 有时会短暂丢失 focus 状态，导致
:focus-within闪退；可加transition: outline 0s避免闪烁 - 如果表单含
<select></select>或自定义下拉，确认其弹层是否脱离父容器 DOM（如挂载到body），否则 focus 移入弹层时，父容器的:focus-within会意外失效
:focus-within，而是想清楚：这个“父容器”在 DOM 结构里是否真的承担了语义上的分组职责，以及它的边界是否干净到能让 focus 流动不被意外截断。 -
