<p>Bootstrap 5 的 row-cols-* + col 无法实现真正瀑布流，因其强制等高导致错位塌陷；推荐用 CSS column-count（轻量响应式）或 Masonry JS 库（灵活可控），并注意 break-inside、图片适配及 iOS 兼容性问题。</p>
用 Bootstrap 5 的 row-cols-* + col 实现基础瀑布流？不行，别试
bootstrap 原生不支持真正的瀑布流（masonry），row-cols-* 只是等高栅格，所有子项会被拉平到同一行高度，视觉上是“砖墙”而非“瀑布”。你看到的错位、留白、高度塌陷，基本都源于误用这个组合。
实操建议：
- 放弃用
row+col拼瀑布流，它不是设计来干这事的 - 若内容高度差异小、可接受轻微错位，可用
display: flex; flex-wrap: wrap;配合固定宽 +min-height模拟，但不算真瀑布流 - 真正要响应式瀑布流，得靠 CSS
column-count或 JS 库，Bootstrap 只负责容器和断点
CSS column-count 是最轻量的响应式瀑布流方案
不用引入 JS，兼容性够用（Chrome 50+、Firefox、Safari 14.1+、Edge 79+），且能自动响应 max-width 断点变化。核心是把容器设为多列流，子项按文档流自然填入各列。
常见错误现象：子项被截断、图片错位、内边距失效 —— 多半因为没重置 break-inside 或忘了处理 img 的默认行为。
实操建议：
- 容器加
column-count: 3;和column-gap: 1rem; - 每个子项必须设
break-inside: avoid;，否则文字或卡片可能被硬生生劈成两半 -
img标签要加width: 100%; height: auto;，否则在 column 布局下容易溢出或比例失真 - 用
@media控制column-count：比如@media (max-width: 768px) { column-count: 1; }
article {
column-count: 3;
column-gap: 1rem;
}
article > div {
break-inside: avoid;
margin-bottom: 1rem;
}
article img {
width: 100%;
height: auto;
}用 Masonry JS 库时，Bootstrap 的栅格类要全删掉
一旦引入 masonry（比如官方库 masonry-layout 或 vanilla-masonry），就别再给子项加 col-md-4 这类类名 —— 它们会干扰 JS 计算位置，导致重叠、错位或初始化失败。
使用场景：需要精确控制子项宽度、支持图片懒加载、或子项含动态内容（如折叠面板）。
实操建议：
- 容器只保留
data-masonry='{"percentPosition": true}'，不要加row - 子项用纯语义化标签（如
article），宽度由 CSS 控制（例如width: calc(33.333% - 1rem);） - 初始化前确保图片已加载，否则高度计算错误；可用
imagesLoaded插件配合masonry - 响应式切换列数时，必须调用
masonry.layout()重排，不能只改 CSS
移动端 Safari 上 column-count 的兼容性坑
iOS 15.4 之前，column-count 在 Safari 中对 position: sticky、transform 或某些 flex 子项有渲染 bug，表现为列间空白异常扩大或子项消失。这不是 Bootstrap 的问题，但你会在用它做响应式时撞上。
性能影响：相比 JS 方案，column-count 渲染更快，但无法监听单个子项进入视口，做懒加载或动画需额外处理。
实操建议：
- 测试务必覆盖 iOS 15.0–15.3，必要时用
@supports not (column-count: 2)降级为单列 - 避免在 column 容器内嵌套
position: relative的复杂定位结构 - 如果项目必须支持老 iOS 且要瀑布流，JS 方案反而更可控，别硬扛 CSS
真正难的不是写几行代码，是判断该用哪条路 —— 纯 CSS 快但受限，JS 灵活但要管生命周期。很多人卡在中间：既没清掉 Bootstrap 的栅格类，又没配好 break-inside，结果调半天发现只是样式冲突。
