Bootstrap本身不提供真正瀑布流，.row+.col-*仅为等高行布局；实现需弃用.col类，改用CSS多列（column-count）或JS库（Masonry/Isotope），并严格处理图片加载与容器纯净性。
Bootstrap 本身不提供真正的瀑布流（Masonry）布局能力，所有基于 .row + .col-* 的写法都只是等高行式排列，不是按列“砌砖”。想实现视觉或行为上接近瀑布流的效果，必须绕开栅格系统的 Flex/float 逻辑——直接答案是：别用 .col 类参与布局计算，改用独立容器 + CSS 多列 或 JS 驱动的 Masonry/Isotope。
为什么 .row + .col-md-4 永远不是瀑布流
Bootstrap 的 .row 默认是 display: flex 容器，.col-* 是 flex item，高度由每行最高项决定。结果就是：中间卡片很高，左右留白；小卡片被拉伸或错位；DOM 顺序和视觉顺序不一致。这不是 bug，是设计使然。
-
row-cols-3只控制每行数量，不改变高度对齐逻辑 - 加
style="display: grid"到.row会破坏.col的宽度声明（如flex-basis: 33.333%与grid-template-columns冲突） - 哪怕把
.col改成width: calc(33.333% - 1rem)，也还是按行 wrap，不是按列堆叠
用 column-count 实现轻量视觉瀑布流
这是唯一不依赖 JS 的方案，但极易翻车——关键不在加不加属性，而在是否清除了 Bootstrap 的干扰。
- 容器必须是干净的块级元素，比如
<div class="masonry-container">，不能是 <code>.row或带.col的父级 - 子项用普通
<div>，删掉所有 <code>.col-*类，否则float/flex-basis会让多列失效 - 必须设
break-inside: avoid（iOS Safari 建议用avoid-column），否则卡片可能被截断在两列之间 -
column-gap才生效，gap-4或mb-3这类 Bootstrap 间距类会叠加出双倍间隙 - 图片必须预留高度：用 HTML
width和height属性，或统一加aspect-ratio: 16/9; object-fit: cover - 子项不能嵌套在
.col-*内部；正确结构是：<div class="item col-md-4"><div class="card">...</div></div>——.col-*仅作宽度参考，不参与布局 - 必须引入
imagesLoaded，且 Masonry 初始化必须包在它的回调里：$('.masonry').imagesLoaded(() => { $('.masonry').masonry({...}) }) -
columnWidth推荐传选择器，比如columnWidth: ".grid-sizer"，并在容器内放一个隐藏的<div class="grid-sizer"></div>，CSS 设为对应列宽（如width: calc(33.333% - 1rem)） - 响应式列数变化时，不能只改 CSS，必须手动调
masonry.layout()（例如监听window.matchMedia或 resize） - 开启
percentPosition: true，否则百分比宽度会被当像素值处理，导致错位 - 图片异步加载导致初始高度为 0，Masonry 或 column-count 都按错误高度排版；没有
imagesLoaded或aspect-ratio控制，就等于没做瀑布流 - 滚动位置恢复必须等 Masonry 渲染完成后再执行，
window.onload太早；应监听masonry.layoutComplete事件，或用setTimeout+requestAnimationFrame确保渲染队列清空 - iOS Safari 对
break-inside支持不稳定，旧版本仍需降级 fallback（比如@supports (column-count: 3)包裹样式，并准备单列备用）
用 Masonry.js 实现行为一致的真瀑布流
这是当前最稳、兼容性最好、响应式可控的落地方式。但初始化时机和 DOM 结构稍有偏差，就会重叠、错位、报 offsetTop 错误。
图片加载与滚动位置是两个最容易被忽略的硬伤
几乎所有“瀑布流跳闪”“卡片堆叠”“返回后滚回顶部”的问题，根源都在这两点。
