column-count 实现瀑布流更快落地，因其是原生文档流分栏机制，无需计算列高、不依赖子项顺序、不触发重排，仅三行 css 即兼容主流浏览器；而 grid 需显式定义轨道、处理自动填充逻辑，易出现留白、参差、响应式错乱等问题。
用 column-count 实现瀑布流，为什么比 Grid 更快落地
因为 column-count 是文档流原生分栏机制，不需要计算列高、不依赖子项顺序、不触发重排，写三行 CSS 就能跑通主流浏览器（Chrome 50+、Firefox、Safari 14.1+、Edge 79+）。Grid 则必须显式定义行/列轨道、处理 grid-auto-flow: dense 和 grid-row-end 等复杂规则，稍有不慎就卡在“等高对齐”或“留白断裂”上。
常见错误现象：Grid 布局下卡片高度差异大时，底部参差、中间大片空白、小屏列数跳变 —— 这不是你没写对 grid-template-columns，而是 Grid 本质不支持“按内容自然填满列”的瀑布逻辑。
-
column-count按文本流顺序逐个填入各列，天然适配不等高卡片 - Grid 必须靠
grid-auto-rows预设行高，或用 JS 动态注入grid-row，否则无法真正“错落” - 响应式切换时，
column-count只需改一个值；Grid 要同步调整grid-template-columns+grid-auto-rows+ 断点内所有子项的grid-column
break-inside: avoid 不加，卡片就会被硬劈开
这是 column-count 方案里最常被忽略、也最致命的一条规则。不加它，浏览器会把单个 <div class="item"> 从中间截断，上半截在第一列、下半截掉到第二列 —— 尤其当卡片含文字段落或嵌套结构时，视觉完全崩坏。
<p>实操建议：</p>
<ul>
<li>必须给所有直接子项加 <code>break-inside: avoid;（Firefox 需额外加 -moz-break-inside: avoid;）
break-inside，得补 -webkit-column-break-inside: avoid;
<card></card>），确保样式作用在最外层 DOM 节点上，而不是包裹 div
column-width 别当响应式主力，它根本不可控
很多人想用 column-width: 300px 配合 column-gap 让浏览器自动算列数，结果在 768px 宽度下有时出 2 列、有时出 3 列，设计预期全乱。因为 column-width 是“建议宽度”，最终列数由容器宽度 ÷ (列宽 + 间隙) 向下取整决定，且受字体渲染、缩放比例等隐式因素干扰。
正确做法是放弃 column-width 主控，改用 @media 显式声明 column-count：
@media (max-width: 768px) {
.masonry { column-count: 2; }
}
@media (max-width: 480px) {
.masonry { column-count: 1; }
}
注意：别在媒体查询里混用 column-width 和 column-count，二者冲突会导致行为未定义。
图片溢出、比例失真？width: 100% 是唯一解
瀑布流里图片默认按原始尺寸渲染，在多列环境下极易撑破列宽、拉伸变形、或因 max-width 未生效而横向滚动。这不是图片本身问题，是 column 布局下 <img> 的盒模型行为未重置。
必须为所有内部 <img> 加：
-
width: 100%;（强制占满当前列宽） -
height: auto;（保持原始宽高比） - 避免设
max-width: 100%单独使用 —— 它只限制上限，不触发缩放，width: 100%才是主动拉伸指令
如果图片是背景图（background-image），则需配合 background-size: cover 和 aspect-ratio 控制，但语义和可访问性会下降。
真正难的不是写对那几行 CSS，而是记住：column-count 不是栅格，它不承诺列宽一致、不控制子项基线、也不提供跨列对齐能力。一旦开始想“让第 2 列第 3 个卡片和第 1 列第 5 个对齐”，就该切到 Masonry JS 方案了。
