CSS瀑布流实现：column-count与grid技巧分享

、

等）会被当作连续内容切开，导致：

column-count: 3;

后，一个高卡片可能被劈成两半跨列显示——这在卡片含按钮、表单或 hover 效果时完全不可接受。

规避方法只有两个：
• 给每个子项加 break-inside: avoid;（注意 IE 不支持）
• 确保父容器有足够高度，否则末尾列可能留白严重
• 列宽由容器宽度 / column-count 自动计算，无法单独设列宽

grid auto-placement 配合 grid-auto-flow: dense 可控性更强，但需明确行高基准

CSS Grid 的 grid-template-columns + grid-auto-flow: dense 是更现代的解法，但关键点在于：它本身不产生“瀑布”效果，必须配合 grid-row-end: span X 或依赖内容自然撑高才能错落。常见误写：

display: grid;
grid-template-columns: repeat(3, 1fr);
grid-auto-flow: dense;

——这只会等高平铺，不是瀑布流。

真正起作用的是让每个 item 主动声明跨行数，例如：

.item:nth-child(1) { grid-row-end: span 2; }
.item:nth-child(2) { grid-row-end: span 3; }

或者用 JS 动态计算并设置 grid-row-end。纯 CSS 无 JS 时，只能靠内容高度自然差异触发 dense 填充，效果不稳定。

column-count 和 grid 在响应式切换时行为不一致，别混用媒体查询硬切

有人想「小屏用 column-count，大屏切 grid」，但两者渲染逻辑完全不同：
• column-count 下，DOM 顺序 = 渲染顺序（从上到下、从左到右填满一列再下一列）
• Grid dense 模式下，DOM 顺序 ≠ 渲染顺序（短 item 可能插进前面长 item 的空隙）
• 切换时视觉跳变明显，焦点管理、滚动锚点、SEO 顺序都可能出问题

如果必须响应式，建议：
• 全局统一用 Grid，并用 @container（需启用 container queries）做细粒度控制
• 或全链路用 JS 瀑布流库（如 masonry），保持行为一致
• 避免在同一个列表里对不同断点用不同 CSS 布局机制

真实项目中，纯 CSS 瀑布流仍受限于内容不可控性

当卡片内容来自 CMS、用户上传或异步加载，高度不可预知时：
• column-count 的 break-inside: avoid 只防劈裂，不防列高严重不均
• Grid 的 grid-auto-flow: dense 在大量短 item 时会把新 item 往前塞，导致 DOM 顺序和视觉顺序错位，影响可访问性和键盘导航
• 两者都不支持「某列加载更多」这种交互，需要额外 JS 调度

所以，除非内容高度较均衡、交互极简单、且兼容性要求覆盖到 Safari 14.1+，否则直接上 Masonry（CSS display: masonry）或 JS 库更省心。目前 display: masonry 已在 Chrome 116+、Firefox 119+ 原生支持，但 Safari 仍缺席。

理论要掌握，实操不能落！以上关于《CSS瀑布流实现：column-count与grid技巧分享》的详细介绍，大家都掌握了吧！如果想要继续提升自己的能力，那么就来关注golang学习网公众号吧！