纯Bootstrap栅格无法实现真正响应式图片瀑布流，必须用column-count或Masonry库；前者需严格控制样式防断行，后者须剥离栅格类并配合imagesLoaded确保图片加载后布局。
纯 bootstrap 栅格（row+col）做不到真正响应式图片瀑布流，它只会等高拉平、留白错位；要视觉连续、高度自适应的瀑布效果，必须跳出栅格逻辑——要么用 column-count 配合严格样式控制，要么上 masonry 类 js 库，二者选其一，没有折中。
为什么 row+col 不能当瀑布流用
Bootstrap 的 row 本质是 flex 容器，col 是 flex 项目，所有子项会被强制拉到同一行高度。哪怕你写 col-md-4，只要某张图高、某张图矮，就会出现“楼梯状”错位或底部大片空白——这不是 bug，是设计使然。
- 常见错误现象：
Uncaught TypeError: Cannot read property 'offsetTop' of undefined（混用 Masonry 时）或卡片堆叠、列间高度差明显 - 别指望
row-cols-*类能救场，它只是给每列加flex: 1和min-height，依然无法解决跨行高度不对齐问题 - 如果内容高度差异小、且允许轻微错位，可临时用
display: flex; flex-wrap: wrap;+ 固定卡片宽 +min-height模拟，但不推荐用于图片为主的内容
用 column-count 实现轻量瀑布流（无 JS）
column-count 不是真 Masonry，但对多数图片卡片列表够用，兼容性覆盖 Chrome 50+、Firefox、Safari 14.1+、Edge 79+，关键是要堵住几个渲染漏洞。
- 容器必须设
column-count: 3和column-gap: 1rem（别用 Bootstrap 的g-*类，它对多列无效） - 每个卡片（如
.card或figure）必须加break-inside: avoid，否则图片和标题可能被硬切到两列 -
img标签务必设width: 100%; height: auto;，否则在列布局下易溢出或比例失真 - 响应式切换列数必须用媒体查询：
@media (max-width: 768px) { .container { column-count: 1; } }，不能靠col-sm-6这类类名模拟 - iOS Safari 15 及更早版本对
break-inside支持不稳定，可降级为break-inside: avoid-column并加max-width: 100%双保险
用 Masonry 实现真实瀑布流（推荐方案）
Masonry（或 Isotope）是当前最稳路径，但必须彻底剥离 Bootstrap 栅格类，否则 JS 计算位置时会因 flex-basis、margin、float 干扰而重叠错位。
- 容器只保留语义化结构，比如
<div class="masonry">，删掉所有row和col-*类 - 子项用纯标签（如
<article>或<div class="item">），宽度由 CSS 控制：width: calc(33.333% - 1rem); -
imagesLoaded不是可选插件——必须等图片加载完成再初始化 Masonry，否则读到的高度全是 0，结果就是卡片堆叠、漏排 - 初始化写法示例：
$('.masonry').imagesLoaded(() => { $('.masonry').masonry({ itemSelector: '.item', percentPosition: true }); }); - 响应式列数变化时，不能只改 CSS，必须手动调用
masonry.layout()触发重排
容易被忽略的细节：图片加载与移动端兼容
瀑布流最脆弱的环节不是布局逻辑，而是图片加载时机和 Safari 渲染行为。服务端返回的 HTML 若含未加载完的 img，JS 就会按默认高度（0 或 1px）计算位置；iOS Safari 对 column-count 的 break-inside 支持仍存在抖动，尤其在页面滚动后触发重绘时。
真正落地时，得把 imagesLoaded 当成必选项，而不是“有空再加”的优化项；若项目需支持 iOS 15 以下设备，column-count 方案慎用，直接上 Masonry + imagesLoaded 是唯一稳妥选择。
