column-count仅能实现形似瀑布流，存在dom顺序错乱、可访问性缺陷及图片加载塌陷等硬伤；真瀑布流应优先采用grid+grid-auto-flow:dense方案，兼顾语义正确、响应式与现代浏览器兼容性。
新手直接用 column-count 最快能出效果，但会立刻遇到图片错位、tab顺序混乱、SEO不友好等问题——这不是“能跑就行”的小毛病，而是布局逻辑层面的硬伤，必须从一开始就知道它为什么不可靠。
用 column-count 搭出第一版照片墙（仅限快速验证）
它确实三行 CSS 就能铺开多列，适合本地 demo 或内部管理页这类对可访问性无要求的场景。
-
column-count: 3必须设在容器上，不能靠媒体查询切列数（多数浏览器不支持@media里改column-count） - 每个卡片加
break-inside: avoid（Firefox 还得补page-break-inside: avoid），否则长卡片会被截成两半 -
<img>默认是inline，底部有空白；必须写img { display: block; width: 100%; height: auto; } - 图片加载前高度为 0，会导致后续卡片全部上移——得用
aspect-ratio或padding-top占位，不能等 JS 补
为什么 grid + grid-auto-flow: dense 是更靠谱的起点
它不改变 DOM 顺序，语义清晰，键盘 tab 和屏幕阅读器都按 HTML 顺序走，且现代浏览器支持度已足够落地。
- 容器写
display: grid; grid-template-columns: repeat(auto-fit, minmax(280px, 1fr))); grid-auto-flow: dense; - 每张图必须有明确高度预期：用
aspect-ratio: 4/3（Chrome/Firefox/Safari 均支持）或padding-top: 75%+position: relative+img { position: absolute; top: 0; left: 0; width: 100%; height: 100%; } - 别给容器加
overflow: hidden，否则跨多行的高图会被裁掉 -
grid-auto-rows的值只是占位基准（比如设10px），实际高度由内容撑开，不影响布局逻辑
图片加载塌陷是所有方案共通的坑
无论用哪种布局，只要图片是异步加载的，首次渲染时高度为 0，就会导致卡片挤在一起或留大片空白——这不是 CSS 写错了，而是没预留空间。
- 服务端能预传宽高时，直接写
width和height属性，浏览器会自动算出aspect-ratio - 做不到就用
data-aspect-ratio="4/3"，再用 JS 读取后动态设style.aspectRatio（兼容性比纯 CSS 更稳） - 懒加载图片必须监听
load事件，而不是等DOMContentLoaded后统一排——用户看到的是空白容器，不是错位结果 - 绝对定位类库（如 Masonry）也依赖这个：没高度，
getBoundingClientRect()返回0，计算就全崩
真正容易被忽略的点不在“怎么让图片落下去”，而在“怎么让它们不跳”。DOM 顺序、加载时机、宽高占位这三件事没对齐，任何瀑布流都会在真实设备上闪一下、卡一下、或者读屏器念错顺序——这些不是后期优化项，是初始结构就得定死的约束。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
