真正可控的瀑布流间距需用column-count配合column-gap和break-inside: avoid，因column-gap由列容器统一分配，不依赖子项尺寸或断行位置，能确保列间物理间隔恒定。
瀑布流用float布局时，列间距为什么忽大忽小
根本不是margin写错了，而是浮动本身不构成二维轨道系统。当各列高度不一致（比如一张图高、一段文字短），后续浮动项无法上浮填补空缺，导致右侧出现不可控空白——你看到的“间距变大”，其实是布局流断裂后留下的视觉断层。
常见错误现象包括：三列瀑布流中，第二列很短，第三列却卡在第一列下方，和第二列之间拉开巨大空隙；或者滚动时某几行突然变疏，刷新后又恢复——这都是浮动高度不对齐触发的重排抖动。
- 每个浮动项的
margin-right确实生效了，但它只作用于自身盒模型，不协调行间对齐 - 父容器若没触发BFC（比如漏写
overflow: hidden或display: flow-root），高度塌陷会让margin被“吞掉”，加剧错位 -
gap在float容器里完全无效——浏览器直接忽略，别指望它能救场
为什么CSS Grid的gap在瀑布流里也不行
Grid 本身不支持真正的瀑布流（masonry）布局。目前只有grid-template-rows: masonry（Chrome 125+ 实验性支持）能原生实现，但gap在此模式下仍受限：它只控制行内间隙，无法约束跨行项之间的垂直距离。
如果你强行用grid-auto-flow: dense + grid-template-columns模拟瀑布流，gap看似生效，但一旦子项高度差异大，密集填充会把短项塞进长项下方空隙，造成上下项紧贴、左右项却隔很远——这不是gap失效，而是Grid轨道模型与瀑布流语义根本不匹配。
- 当前稳定方案中，
gap仅对规则网格有效；瀑布流必须依赖JS库（如Masonry、CSS Container Queries配合@container）或column-count - 用
column-count时，column-gap才真正可控，但它基于多列文本流，不支持跨列元素定位 - 别在Grid容器上写
gap还幻想它能“智能避让”高度不一的项——它不会
用column-count实现瀑布流时，间距为何仍不稳定
column-count是目前兼容性最好、行为最可预测的纯CSS瀑布流方案，但它的“不稳定”往往来自字体和行高干扰，而非列间隙本身。
问题核心在于：多列布局会把内容当作文本流切分，而line-height、font-size、甚至vertical-align都会影响每列末尾的断行位置。同一组元素，在Chrome里可能断在第3行底，在Safari里断在第4行中，导致各列实际高度偏差，视觉上就是“间距忽大忽小”。
- 务必给容器设
box-sizing: border-box，并确保*, *::before, *::after全部覆盖，否则伪元素撑开的像素差会被放大 - 避免在子项里用
height或min-height硬约束——它会破坏列内自然断行 - 图片记得加
vertical-align: top，否则默认baseline会引入不可见的底部间隙 - 测试时打开DevTools → Rendering → “Show layout shift regions”，能直接看到哪一列因断行偏移了
真正可控的瀑布流间距怎么做
放弃靠margin“调感觉”，转为用column-gap定义刚性间隔，并用break-inside: avoid守住关键元素不被劈开。
这是目前唯一能在不引入JS的前提下，让瀑布流间距保持物理一致的做法：间隙由列容器统一分配，不依赖子项尺寸，也不受断行抖动影响。
- 父容器设
column-count: 3; column-gap: 20px;，所有间距逻辑就锁死了 - 每个瀑布流项加
break-inside: avoid;，防止标题+图片被切到两列 - 若需响应式，用
@container配合container-type: inline-size动态改column-count，比媒体查询更精准 - 别给子项设
margin-bottom——它会在列内叠加，导致实际间隙变成column-gap + margin-bottom
最容易被忽略的一点：所谓“瀑布流间距稳定”，从来不是指所有项看起来等距，而是指列与列之间的物理间隔恒定。只要column-gap值不变，哪怕某列多出半行文字，那20px的空白始终存在——这才是可控的底线。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
