让CSS自己算布局：:has()实现自适应网格

为什么固定列数总是不对劲

做前端开发的人几乎都遇到过这样的场景：一个卡片网格，放2个元素时希望是2列，放4个时还是2列，放到6个时却觉得3列更舒服。用grid-template-columns写死数字的问题在于，它不认识内容，只认识设定。

YouTube频道Kevin Powell的教程里演示了一个朴素但常见的困境：minmax()能自适应列宽，但当项目数量是2、4、6这类可整除的偶数时，自动折行往往给出不如人意的结果——2个项目被排成1行、5个项目挤成5列。用媒体查询和修改器类来打补丁，代码会迅速膨胀成条件判断的沼泽。

解决思路应该反过来：不是让开发者告诉CSS怎么排版，而是让CSS先数一数里面有几个孩子，再自己决定怎么排。

用:has()让选择器"数数"

现代CSS的:has()伪类提供了一种声明式能力：父元素可以根据自身的子元素匹配状态来设置样式。结合:nth-child()，就能表达"如果这个网格至少有6个子元素"这类条件。

.gallery:has(> :nth-child(6)) {
  --gallery-columns: 3;
}

这段选择器读作：选中那些拥有第6个子元素的.gallery。由于:nth-child(6)匹配的是"第6个孩子存在"，它天然表示"6个或更多"。如果要精确命中"恰好5个"，需要把两个条件串联起来：存在第5个孩子，并且第5个孩子同时是最后一个孩子。

.gallery:has(> :nth-child(5):last-child) {
  --gallery-columns: 2;
}

截图中的演示正是这个逻辑：当网格恰好有5个项目时，高亮状态生效，列数变量被改写。

:has() 是 CSS 关系伪类，2023 年起在 Chrome、Safari、Firefox 等主流浏览器中稳定支持，它允许根据后代或兄弟元素是否存在来匹配父元素。:nth-child() 则按元素在兄弟节点中的位置（从 1 开始计数）匹配。二者组合时，:has(> :nth-child(6)) 的含义是：父元素存在第 6 个直接子元素，即子元素数量至少为 6。这种“存在即至少”的语义来自 :nth-child 的匹配方式——只要第 N 个孩子存在，该选择器就成立，不需要显式写“大于等于”。

把列数收进一个自定义属性

真正的可维护性来自把"默认值"和"覆盖值"分离。先声明一个带兜底的CSS变量，让所有规则只改写它，而不是重复写grid-template-columns。

.gallery {
  --gallery-columns: 3;
  display: grid;
  grid-template-columns: repeat(var(--gallery-columns), 1fr);
}

随后每条:has()规则只做一件事：重新赋值--gallery-columns。元素数量不同，走的规则不同，但最终都汇入同一个布局声明。这种做法比在JS里读children.length、拼class名、再操作DOM要轻量得多——没有运行时开销，没有水合问题，服务端渲染的HTML直接就是正确的布局。

CSS 自定义属性（CSS Variables）通过 --name 声明，用 var(--name, fallback) 引用，遵循继承与级联规则。在本文方案中，--gallery-columns 声明在 .gallery 上，其值会被更具体的 :has() 规则覆盖，最终被 grid-template-columns 中的 repeat() 读取。由于变量替换发生在计算值阶段，浏览器无需重新解析整条规则，性能开销极低，且服务端渲染的 HTML 直接携带正确变量值，不会出现布局抖动。

组合规则处理边界情况

单一条件往往不够。视频里处理的典型场景是：

• 偶数个且为最后一个孩子时，列数降为2（适配2个和4个的情况）
• 但当数量达到6或更多时，3列反而更好看，需要把前面的规则"排除"掉

排除的做法是把:not()嵌进:has()内部，形成"4个或更少"这样的选择器。通过:has()内部串联多个伪类和:not()，可以构造出相当精细的数量区间判断：

.gallery:has(> :nth-child(7)) {
  --gallery-columns: 4;
}

这里第7个孩子存在即代表"7个或更多"，列数升到4。整套规则加起来不过几行选择器，却能覆盖从2到7以上的全部情况。

有意思的是，:has()内部的这种写法在可读性上有代价。作者也承认，如果追求更易读的版本，可以拆成独立选择器分别注释，而不是把所有逻辑串成一行。这属于风格取舍，不影响能力边界。

:not() 是 CSS 否定伪类，用于排除匹配某选择器的元素；当它嵌套在 :has() 内部时，表达的是“不存在满足某条件的子元素”。例如 :has(> :nth-child(4):not(:last-child)) 表示存在第 4 个孩子且它不是最后一个，即子元素数量至少为 5。通过这种嵌套，可以组合出“4 个或更少”“7 个或更多”等区间判断，而不必为每个数量单独写规则。

为什么这比JS或修改器类更值得

Powell在视频里反复强调一个观点：布局计算应该交给CSS，而不是用JavaScript或组件层面的条件逻辑去兜底。理由有三层。

第一层是性能与正确性。CSS的样式匹配在渲染管线内完成，不触发额外的脚本执行，也不会因为DOM更新时机问题出现布局闪烁。

第二层是解耦。组件不需要知道自己被放在什么容器里、容器里有多少兄弟，它只提供一个--gallery-columns的钩子，外部用任意选择器去覆盖。这比给每个数量写一个.cols-2、.cols-3修饰类要干净得多。

第三层是他在课程推广部分提到的现实：即便日常大量借助AI生成代码，理解底层语言仍然是调试和优化输出的前提。当AI给出一个用媒体查询堆出来的布局时，能否一眼看出问题、能否改写成基于:has()的声明式方案，取决于对选择器能力的掌握程度。这一点对当前依赖AI辅助编码的开发者尤其有参考价值。

落地建议

这套技巧的前提是:has()的浏览器支持。它已在主流浏览器稳定可用，但在需要兼容旧环境的项目里仍需评估。实际使用时，建议把数量判断集中在一个@layer或一段注释清晰的样式块中，并配合视觉回归测试覆盖2、4、6、7个项目这几种边界数量——这些正是固定列数方案最容易出错的点。

真正需要记住的不是某一段具体代码，而是思路的转向：布局规则可以基于内容本身来书写，而不是基于开发者预先假设的几种情况。CSS的表达能力比很多人习惯使用的子集要宽得多。