用 isotope 做图片瀑布流最靠谱，它支持真实 Masonry 布局，兼容 Bootstrap、响应式重排且不破坏 DOM 顺序；需配合 imagesLoaded 确保图片加载完成后再布局，避免高度计算错误。
用 isotope 做图片瀑布流最靠谱
原生 bootstrap 不支持真正意义上的瀑布流（masonry layout），col-* 栅格只是等宽分列，图片高度不一就会留白错位。想靠纯 css + bootstrap 实现，目前只有 column-count 这条路，但它会破坏图片 dom 顺序、无法响应式重排、点击定位也容易出错。
所以实际项目里，直接上 isotope 是最快落地的方案——它专治这类动态布局，和 Bootstrap 共存毫无压力。
-
isotope的masonry模式能按真实图片高度自动堆叠，不依赖固定行高 - 初始化时传入
itemSelector和columnWidth，后者建议设为一个.grid-sizer元素，避免 JS 计算误差 - 必须等所有图片加载完再触发布局，否则高度取值不准；可用
imagesLoaded插件配合isotope - Bootstrap 5 的
container/row可以照常套在外面，但内部子项要移除col-*类，改用isotope-item
column-count + break-inside: avoid 的硬凑法
如果坚决不用 JS，只能走 CSS 多列布局。它确实能实现视觉上的“瀑布”，但本质是把容器切成几栏，内容按顺序填满，不是按块高度智能排列。
常见错误是只加 column-count: 3 就完事，结果图片被切开、文字断行错乱、响应式切换列数时布局崩塌。
- 每个图片包裹一层
<figure></figure>或<div class="item">，并加 <code>break-inside: avoid（防止跨列断裂） - 给父容器设
column-gap控制间隙，别依赖margin，否则列间距离会翻倍 - 响应式换列数时，
column-count必须用min-width媒体查询控制，不能靠 Bootstrap 的col-md-4类模拟 - Firefox 对
column-count渲染最稳；Chrome 有时会因图片异步加载导致初始错位，需手动触发column-fill: auto - 别信某些博客里“CSS 瀑布流已原生”的说法，那是把
grid的auto-flow: dense和grid-auto-rows混淆了——它们做不到真正的 Masonry 高度对齐 - 即使未来全面支持，
masonry仍不支持gap在列之间生效，还得靠padding+clip-path补救 - 目前唯一稳妥的「纯 CSS」替代方案，是服务端预计算每张图高度，生成带
data-height的 HTML，再用 JS 模拟 Masonry ——但这已经不算纯 CSS 了 - 务必引入
imagesLoaded，并在回调里调用isotope.layout()或强制触发column-count重绘 - 如果用了
loading="lazy"，得监听load事件后单独刷新对应 item，而不是整个容器重排 - 服务端渲染（SSR）场景下，要确保首屏图片有明确
width/height属性，让浏览器预留空间，减少回流
为什么不用 display: grid + grid-template-rows: masonry
这个 CSS 新特性听上去完美，但现实很骨感：grid-template-rows: masonry 目前（2024 年中）仅在 Chrome 116+ 启用，且必须开启实验性标志 chrome://flags/#enable-experimental-web-platform-features，Safari 和 Firefox 完全不支持。
也就是说，写死了这条规则，90% 用户看到的还是单列滚动。
图片加载时机不对，瀑布流就永远错位
这是上线后最常被忽略的坑：DOM 渲染完成时，图片还没加载，isotope 或 column-count 都按 0 高度计算，结果所有图挤在第一行。
不能只靠 window.onload，因为懒加载图片或 CDN 缓存策略会让加载时间飘忽不定。
