column-count 是当前唯一浏览器原生支持、滚动零重排、无需 js 即可稳定工作的瀑布流方案，因其专为内容流式切分设计，能自动均分列高并避免跨列断裂。
纯 CSS 实现“高性能瀑布流定位布局”根本不存在——position: absolute 需 JS 动态算 top，grid-auto-flow: dense 不解决列高平衡，column-count 才是目前唯一浏览器原生支持、滚动零重排、无需 JS 即可稳定工作的方案。
为什么 position: absolute 算不准 top
浏览器不维护“前一张卡片底部位置”这个状态。你写 top: 200px，它就真只按 200 像素放；一旦某张卡片因图片加载、字体渲染或响应式缩放导致高度变化，后续所有硬编码的 top 全部错位。
- 必须给父容器加
position: relative，否则absolute元素会相对于视口定位，直接飞到左上角 -
margin-top和top混用极易叠加偏移，且无法响应内容高度突变 - 靠 JS 读取
offsetTop + offsetHeight累加计算虽可行，但每次 DOM 变更都要重跑，长列表下触发强制同步布局（Layout Thrashing），性能断崖式下降
为什么 grid-auto-flow: dense 不是瀑布流
它只回填被显式跳过的空网格单元（比如你设了 grid-row: 3 / span 1 但第 2 行空着），前提是所有项行高固定。而瀑布流要求每项高度不同、且能自动“下坠”到当前最短列——Grid 的 track 是静态划分的，dense 不会重算列高，也不移动已定位元素。
- 删掉
grid-auto-flow: dense反而更可控：用grid-column显式指定列，再配合 JS 计算grid-row-start -
grid-template-rows: masonry是真·原生瀑布流，但仅 Chrome 116+ 和 Safari 17.4+ 支持，且需@supports (grid-template-rows: masonry)守卫 - 用
grid-auto-rows: 1px+grid-row-end: span N模拟，本质是把高度转为“行数”，但 N 必须由 JS 提供，仍绕不开计算开销
为什么 column-count 是当前最稳方案
它是唯一被浏览器排版引擎原生支持的分栏机制，专为“内容流式切分”设计。浏览器内部会测量每张卡片高度，按列高大致均分内容，并自动避免跨列断裂——这正是瀑布流的核心诉求。
- 只对块级子元素生效，
break-inside: avoid在 Firefox/Chrome 稳定，在 Safari 有轻微偏差，IE10+ 全支持 - 不能嵌套
flex或grid子项，否则break-inside失效；适合纯卡片（div包裹图片+文字）结构 - 滚动时几乎无重排，比 Grid 方案帧率更稳；搭配
contain: layout style可进一步隔离样式影响 - 响应式只需改
column-count值 +column-gap，无需 JS 干预
真正难的不是“怎么写 CSS”，而是接受一个事实：浏览器没给瀑布流留出纯 CSS 的通用解。你选 column-count，就得接受它对子元素类型的限制；你选 Grid + JS，就得承担动态计算和重排成本；你信 masonry，就得守着兼容性边界做降级。没有银弹，只有权衡点在哪。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
