column-count 直接生效的前提是容器必须有明确高度限制或内容足够长；否则因按自然流排版，内容未超出容器高度时不会触发分栏。
column-count 直接生效的前提是什么
多数人写完 column-count: 3 没反应，第一反应是“CSS 不生效”，其实更可能是容器没满足基本条件：必须有明确的高度限制或内容足够长才能触发分栏。浏览器默认按自然流排版，若图片总高度小于容器高度，column 就不会拆——它不是“强制等高分栏”，而是“按内容流切片”。
实操建议：
- 给父容器加
height（如height: 600px）或max-height，配合overflow: hidden观察是否分栏出现 - 确保子元素（
<img>）没有设置display: block以外的干扰样式（比如float、position: absolute） - 图片需有明确宽高或通过
aspect-ratio控制比例，否则可能因高度塌陷导致列高严重不均
图片高度不一致时 column-layout 的真实表现
column-count 不会重排或拉伸元素，只是把内容流从上到下切成若干列，每列内部仍保持文档流顺序。这意味着：如果前几张图特别高，某一列就会“吃掉”大量垂直空间，后面图片被迫挤到下一列开头，造成视觉上的“断层”和底部参差。
常见错误现象：
立即学习“前端免费学习笔记（深入）”；
- 最后一列明显短一截，甚至空着
- 相邻列之间有巨大空白（尤其在小屏幕下）
- 滚动时某列突然“跳动”，因为新图片被塞进最短列（但 column-count 本身不支持这种智能分配）
这不是 bug，是 column 布局的本质限制——它适合文字流，不适合等高卡片。真要视觉均衡，得换方案（见下一条）。
Article To Html
下载
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
为什么你该考虑 CSS grid + Masonry 而不是死磕 column-count
Chrome 116+ 和 Safari 18.0+ 已支持 display: grid 配合 grid-template-rows: masonry，这才是语义正确、行为可控的瀑布流。而 column-count 在响应式切换列数时，会重排整个流（从第一张图开始重新切片），用户滚动位置丢失，且无法单独控制某张图跨列。
对比关键点：
-
column-count：纯流式切片，无列对齐，不支持break-inside: avoid稳定单图完整性（某些浏览器仍会把一张图劈成两半） -
grid-template-rows: masonry：每项独立定位，自动填入最短列，支持grid-row: span 2手动控制大图，滚动锚点稳定 - 兼容性兜底：可用
@supports not (grid-template-rows: masonry)回退到column-count，但别把它当主力
column-count 真正适用的场景和最小可行代码
它适合内容以阅读为主、高度差异小、且无需交互对齐的轻量展示，比如博客侧边图集、标签云缩略图墙、或作为降级 fallback。以下是最简可靠写法：
.waterfall {
column-count: 3;
column-gap: 1rem;
column-fill: auto;
}
.waterfall img {
width: 100%;
break-inside: avoid;
margin-bottom: 1rem;
}
注意三个关键配置：
-
column-fill: auto：避免浏览器默认的“平衡列高”逻辑（它会预估内容并强行拉伸间隙，导致更大错位） -
break-inside: avoid：防止图片被跨列截断（但 IE 和旧 Safari 不支持，需用 JS 补充） -
margin-bottom必须设在img上，而不是用column-gap控制垂直间距——后者只作用于列之间，不影响列内元素间距
真正难的不是写出来，而是判断该不该用。只要设计稿里写了“各列底部对齐”或“点击放大后不跳视口”，就别碰 column-count。
