column-count 是最轻量兼容的纯 CSS 瀑布流方案，但属列式分段而非真 Masonry；渲染按内容流从上到下、从左到右切分，不感知子元素边界，且依赖 break-inside: avoid 防截断。
column-count 是目前最轻量、兼容性最好的纯 CSS 瀑布流实现方式，但它不是“真 Masonry”，而是基于内容流的列式分段 —— 适合静态内容、图片画廊或 CMS 后台预渲染场景；动态加载、高度频繁变化或需精确控制排序时会出问题。
为什么 column-count 渲染顺序是“从上到下、从左到右”而非“找最短列”
它本质是把整个容器内容当作一段连续文本切分，浏览器按列高自动折行，不感知子元素边界。所以第 1 张图可能在第 1 列顶部，第 2 张图紧接其后——哪怕第 2 列此时还空着。
- 子元素必须是文档流内联级或块级（
display: block或默认），float、position: absolute会让它脱离分栏逻辑 - 所有子元素共享同一内容流，无法跨列对齐顶部，也无法按列独立设置
justify-content - 如果某张图加载慢或失败，后续内容会整体下移，造成视觉断层
break-inside: avoid 必须加，但 IE/旧 Safari 不支持
没有它，高图会被硬生生截成两半，分别出现在上下两列 —— 这是 column-count 最典型的破绽。
- 现代浏览器写
break-inside: avoid即可；Firefox 需加-moz-break-inside: avoid - IE10–11 只认
page-break-inside: avoid，但仅对打印生效，页面渲染无效 - 替代方案：用
display: inline-block+vertical-align: top模拟，但失去列间隙自动计算能力
响应式列数切换要配合 column-width，不能只靠媒体查询改 column-count
单纯用 @media (max-width: 768px) { .grid { column-count: 2; } } 容易导致小屏下最后一列严重留白，因为列宽被固定为容器宽度 / 列数，而图片本身有最小宽度约束。
- 更稳的做法是设
column-width: 280px+column-gap: 1rem，让浏览器自动算列数（至少 1 列） - 加
width: 100%到子项，避免子项宽度撑破列宽 - 若需强控列数（如始终 3 列），则必须配合 JS 监听
resize并重设column-count，否则窗口拖拽时列数不会实时更新
图片高度不均时，底部留白不可控，且无法监听“最后一行是否填满”
column-count 不提供布局完成回调，也不暴露列高信息。当你想在底部加“加载更多”按钮，或判断是否已滚动到底，只能靠估算或额外 DOM 查询。
- 常见误判：用
container.scrollHeight - window.innerHeight ，但在列高差异大时误差可达数百像素 - 真实列高需遍历所有子元素并累加
offsetHeight + margin-bottom，但这个值受column-gap和容器 padding 影响，无直接 API 获取 - 若内容含异步加载图片，务必等
img.onload后再触发重排检测，否则高度统计失效
真正需要 Masonry 行为（比如电商商品卡片、社交 feed）时，column-count 只能当降级方案；优先考虑 display: grid 配合 grid-template-rows: masonry（Chrome 116+ 支持），或引入 css-masonry polyfill —— 但别指望它在 Safari 上跑得顺。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
