“卡位”是column-count中浏览器对break-inside: avoid的保守处理所致，当卡片高度接近列剩余空间时强制整块移至下一列，造成顶部空白；常见诱因包括margin-bottom过大、图片延迟加载、容器height受限等。
为什么column-count布局里还会出现“卡位”？
这不是浮动的问题——column-count根本不用float。所谓“卡位”，其实是浏览器在多列分发时，对break-inside: avoid的保守处理：当某张卡片高度接近当前列剩余空间，浏览器宁可让它整块挪到下一列，也不愿冒险截断（哪怕它其实能塞下），结果就留下顶部空白、视觉上像被“卡住”了。
常见错误现象：margin-bottom没设或设得过大，导致列内卡片间距吃掉大量可用高度；图片加载延迟造成初始高度为0，分列逻辑按空盒子计算，等图一出来就撑开、触发重排错位；容器height被意外限制，压缩了列的自然伸展空间。
- 确保父容器没设
height或max-height，让它能随内容自由增长 - 把
margin-bottom统一收窄，比如margin-bottom: 0.5rem，避免单张卡片占满一列后留不出余量 - 给图片加
height: auto; max-width: 100%，并配合object-fit: cover防止拉伸变形 - 用
loading="lazy"属性延迟非视口图片加载，但关键首屏几张务必提前触发img.onload或用IntersectionObserver监听加载完成再渲染
break-inside: avoid失效时怎么补救？
这个声明在 Safari 旧版和部分安卓 WebView 中支持不稳，一旦失效，卡片就会被硬生生从中间劈开——上半截在第一列，下半截跳到第二列底部，形成真正意义上的“卡位断裂”。
解决不是靠加更多 hack，而是降级兜底：
立即学习“前端免费学习笔记（深入）”；
- 加
page-break-inside: avoid作为双保险（对打印样式无害，现代浏览器也认） - 给卡片加
display: inline-block或display: block，避免某些引擎把它当匿名文本节点处理 - 如果项目必须兼容 iOS 14 以下，直接放弃
column-count，切到display: grid+grid-auto-flow: dense方案，虽然不是严格瀑布流，但至少不会劈裂
响应式切换列数时为何突然错位？
媒体查询里只改了column-count，但忘了重置column-gap和卡片margin，导致小屏下间隙比例失衡；更隐蔽的是，列数变化瞬间，浏览器来不及重新分发已渲染的卡片，旧列残留+新列抢占，视觉上就像一堆卡片被“吸”到左上角堆叠。
关键动作不是等 resize 完再处理，而是主动干预分发节奏：
- 在
@media规则中同步调整column-gap，比如大屏2rem，平板降到1rem，手机用0.75rem - 用
window.matchMedia监听断点变化，在回调里触发一次container.style.columnCount = "auto"再立刻设回目标值，强制浏览器重排 - 避免在卡片内部用
position: absolute或transform，它们会让浏览器误判尺寸，加剧分列混乱
真瀑布流需求强烈时，column-count还能不能扛？
能，但只限于“视觉可接受”的场景。它不追踪列高、不插空、不重排序，纯靠浏览器内置分列算法——所以当卡片高度差异超过 3 倍（比如一张 200px 高的图和一张 600px 高的图混排），空白率会明显上升，尤其在列数≥4 时。
这时候别硬刚 CSS，该交棒给 JS：
- 保留
column-count做降级层（无 JS 时仍可读） - 用
Masonry库或轻量实现，只在document.readyState === "complete"后初始化，避开 DOM 渲染中途介入 - 重点监控
img.naturalHeight而非offsetHeight，避免加载未完成就取错高度
最常被忽略的一点：多列布局的column-fill: balance默认开启，但它在动态追加内容时不会自动重平衡——滚动加载新卡片，必须手动调用container.style.columnFill = "auto"再切回"balance"才能触发重分发。
