columns才是真瀑布流，因其原生支持按内容自动分列、自适应填充，无需JS且语义正确；grid无法原生实现动态高度列填充，“Grid瀑布流”或是伪解法，或仅限最新Chromium实验性支持。
纯 CSS 实现真正意义上的瀑布流，columns 是目前唯一可靠、语义正确、无需 JS 补位的方案；grid 当前无法原生支持动态高度列填充，所谓“Grid 瀑布流”基本是伪解法，或仅限最新 Chromium 内核实验性支持。
为什么 columns 才是真瀑布流
columns 是浏览器原生为文本流设计的多列机制，按内容长度自动切分、按列高自适应填充，天然满足“等宽不等高、填满最短列”的瀑布流行为。它不要求 DOM 顺序与视觉顺序一致，也不依赖预设高度——这对图片异步加载、字体渲染延迟、响应式重排都至关重要。
常见错误包括：
- 漏写
break-inside: avoid（或旧版break-inside: avoid-column），导致长卡片被硬截断跨列显示 - 用百分比设
column-gap，某些 Safari/Chrome 版本解析不稳定，推荐用rem或px - 未显式声明
column-fill: auto，虽默认值如此，但部分旧引擎在 resize 后可能回退到balance模式造成错位
最小可用代码：
立即学习“前端免费学习笔记（深入）”；
.masonry {
columns: 3;
column-gap: 1.5rem;
column-fill: auto;
}
.masonry > * {
break-inside: avoid;
}
为什么 grid 模拟瀑布流是伪解法
标准 CSS Grid 不支持“将下一个元素插入当前最短列”这一逻辑。所谓“Grid 瀑布流”实际是以下两种情况之一：
- 用
grid-template-columns: repeat(3, 1fr)+grid-auto-rows强制等高行 → 结果是垂直滚动网格，不是瀑布流 - 靠 JS 计算每列高度、动态插入最短列 → 已脱离纯 CSS 范畴，且存在竞态：图片加载完成前高度为 0，JS 补位错乱
实验性写法 grid-template-rows: masonry 目前仅 Chrome 117+ 启用，需同时满足：
display: gridgrid-template-rows: masonrygrid-auto-flow: dense- 父容器不能有
overflow: hidden（会截断定位）
该特性在 Firefox、Safari 中完全不可用，生产环境无法兜底。
columns 的兼容性与响应式适配要点
columns 在 Safari 14.1+、Firefox 91+、Chrome 102+、iOS Safari 15.4+ 均稳定支持。最大限制是无法精确控制单列宽度——column-width 是建议值，浏览器会根据 column-count 自行权衡。
响应式建议：
- 小屏（
max-width: 768px）用column-count: 1或columns: 1 - 中屏用
columns: 2，大屏用columns: 3或columns: 4 - 避免在媒体查询中混用
column-width和column-count，易触发浏览器重排抖动
注意：columns 对子项的 margin、padding 敏感，若卡片内有浮动或绝对定位元素，需额外加 contain: layout 防止溢出干扰列平衡。
什么时候必须上 JS 瀑布流
当需求超出 columns 能力边界时，才考虑 JS 方案，典型场景包括：
- 需要拖拽排序、实时增删项，且要求视觉位置立即响应（
columns重排有延迟） - 列宽必须严格等于某像素值（如 280px），且不允许浏览器微调
- 要实现“吸附最短列 + 动画过渡”效果（
columns无动画钩子） - 服务端渲染首屏需保证列高视觉均衡（
columns首屏可能因字体加载延迟出现错位）
此时应优先用轻量库如 masonic 或 react-virtualized-masonry，而非手写高度计算逻辑——DOM 查询 + getBoundingClientRect() 在长列表下性能极易崩。
真正容易被忽略的是：columns 的“真瀑布流”优势只在内容自然流式、不强求列间像素级对齐时成立；一旦你开始用 JS 强控位置，就已放弃其原生语义和可访问性收益，不如直接换方案。
