纯 CSS 选择器不能实现瀑布流布局，真正起作用的是 column-count、grid-template-columns 等布局属性；选择器仅用于精准匹配元素并应用样式，无法参与列高平衡或空间填充计算。
纯 CSS 选择器本身不能实现真正的瀑布流布局——它不参与布局计算，只负责匹配和样式应用。所谓“用选择器控制瀑布流”，实际是误读；真正起作用的是 column-count、grid-template-columns 这类布局属性，选择器只是帮你精准作用到容器或子项上。
为什么不能靠选择器驱动瀑布流？
CSS 选择器（如 .masonry > .item、:nth-child(odd)）只能筛选元素并附加样式，无法决定元素在页面中如何排列、换列或跨行。瀑布流的本质是**列高动态平衡**或**二维空间自动填充**，这需要浏览器布局引擎支持（如多列排版或 Grid 自动流），而不是选择逻辑。
-
:nth-child()可以给第 3 个卡片加margin-left: auto，但不会让它跳到新列——它仍在原文档流位置 -
[data-type="featured"]能让某张图变大，但若用column-count布局，它仍会被按高度切分，可能被截断 - 试图用
.item:first-of-type强制首项占两列？在多列布局里无效；Grid 中需配合grid-column才生效，而那是 Grid 属性，不是选择器能力
选择器真正该用在哪几个关键位置？
它们的作用是“精准干预布局行为”，而非替代布局机制：
- 给容器加类名触发不同布局模式：
.masonry-cols对应column-count: 3，.masonry-grid对应display: grid—— 类名是开关，不是魔法 - 用属性选择器区分内容类型：
[data-height="tall"]配合 JS 动态设grid-row-end，或在 Grid 中设grid-row: span 3 - 响应式切换时避免样式冲突：媒体查询内用
.masonry-grid .item而非泛用.item，防止移动端 column 布局下样式错乱 - 图片加载前占位：
.item img:not([src])设visibility: hidden，配合aspect-ratio防闪跳 —— 这里选择器在补布局短板
常见误用：以为 class 名能“启动”瀑布流
比如写 .waterfall 就以为自动生效，结果发现没效果。问题往往出在：
立即学习“前端免费学习笔记（深入）”；
- 漏了核心布局声明：
display: grid或column-count没写，光有类名没用 - 子项用了
float或inline-block，覆盖了 Grid/column 的布局上下文 - 父容器没设
height或max-height，在column-count下导致列高为 0，内容堆成一团 - 用了
:is(.item)这类现代选择器，但在旧版 Safari 中不支持，导致样式丢失、布局崩塌
真正要控制瀑布流，得盯住布局属性本身；选择器只是帮你把对的样式，贴到对的元素上——别指望它替你算高度、分列或重排。最容易被忽略的，是当用 JS 动态插入新卡片时，忘了给它们加上和原有元素一致的 class 或 data 属性，导致新项不响应已有的选择器规则，布局立刻失衡。
