CSS Grid可实现响应式图片画廊：用repeat(auto-fill, minmax(280px, 1fr))自动适配列数，grid-gap控间距，img{width:100%;height:auto}配合aspect-ratio防变形；瀑布流需JS（如Masonry）或Chrome 116+ grid-template-rows:masonry。
用 CSS Grid 实现响应式图片画廊（非 JavaScript）
纯 CSS 就能做出对齐整齐、自动换行、适配不同屏宽的图片画廊，grid 比 float 或 inline-block 更可控，也比 flex 更适合二维布局。关键不是“堆满”，而是让每张图在各自格子里自然伸缩。
常见错误是给 img 设固定宽高，导致变形；或把 grid-template-columns 写死成 repeat(3, 1fr)，结果小屏上溢出。
- 用
grid-template-columns: repeat(auto-fill, minmax(280px, 1fr))—— 最小 280px，最多占满一行，浏览器自动算列数 -
grid-gap替代margin控制间距，避免外边距合并问题 -
img设width: 100%; height: auto;，再包一层aspect-ratio: 4/3（或用object-fit: cover配合固定容器高） - 如果要支持旧浏览器（如 IE），
grid不可用，得切回display: flex; flex-wrap: wrap+min-width控制子项
瀑布流必须用 JavaScript？不一定，但 CSS column-count 有硬伤
CSS 的 column-count 确实能模拟瀑布流效果，但它按内容高度切列，不是按图片切——一张高图会被断开，出现“撕裂”。所以它只适合文字流，不适合图片画廊。
真瀑布流（每列独立、图片不切割、底部对齐）目前仍需 JS，但不用重写整个布局引擎。主流方案是 Masonry（原生 Web API 尚未普及）或轻量替代 css-masonry（Chrome 116+ 支持，但 Safari / Firefox 无）。
立即学习“前端免费学习笔记（深入）”；
- 若只支持现代 Chrome，可试
display: grid; grid-template-rows: masonry;，但必须配合grid-auto-flow: dense和显式行高控制 - 更稳妥：用
vanilla-masonry库，监听图片加载完成后再布局，避免高度塌陷 - 别在
DOMContentLoaded就初始化 —— 图片还没加载，高度为 0，瀑布流会全挤在第一列
loading="lazy" 和 srcset 对瀑布流的影响很实际
懒加载和响应式图片本身是好功能，但在瀑布流里容易引发重排。典型现象：图片加载后突然撑开高度，下面所有列往下跳，用户体验割裂。
这不是 bug，是预期行为。解决思路不是关掉懒加载，而是预留占位空间。
- 给
img容器设最小高度（如min-height: 200px），或用aspect-ratio配合height: 0+padding-bottom占位 -
srcset要配sizes，比如sizes="(max-width: 768px) 100vw, 50vw"，否则浏览器可能选错尺寸，导致放大模糊 - 瀑布流 JS 库通常提供
reloadItems()方法，可在img的load事件里调用，但频繁触发性能差；建议节流或等全部加载完再统一刷新
移动端触摸操作：缩放、滑动、点击预览怎么不打架
图片画廊在手机上常同时需要：双指缩放、左右滑动切换、单击放大预览。三者手势冲突严重，touchstart/touchmove 默认行为不加干预就会互相劫持。
- 禁止默认缩放：在
<meta name="viewport">中去掉user-scalable=yes，或设maximum-scale=1 - 滑动切换优先级高于缩放：监听
touchmove，根据deltaX是否大于deltaY * 1.5判断是否为横向滑动，是则preventDefault()，阻止缩放手势启动 - 预览弹层用
position: fixed+transform: scale()，别用zoom（已废弃且不兼容） - 注意 iOS Safari 的
overflow: scroll在fixed元素里可能失效，需加-webkit-overflow-scrolling: touch
真实项目里最常被忽略的是图片加载时机与瀑布流重排的协同——不是代码写不对，而是没想清楚“谁该等谁”。尤其服务端渲染（SSR）场景下，JS 初始化早于图片解码，空布局几乎不可避免。
