纯CSS无法实现真正按列高动态分配的瀑布流；column-count按文档流顺序分栏，grid靠dense+auto-fill模拟视觉错落，二者均需JS补足高度动态计算与可访问性缺陷。
纯 CSS 能实现瀑布流，但效果取决于你对“真实瀑布流”的定义——column-count 方案能快速出效果，但元素按列顺序填充；grid 方案视觉更可控，但需配合 JS 才能真正按高度动态分配。
用 column-count 实现最简瀑布流（兼容性好）
这是浏览器原生支持的多列布局，适合图片宽度一致、高度不一的场景。它不计算元素高度，而是从上到下填满第一列，再填第二列……所以新数据会集中在左侧，阅读顺序反直觉。
-
break-inside: avoid必须加在子项上，否则图片可能被硬生生截断到两列之间 -
column-gap控制列间距，但无法控制行间距，垂直间隙只能靠子项margin-bottom模拟 - 响应式时别只改
column-count，也要同步调小column-gap和margin-bottom，否则小屏上间隙过大 - IE10+ 支持，移动端 Safari 从 iOS 9.3 开始支持，基本无兼容风险
用 grid + span 模拟瀑布流（视觉更稳）
这不是真正的 Masonry 布局（CSS Grid 本身不支持按列高自动放置），但通过固定基础行高 + 动态 grid-row-end: span N，能模拟出接近效果。关键在于：你得提前知道每张图的高度。
-
grid-auto-rows设为一个较小值（如10px），后续用span计算跨行数：span calc(var(--height) / 10) -
grid-template-columns: repeat(auto-fill, minmax(250px, 1fr))让列数随容器自适应，但注意minmax()第二个参数用1fr会导致列宽不均，建议统一用minmax(250px, 250px)或直接写死像素值 - 图片加载完成前，
offsetHeight读不到真实高度，必须监听load事件后再计算并更新style中的grid-row-end - 若后端能返回图片宽高，优先用服务端预计算，避免客户端反复测量
微信小程序里别用 column-count
小程序 WebView 对多列布局支持极差，column-count 在 iOS 微信中常失效，安卓表现也不稳定。强行用会遇到子项错位、截断、列数不生效等问题。
立即学习“前端免费学习笔记（深入）”；
- 推荐双列 JS 分流：维护
leftHeight和rightHeight两个变量，每次把新卡片推入较短列 - 务必要求后端返回图片原始宽高，否则 JS 无法准确预估高度，懒加载 + 骨架屏要同步占位
- 用
display: flex; flex-wrap: wrap+flex-basis是伪瀑布流，仅适用于等宽卡片，图片会被拉伸或留白
真正按列高自动分配的瀑布流，目前仍需 JS 驱动。CSS 方案本质是“视觉模拟”，容易忽略图片加载时机、字体回流、缩放重排这些细节——它们不会报错，但会让瀑布流在某些设备上突然错行几像素。
