纯 CSS 瀑布流受限于内容不可控性：column-count 会劈裂卡片且不支持 item 交互，Grid 需手动设跨行或依赖内容高度，响应式切换易导致视觉跳变与 DOM/渲染顺序不一致，真实项目推荐 Masonry 或 JS 库。
column-count 实现瀑布流时内容会被强制分段，但不支持 item 级交互控制
用 column-count 做瀑布流最简单，浏览器原生支持，无需 JS。但它本质是「文本流分栏」，所有子元素（<div>、<code><p></p> 等）会被当作连续内容切开，导致：
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;<br>grid-template-columns: repeat(3, 1fr);<br>grid-auto-flow: dense;——这只会等高平铺，不是瀑布流。
真正起作用的是让每个 item 主动声明跨行数，例如：
.item:nth-child(1) { grid-row-end: span 2; }<br>.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 仍缺席。
