:has() 是唯一能从子元素反推父元素的原生 CSS 方案，需配合前置选择器使用，如 .container:has(.required-section) { background: #ffebee; }，兼容 Chrome 105+、Firefox 121+、Safari 15.4+，不支持 @keyframes 和伪元素，深层嵌套应避免，fallback 可用 data-* + JS 检测。
用 :has() 选择器直接匹配子结构变色
现代 CSS 已支持 :has()，它是唯一能“从子元素反推父元素”的原生方案。只要目标结构存在，父级就能响应式变色，无需 JS 干预。
常见错误是写成 :has(.target) { color: red; } 却忘了加父选择器——:has() 本身不选中任何元素，必须配合前置选择器使用。
- 正确写法：
.container:has(.required-section) { background: #ffebee; } - 注意浏览器兼容性：Chrome 105+、Firefox 121+、Safari 15.4+ 支持；旧版 Safari 需加
-webkit-前缀（但仅限部分版本） - 不能在
@keyframes或伪元素（如::before）里使用:has() - 性能上无明显负担，但避免深层嵌套写法如
div:has(div:has(div:has(.flag)))，可读性和维护性会急剧下降
fallback 方案：用 data-* 属性 + JS 触发
当需要兼容 IE 或老版 Safari，就得退回到 JS 主动标记。核心逻辑不是“监听 DOM 变化”，而是“检查结构是否存在并打标”，简单可靠。
典型场景：CMS 输出的 HTML 不可控，但你知道某类区块（如 .cta-banner）一旦出现，就要让整个 .article 背景变浅蓝。
立即学习“前端免费学习笔记（深入）”；
- JS 判断后加属性：
if (el.querySelector('.cta-banner')) el.setAttribute('data-has-cta', '') - CSS 对应写：
.article[data-has-cta] { background: #e3f2fd; } - 别用
classList.add()再写.article.has-cta——多一次 class 维护，且容易和业务 class 冲突 - 如果结构动态加载（如 React 懒加载模块），需在内容挂载后手动调用检测函数，不能只靠 DOMContentLoaded
:has() 的嵌套与否定陷阱
:has() 看似简单，但组合稍一复杂就失效。最常踩的坑是误以为它支持“非直接子元素 + 否定”这种双重逻辑。
比如想表达“包含 .icon 但不包含 .disabled”，写成 .btn:has(.icon):not(:has(.disabled)) 是合法的，但若写成 .btn:has(.icon:not(.disabled)) 就错了——:not() 在 :has() 内部只作用于单个元素，无法过滤祖先关系。
- 要匹配“有 .icon 且其父不是 .disabled 容器”，得拆成两步：
.btn:has(.icon):not(:has(.disabled .icon)) -
:has()里不能用伪类如:hover、:focus，也不能用:nth-child()等依赖位置的伪类 - 路径过深易出错：优先用明确 class 名，少用
div > div > span这类脆弱路径
为什么不用 JavaScript 监听 MutationObserver？
有人第一反应是用 MutationObserver 监听子节点增删再改样式，这在绝大多数场景下是过度设计。
真正需要它的只有两类情况：内容完全由第三方脚本注入（你无法控制插入时机）、或结构变化频率极高（如实时协作编辑器）。普通页面里，DOM 一般只初始化一次或少数几次更新。
- Observer 的回调开销比一次
querySelector高得多，尤其在长列表中频繁触发 - 容易漏掉初始状态：必须在 observer 启动前先手动执行一次检测，否则首屏不生效
- 若多个组件都监听同一区域，可能互相干扰；而
:has()或data-属性是声明式的，天然解耦
实际项目里，90% 的这类需求用 :has() 一行 CSS 就搞定。剩下那 10%，往往是结构判断条件模糊（比如“包含带 data-role=‘primary’ 的按钮，且不在 footer 里”），这时候与其硬塞进 CSS，不如在 JS 初始化时算清楚，写死一个 data-state 更稳。
