column-count是轻量兼容的伪瀑布流方案，本质为内容流式切分而非真Masonry，需设容器高度、子项加break-inside: avoid防截断，并依赖aspect-ratio等预留图片空间以避免闪跳。
纯 CSS 多列布局（column-count）能快速实现视觉近似的瀑布流，但它不是真正按“最短列优先”分配元素的瀑布流——它只是把内容当作文本流切分，DOM 顺序和视觉顺序一致，但列高均衡依赖浏览器自动重排，且无法响应图片加载后的高度变化。
为什么 column-count 常被误用却看似有效
它在静态、图片宽高比稳定、无 JS 动态插入的场景下“看起来像瀑布流”，是因为浏览器会尽量让各列总高度接近。但本质仍是文档流折行，不是列级调度：
-
column-count: 3不代表永远显示 3 列——若容器太窄或字体渲染异常，可能退化为 1 列 - 没设
max-height或height时，多列布局可能完全失效（表现为单列垂直堆叠） - 子项用了
display: flex、position: absolute或float，立刻脱离文档流，列切分逻辑失效 - DOM 顺序 = 渲染顺序，无法让第 5 个 item 跳去第 2 列底部补空——这和真实 Masonry 行为完全不同
break-inside: avoid 必须写全，且要兼容老浏览器
漏写或写错这个声明，卡片会被硬生生从中间劈开（尤其文字多、图片少的卡片），这是最常翻车的点：
- 标准写法：
break-inside: avoid - Firefox 需补：
-moz-break-inside: avoid - iOS Safari 13 及更早需补：
-webkit-column-break-inside: avoid - 别写成
break-inside: avoid-column（无效值，CSS 会静默忽略） - 该声明必须加在直接子元素上（即每个
.item），不能只加在容器上
图片加载闪跳怎么防：靠 aspect-ratio + 容器占位
图片异步加载前高度为 0，会导致内容提前掉进下一列，等图一出来就“啪”地跳回原列——用户看到的就是明显闪跳：
html-to-pptx-converter
下载
使用 PptxGenJS 和 Python 解析，将结构化的 HTML/CSS 幻灯片内容转换为原生、可编辑的 PowerPoint（.pptx）演示文稿。
立即学习“前端免费学习笔记（深入）”；
- 给每个
.item设置aspect-ratio: 4/3（或你实际用的宽高比），强制预留空间 -
.item img写成width: 100%; height: 100%; object-fit: cover;，避免拉伸 - 禁用
.item { height: ... }固定高——它会锁死列高计算，导致后续卡片错位 - 不要用
margin-bottom模拟间隙，改用column-gap；否则 margin 折叠会让列高估算失准
响应式切换列数时，别用同一 class 写两套逻辑
媒体查询里对同一个 class 同时定义 display: grid 和 column-count，会触发渲染引擎冲突——Grid 的 grid-auto-rows 和 column 的高度计算机制互斥，结果常是高度塌陷或列数少一列：
- 正确做法：用两个 class 分离，例如
.waterfall-grid和.waterfall-column - 用
@media控制显隐：.waterfall-column { display: block; }，.waterfall-grid { display: none; } - 如果项目必须支持 iOS 16.4 及更早，
column-count是唯一稳妥 fallback；但别指望它和 Grid 共存于同一选择器 - 真要动态插入新 item？
column-count无法感知，必须 JS 触发document.body.offsetHeight++强制重排（不推荐）或换 Masonry 库
真正难的不是写对那几行 CSS，而是守住「容器约束」和「子项流式语义」这两条线——一旦加了 position: relative、transform 或 JS 改了 innerHTML，整个多列布局就可能瞬间退化。它是个脆弱但轻量的方案，用就得守它的规矩。
