:has(*:nth-child(4))才是检测“至少4个子元素”的正确写法，因:nth-child(4)作用于后代元素而非自身，通配符*显式指向第4个子元素，空格不可省略，否则层级关系错误。
为什么 :has(*:nth-child(4)) 才是检测“至少4个子元素”的正确写法
很多人误写成 .grid:has(:nth-child(4))，结果始终不生效——因为 :nth-child(4) 是对当前选择器匹配的元素自身施加条件，而 .grid 不可能是它自己的第4个子元素。真正要检测“是否存在第4个子元素”，必须用通配符 * 显式指向后代：:has(*:nth-child(4))。空格不能省，否则变成错误的层级关系。
常见错误现象：
– 写成 :has(> :nth-child(4))（缺少 *），部分浏览器静默忽略
– 写成 :has(*:nth-last-child(1)) 试图反向锚定，但文本节点会干扰计数，不可靠
– 在子元素上写 div:has(+ div + div)，完全偏离目标容器
:not(:has()) 组合必须按“从多到少”顺序书写
CSS 没有 > 或 运算符，只能靠存在性布尔判断逼近范围。比如实现「1–3列 → 1fr，4–6列 → 2fr，7+列 → 3fr」，规则顺序错了就全乱：
-
.grid:has(> div:nth-child(7))→ ≥7，设为repeat(3, 1fr) -
.grid:has(> div:nth-child(4)):not(:has(> div:nth-child(7)))→ ≥4 且 repeat(2, 1fr) -
.grid:not(:has(> div:nth-child(4)))→ 1fr
如果把 not(:has()) 放在最前，后面两条规则会被层叠覆盖；:not() 必须紧贴对应 :has() 条件，漏掉任何一个否定，边界就会错位。
精准匹配“恰好 n 个子元素”时，:nth-child(n):nth-last-child(n) 有硬限制
想让 .container 在恰好有 3 个子元素时切为三等分，可用：.container:has(> *:nth-child(3):nth-last-child(3))。但这要求所有子项是同级块级元素（如 <div>），且 DOM 中不能有文本节点干扰——换行、空格、注释都会被计入 <code>childNodes，导致 :nth-last-child(3) 实际匹配失败。
实操建议：
– 服务端或构建时压缩 HTML，移除容器内无意义的空白
– 或用 display: contents 让文本节点不参与计数（但注意该属性本身有兼容性）
– Safari ≤15.3 完全不支持这种组合写法，生产环境慎用
grid-template-columns 不是 :has() 的安全响应属性
关键限制：浏览器只允许 :has() 触发部分 CSS 属性变更。grid-template-columns 在 Chrome 105+ 和 Firefox 121+ 可用，但 Safari 16.4+ 才开始有限支持，且旧版 WebKit 会直接忽略整条规则——不报错，也不回退到默认值。
更隐蔽的问题：
– 把 :has() 套在 @media 或 @supports 里，部分 Safari 版本会失效
– 若父容器同时设了 display: contents，:has() 子元素计数可能异常
– 必须用 @supports selector(:has(*)) 包裹，而不是 @supports :has()（语法无效）
真正难的不是写出语法，而是接受 :has() 的快照式判断本质：它不计算数量，只做一次存在性检查；DOM 变动后虽自动重匹配，但中间状态不可控。一旦项目需兼容 Safari 15.x 或 Android WebView，就得准备 JS fallback —— 比如监听 MutationObserver 更新 data-count 属性。
