column-count 是当前最轻量可控的纯 CSS 瀑布流方案，但需配合 break-inside: avoid、column-gap 双前缀、column-fill: balance 及列数阶梯式响应式调整，否则易出现截断、列高不齐等问题。
column-count 能做响应式瀑布流，但必须配合 break-inside: avoid、column-gap 和媒体查询阶梯降级，否则小屏下文字被截断、图片被砍半、列高严重不齐是常态；grid 本身不支持真瀑布流，所谓“Grid 瀑布流”只是等宽多列换行布局，视觉近似但逻辑完全不同。
为什么直接写 @media (max-width: 768px) { .masonry { column-count: 1; } } 会出问题
浏览器按文档流顺序把内容“切段”填入列，不重排、不挪动 DOM。如果一个高卡片刚好被切在第二列开头，那第二列就会明显高出一截——column-count 不平衡列高，只管分段。
- 所有卡片容器必须加
break-inside: avoid（或break-inside: avoid-column），防止跨列断裂 - 图片必须用
aspect-ratio+object-fit: cover控制比例，不能依赖原始尺寸 - 禁用
position: absolute、float或display: contents，它们会让元素脱离文档流，column布局直接失效 - 移动端优先：从
column-count: 1起步，往上加（2 → 3 → 4），不是往下减
column-gap 在 Safari 和 Firefox 中的兼容性陷阱
column-gap 在 Chrome 表现稳定，但在 Safari 15.4 之前不支持独立属性，Firefox 则对 column-fill: balance 更友好但默认是 auto，容易导致最后一列空荡荡。
- 必须写双前缀：
-webkit-column-gap: 1rem和column-gap: 1rem - 显式声明
column-fill: balance，尤其内容少时能显著改善列高一致性 - 别信 Can I Use 上“支持”的标绿，要实测 iOS 15.6 / macOS Monterey Safari 渲染效果
- 避免混用
column-width和column-count，二者同时存在时浏览器优先按column-width计算列数，可能意外变成 2.5 列
用 grid 模拟“类瀑布流”时的真实限制
CSS Grid 的 grid-template-columns: repeat(auto-fill, minmax(300px, 1fr)) 只能实现等宽多列换行，每行高度取该行最高项，不是真正的 Masonry 瀑布流——它无法让第 5 个元素自动落到第 1 列第二行空白处。
- 适合场景：卡片结构规整、高度差异不大、无需拖拽/无限加载的列表（如博客归档、标签云）
- 不适合场景：图片高度差异大、需动态插入、要求列高视觉均衡的画廊类页面
- 若强行用
grid+grid-auto-flow: dense配合grid-row: span X手动控制，维护成本极高且响应式断点一变全乱 - 真正需要 Masonry 行为时，
column-count仍是当前最轻量、最可控的纯 CSS 方案
最易被忽略的一点：列数变化时，column-gap 必须同步调整，否则小屏下 1 列却保留 2rem 间隙，左右留白突兀；而大屏下 4 列若仍用 0.5rem 间隙，密集压迫感强。间隙值不是固定常量，它和列数、内容密度强相关。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
