纯靠html无法实现瀑布流，必须依赖css或js；column-count需直系子元素并设break-inside: avoid；grid-template-rows: masonry仅chrome/edge 116+支持；js方案须处理图片加载时机与动态布局。
纯靠 HTML 结构本身无法实现瀑布流——它没有内置的“按最短列排列”逻辑，必须靠 CSS 或 JS 驱动布局。关键不是怎么写 <div>，而是怎么让浏览器知道“这张图该塞进哪一列”。
<h3>column-count 必须搭配直系子元素 + break-inside: avoid</h3>
<p>这是最快能跑起来的方案，但结构容错率极低。浏览器会把容器内所有直接子节点按顺序切片分栏，中间插一层 wrapper 就失效。</p>
<ul>
<li>
<code>.masonry > * 是底线选择器，不能写成 .masonry div，否则会命中卡片内部的 <span></span> 或 <button></button>
<img> 不能裸放，必须包在 <div class="item"> 里，否则 <code>break-inside: avoid 在 Safari/Firefox 中基本不生效
-webkit-column-break-inside: avoid，Firefox 建议给 .item 设 min-height: 200px 防止图片未加载时塌陷column-width: 280px 比 column-count: 3 更响应式，两者别同时设，浏览器优先按 column-width 算grid-template-rows: masonry 只在 Chrome/Edge 116+ 有效
这不是未来式，是现在就能用的原生方案，但兼容性墙很硬：Safari 和 Firefox 完全忽略该声明，回退为普通 grid（单行排列）。
- 必须配合
grid-auto-flow: dense，否则空隙不会自动填充 - 必须显式设
grid-template-columns（如repeat(auto-fill, minmax(280px, 1fr)))），否则列数不响应 - 不能依赖图片自然高度——若没设
aspect-ratio或固定height，加载后会塌陷，需 JS 补位或服务端预传宽高比 - 别在
上直接设该样式，父级有transform或filter会破坏 masonry 计算
JS 方案绕不开图片加载时机问题
用 Masonry.js 或手写算法时，img.height 读出来是 0 的情况远比想象中频繁——哪怕 DOM 已就绪，图片资源还没解码完成。
- 初始化前务必等
document.addEventListener('DOMContentLoaded', ...)，但别在这时调masonry.layout() - 必须监听每张图的
load事件，或用imagesLoaded插件聚合触发；懒加载图还要额外监听IntersectionObserver - 动态插入新项后，用
layout.appended(newItems)，别用layout.reloadItems()——后者会重排全部项，卡顿明显 - 给
<img>加width和height属性（哪怕只是占位值），或用data-aspect-ratio="4/3"配合 JS 补算真实尺寸
响应式间隙和末尾留白是隐形陷阱
看起来只是视觉问题，实则暴露底层逻辑缺陷：column-count 不管内容高度分布，只管顺序切片；grid masonry 则依赖行高预估是否准确。
-
column-gap和margin-bottom要配合用——只靠column-gap无法控制最后一行底部空白，得加.item:last-child { margin-bottom: 0 } - Grid 方案中，若卡片高度差异大（比如混有 200px 和 800px 项），
grid-auto-flow: dense可能导致顺序错乱，此时需用grid-row-end: span 2显式标注跨行 - 所有方案都怕父容器设
overflow: hidden——grid 中跨行元素、column-count 中高卡片会被截断，调试时先关掉它
真正难的不是写出第一版瀑布流，而是让它在图片异步加载、窗口缩放、动态增删、不同设备上都不崩——这些细节没被封装进一行 CSS 里，得靠你一条条补全。
