纯CSS响应式瀑布流仅推荐多列布局（column-width）和Grid（repeat(auto-fill, minmax())）；float因脱离文档流、无法列高自适应且易塌陷，已淘汰。
纯 CSS 实现响应式瀑布流，float 已不是推荐路径——它无法真正支持“列高自适应填充”且易引发清除问题，现代方案应绕开浮动。当前可靠方式只有两种：多列布局（column-count/column-width）和 Grid（grid-template-columns: repeat(auto-fill, ...)），下面直说关键点。
为什么不要用 float 实现瀑布流
浮动本质是文本环绕机制，强行用于多列图片排列会遇到几个硬伤：
-
float元素脱离文档流，父容器高度塌陷，必须额外加clear或伪元素修复，响应式断点切换时极易出错 - 无法控制列数自动适配视口；
float: left+width: 33.333%只能模拟等高栅格，不是真正的瀑布流（即列高不均衡、无法错落） - 浏览器对
float在 flex/grid 容器内的行为未定义，混用会导致渲染不一致，尤其 Safari 和旧版 Edge
column-width 是响应式瀑布流最简解法
它让浏览器按最小列宽自动计算列数，比固定 column-count 更适合响应式场景：
- 设置
column-width: 250px后，视口宽度 700px 时自动分 2 列，1200px 时分 4 列，无需媒体查询干预 - 必须配合
break-inside: avoid（或avoid-column），否则长图会被截断到两列中 -
column-gap控制列间距，但无法控制行内图片垂直间距——需用margin-bottom在子项上设 - 兼容性好：Chrome 50+、Firefox 13+、Safari 9+、Edge 10+ 都支持；IE10/11 仅支持
column-count，不推荐上线使用
示例关键样式：
立即学习“前端免费学习笔记（深入）”；
.masonry {
column-width: 250px;
column-gap: 12px;
}
.masonry > * {
break-inside: avoid;
margin-bottom: 12px;
}
grid-template-columns: repeat(auto-fill, ...) 更可控但有陷阱
Grid 方案视觉效果更稳，但要注意它「不是真瀑布流」——grid-auto-rows 设的是固定行高，图片靠 object-fit: cover 填满，实际列高仍由内容撑开：
-
minmax(250px, 1fr)中的1fr是最大宽度，非弹性分配；列数由容器宽度和最小宽共同决定 - 若图片原始比例差异大（如 1:1 和 4:3 混排），
object-fit: cover会裁剪，需确认设计是否接受 - 不加
grid-auto-flow: dense时，小图不会填补前面大图留下的空隙，视觉密度下降 - 移动端小屏下，
minmax(250px, 1fr)可能导致单列过宽，建议用媒体查询降为minmax(180px, 1fr)
典型写法：
.masonry-grid {
display: grid;
grid-template-columns: repeat(auto-fill, minmax(250px, 1fr));
gap: 12px;
grid-auto-flow: dense;
}
.masonry-grid > img {
width: 100%;
height: 200px; /* 或用 aspect-ratio: 4/3 */
object-fit: cover;
}图片高度不均时，CSS 真正的限制在哪
所有纯 CSS 方案都绕不开一个事实：浏览器无法在布局阶段动态测量每个图片加载后的自然高度并重排列。所以：
- 多列布局靠分段流式折行，列高最终由最长项决定，视觉上“错落”但列底边不齐——这是正常表现，不是 bug
- Grid 的
grid-auto-rows是占位用的，如果想让每张图按自身高度伸展，就得放弃height: 200px，改用aspect-ratio或 JS 补充计算 - 懒加载图片（
loading="lazy"）可能造成列高重绘闪烁，建议搭配height占位或aspect-ratio防止跳动
真要列高完全均衡、支持无限滚动且动态插入，还是得上 JS 库（如 Masonry、Packery）或 IntersectionObserver 配合列高缓存。CSS 方案只是视觉近似，别强求物理对齐。
