图片多的网站，真正卡住的从来不是「好不好看」，而是两个很具体的问题：一屏里能同时摆下多少张，以及用户想看清其中一张的时候该怎么办。
这两件事的技术路线完全不搭界。前者是布局问题，靠 CSS 的网格、多列或者裁剪来解决；后者是交互问题，要么点开弹一个灯箱，要么悬停就地放大。选错了方向，后面基本得推倒重来——比如你用瀑布流排了两百张缩略图，却发现没预留放大预览的位置，那不是加个插件能补上的事。
本文这 14 款讲的是陈列：一次把多张图摆在眼前，让人自己挑着看。轮播与切换效果那一篇讲的是另一件事——一次只给一张，按顺序往下换，两者的适用场景几乎不重叠。
下面按四组来看：布局本身怎么排、点开怎么看大图、不点开怎么看清、以及图片特别多时怎么办。文章最后有一节讲图片站上线前必须处理的性能与可访问性问题，做作品集和电商图库的建议看完。
第一组 · 布局本身：不用 JS 算位置（01 - 04）
这一组的共同点是排版全靠 CSS 完成，浏览器自己算位置，没有 JavaScript 参与。好处不只是代码少：JS 布局方案必须等图片加载完拿到尺寸才能排，中间那段时间页面是乱的；CSS 方案没有这个空档。
01. 瀑布流，一个 CSS 属性就够了
纯 CSS column-count 零 JS 带调试开关
仅用 CSS 的 column-count 属性实现的瀑布流，不需要任何 JavaScript 布局计算。图片按列自动填充，高低错落，响应式适配各种屏幕，还内置了一个序号显示开关方便调试。
这一款的价值需要放在当下的浏览器现状里才看得清楚。大家想要的「原生 CSS 瀑布流」是 Grid 的 masonry 能力，可截至目前它仍未普及——按 caniuse 的统计，CSS Grid Lanes（masonry / 瀑布流布局）的全球支持率只有 10.55%，目前只有 Safari 26.4 及以上默认开启，Chrome、Edge、Firefox 都还藏在实验开关后面。也就是说今天要做瀑布流，column-count 仍然是唯一能直接上生产的纯 CSS 方案。
它的代价作者自己就写明了：内容是按列排列而不是逐行排列的。意思是第 1、2、3 张会竖着落在第一列，而不是横着排成第一行。纯图片墙无所谓，但如果你的图带序号、带日期、或者有阅读顺序（比如按时间倒序的作品集），视觉顺序会和实际顺序对不上。有阅读顺序要求就别用它，老老实实用 Grid 逐行排。
02. 蜂巢六边形图片墙
纯 CSS Grid + clip-path corner-shape 六边形
用 CSS Grid 加 clip-path（以及较新的 corner-shape）把图片裁成六边形，拼成蜂巢状排列。作者给的适用场景很具体：节日与活动专题图集、展示合作伙伴 Logo 或团队成员的创意品牌墙、电商的生活方式类配图。
六边形排布最实际的好处是省空间——同样的面积，蜂巢比矩形网格能多塞下内容，而且相邻单元互相咬合，视觉上是连成一片的整体而不是散落的方块。用来做团队头像墙尤其合适，人多也不会显得杂乱。
两个限制要提前知道：
六边形裁切会切掉图片的四个角，人像必须居中构图，否则脑袋边缘会被削掉，用之前得批量检查素材。
corner-shape这个属性还很新，Safari 上拿不到它带来的额外圆润处理。
关于第二点，按 caniuse 的数据，它的全球支持率为 68.05%，Chrome 与 Edge 从 139 起支持，而 Firefox 和 Safari 目前都不支持。好在核心的 clip-path 兼容性没问题，Safari 用户看到的是没有额外圆润处理的六边形，属于可接受的降级。
03. 不规则多边形拼接相册
纯 CSS 不规则边框 悬停缩放 响应式
仅用 CSS 实现的响应式图片画廊，图片被裁成不规则的多边形拼接在一起，配悬停缩放与过渡动画。定位是作品集展示与相册浏览。
它和上一款是同一类思路的两个方向：蜂巢追求的是秩序感和重复的韵律，不规则拼接追求的是打破秩序。做设计工作室或艺术类作品集时，后者更能传达「我们不走寻常路」这个信号；但同样的处理放到卖货的电商图库上就会显得刻意。
它的短板是可复用性差：不规则形状意味着每一格的裁切路径都是手写的，图片数量一变，整套坐标就得重调。适合图片数量固定的展示区（比如首页的一块视觉区），不适合会不断增删的动态相册。做动态列表还是回第 01 款那种规则布局。
04. Grid 网格：悬停一张，其他自动让位
纯 CSS CSS Grid 悬停伸缩 支持点击
基于 CSS Grid 的响应式图片网格，悬停或点击时目标图片平滑扩展，其余图片被挤压收缩，全程有过渡动画。适用于作品集、相册和产品陈列。
这种「挤压—扩张」的模式解决的是一个很实在的矛盾：用户既想看清一张，又不想失去对全局的感知。弹窗放大会遮住其他内容，跳转详情页会打断浏览，而就地扩张两者都不牺牲——放大的那张够大，旁边的还在视野里。
它有两个容易忽略的问题。一是触屏上没有悬停，所以移动端必须靠点击触发，作者支持了点击是对的，但你要自己确认交互提示够不够明显——手机用户不会知道这张图能点。二是布局变化会引起周围内容位移，如果画廊下面紧接着放了按钮，用户可能在扩张的瞬间点错。给画廊区块留够下边距能规避大半。
第二组 · 点开看大图：灯箱（05 - 07）
05. 原生 JS 灯箱，不依赖任何库
JavaScript + CSS 零依赖 键盘方向键 HTML 说明文字
纯 JavaScript 写的灯箱：点击缩略图后全屏弹出，带左右切换箭头、关闭按钮和自定义图片说明，支持键盘方向键。不引入 jQuery，不加载几百 KB 的第三方库，几十行代码搞定。
本文最该被收藏的就是这一款。灯箱是图片站的刚需，而市面上流行的灯箱插件普遍带着历史包袱——为了兼容老浏览器、为了支持视频和 iframe、为了各种配置项，体积一路膨胀。绝大多数网站要的其实只有「点开、看大、左右翻、关掉」这四件事，几十行代码完全够。
它还有一个不起眼但很实用的能力：说明文字支持 HTML，可以在图片下方加链接、加标签。电商的产品图想在灯箱里直接挂「加入购物车」，摄影作品想标注拍摄参数并链到详情，用纯文本灯箱是做不到的。
要自己补的是无障碍部分：灯箱打开后应该把键盘焦点锁在弹层内（否则 Tab 键会跑到背后的页面上去），关闭时再还给触发它的那张缩略图。这属于自定义弹层的通用课题，轻量灯箱一般不会替你处理，做正式项目时记得加上。
06. View Transition API 驱动的响应式灯箱
CSS + JS View Transition API 响应式 沉浸式预览
同样是灯箱，但过渡交给浏览器原生的 View Transition API。点击缩略图时，图片是「长大」成大图的，而不是缩略图淡出、大图淡入——中间那段形变由浏览器接管，帧率和顺滑度都不是 JS 逐帧计算能比的。
这个 API 现在已经可以放心用了。按 caniuse 的数据，View Transitions 的全球支持率为 90.2%：Chrome 与 Edge 从 111 起支持，Safari 从 18.0 起支持，Firefox 从 144 起支持（143 版本已实现但默认关闭）。更重要的是它的降级方式很温和——不支持的浏览器只是没有那段动画，点击、放大、关闭全都照常工作，不会白屏也不会报错。这种「加分项而非依赖项」的特性，是它比 JS 动画方案更适合生产环境的原因。
缺点是它只负责过渡，不负责功能。左右翻页、键盘操作、说明文字这些第 05 款自带的东西，这一款需要你自己确认有没有。两款其实可以合起来用：用第 05 款的结构，把它的显示/隐藏包进 document.startViewTransition()，就同时拿到了完整功能和原生过渡。
07. 超椭圆放射布局，点击时图片在流动
CSS + JS View Transition 超椭圆 8 张放射排布
8 张图片装进不同尺寸的超椭圆容器，围绕中心主图放射状分布。超椭圆是介于圆形和圆角矩形之间的形状，iOS 图标用的就是它，比正圆多一点呼吸感，比圆角矩形柔和。点击任意小图时，同样用 View Transition API 做形变：被点的图平滑变形并放大到中心，原来的中心图则缩小移到它的位置上，两张图像是在交换位置而不是在闪现。悬停时还有逐渐缩小的反馈。
它和上一款用的是同一个 API，但解决的问题完全不同：第 06 款是「小图变大图」的纵深过渡，这一款是「两张图互换位置」的平面过渡。后者更适合数量固定、彼此平等的一组图，比如首页的品牌视觉区或者摄影师的精选集。
限制很明确：放射构图是为固定张数设计的，8 张是它的舒适区。图片一多，外圈会越排越挤，中心的视觉焦点也就散了。这一款是「首页视觉区」的用法，不是「相册」的用法——真要陈列几十上百张，回第一组。
第三组 · 不点开也能看清（08 - 11）
这一组的思路是取消「点击」这一步。用户的鼠标经过哪里，哪里就变清楚、变大、被突出——省下了一次点击和一次关闭，代价是触屏上要另想办法。
08. 悬停即展开，还带切角处理
纯 CSS CSS Grid corner-shape: notch 4 张
4 张图默认均匀排列，悬停某张时它立即展开占据更大空间，其他图自动收缩让位。用 CSS Grid 加 corner-shape: notch 的切角技术实现，图片边缘做了斜切处理，避开了纯矩形拼接的呆板。作者建议的场景里专门点了房产图片浏览和产品多角度展示。
它和第 04 款是同一种交互的两种实现，差别在图片数量和视觉处理上。第 04 款是可以扩展的网格，适合几十张；这一款固定 4 张、每张都占很大面积，更像是首页的一个「四选一」展示位——房产站的四种户型、产品的四个角度，正好各占一格。
要注意的还是 corner-shape 的兼容性问题：Firefox 和 Safari 目前都不支持这个属性，那里看到的会是没有切角的普通矩形。好在展开收缩这个核心交互是 Grid 做的，不受影响——切角丢失只是少了点设计味道，功能完整。但如果切角正是你选它的原因，那就得掂量一下了。
09. 用遮罩做出景深，照片像嵌在相框里
纯 CSS CSS Mask 景深效果 12 张网格
用 CSS Mask 遮罩做出「照片叠加相框」的层次：中心区域清晰锐利，向四周自然过渡到模糊，营造景深和立体感。12 张照片网格排列，悬停时缓慢拉近。
模糊边缘解决的是图片墙最常见的一个观感问题——生硬。一堆矩形照片紧挨着排开，边界互相打架，整体显得拥挤。让边缘化开之后，每张图之间有了空气感，视线也更容易在单张上停留。摄影作品集和旅行博客用这一招提升最明显。
限制在于它会吃掉图片边缘的信息。构图饱满、四角有内容的照片，边缘一模糊就等于被裁了；反过来说，中心构图的人像和特写最适合它。选它之前先拿最重要的那几张试一遍，别等全站铺开了才发现关键信息糊在了边上。
10. 一个会跟着鼠标跑的边框
纯 CSS 悬停高亮 边框跟随 轻量
鼠标在图库里游走时，一个边框跟着移动，并把鼠标下方那张图突出出来。纯 CSS 实现，除了图库也能用在卡片列表上。
这一款的克制是优点。本文其他效果都在改变布局——放大、挤压、变形，而它只是给出一个「你正看着这张」的视觉确认，一个字节的布局都不动。在信息密集的列表里，这种不打扰的反馈往往比华丽的动效更受用，因为用户的注意力还在内容上，没被动画抢走。
它的问题也来自同一处：反馈太轻，可能被忽略。如果这个边框同时还承担「这里可以点」的暗示，那就不够——用户可能压根没意识到它是可交互的。建议配合鼠标指针样式（cursor: pointer）一起用，双重信号才稳。触屏上这个效果自然不成立，移动端需要另设一套高亮方式，或者干脆不要。
11. 九宫格收拢与散开
纯 CSS 点击触发 九宫格 零 JS
点击一个九宫格图标，多张图片以九宫格布局散开；再点收回。全程纯 CSS，没有 JavaScript。
「点击也能纯 CSS 实现」这件事本身值得单独说一句。常规做法是用隐藏的 checkbox 或 radio 配合 :checked 选择器来记住状态，不写一行 JS 就能做出开关式交互。这个技巧的适用面远不止相册——折叠面板、标签页、移动端菜单都能这么做，是很值得从这一款里学走的一招。
用之前要清楚它的定位：这是个交互彩蛋，不是相册主体。九宫格意味着九张，多了排不下；而且散开的动效看第二遍就没有惊喜了。合适的位置是个人主页的一个小模块、或者「我们的团队」那种数量固定的展示区，不适合做需要反复浏览的正式图库。另外纯 CSS 的状态没法被 JS 读取，如果你需要在展开时同时做别的事（比如加载图片），还是得写脚本。
第四组 · 图片特别多的时候（12 - 14）
12. 可拖拽的整块画布，专业作品集用的那种
GSAP Draggable + Inertia 无级缩放 Flip 布局切换
这不是一个画廊组件，而是一整套作品集官网方案。基于 GSAP 原生开发，用到了官方的 Draggable 拖拽引擎、InertiaPlugin 惯性动效、CustomEase 缓动和 Flip 布局切换插件。能力给得很满：整块画布自由拖拽浏览、多档位无级缩放、视图自适应，还能一键在「网格全景」和「单张沉浸预览」两种模式间切换，拖拽全程带物理惯性。视觉上是暗调全屏，把界面元素压到最低，另外品牌导航、工作室信息、联系方式、社交入口、作品版权标注这些官网必备模块也都集成好了。
拖拽画布这种交互，本质上是把浏览的主动权彻底交给用户。网格和瀑布流仍然是你替他决定顺序，而在一块可以任意拖动缩放的画布上，他自己决定从哪儿看起、看多细。摄影师和艺术家的作品集特别吃这一套——它的手感更接近专业设计工具，而不是网页。
三条代价要认：
插件授权：它依赖 GSAP 的多个插件，其中 InertiaPlugin 属于会员插件，商用前必须先确认授权。
SEO 收录：搜索引擎理解不了「拖到左上角能看到什么」，作品集本身的收录会打折，务必同时保留一套常规列表页给爬虫。
移动端手势：拖拽和缩放很容易和页面本身的滚动、双指缩放打架，上线前必须拿真机逐一试过。
13. 多列反向滚动的立体图片墙
纯 CSS 3D Transform 自动循环 倾斜透视
多列图片按不同方向（向上、向下）交错平滑循环滚动，配上倾斜视角和边缘暗角，空间纵深感很强。基于 CSS 3D Transform 与 @keyframes 实现。适合品牌官网的首屏背景、创意作品集、媒体墙展示。
它的正确用法是背景而不是内容。自动滚动的图墙没法让人看清任何一张——图一直在动，想细看只能干等它转回来。所以它的职责是「让首屏有活气、暗示这里有大量作品」，具体内容应该由下面的常规画廊承接。把它当正经相册用，是最容易犯的错。
性能上要留意：多列同时做 3D 变换是持续动画，不像滚动触发的效果那样只在特定时刻跑。图片务必先压缩、控制单列数量，并且给 prefers-reduced-motion 留一个静止版本——持续运动的大面积画面对前庭敏感的用户是实打实的困扰，不只是「体验问题」。
14. 48 张图排成螺旋，滚动穿行其中
纯 CSS 48 张卡片 滚动驱动 参数化
48 张卡片分成两条螺旋股，像双链一样绕着中轴向远处延伸；页面一滚，整条螺旋朝你推进，正对镜头的那张自动放大变清晰，两侧的半透明后退。滚动停下画面也停住，进度完全跟手。全程零 JavaScript，由 CSS 三维变换和滚动驱动动画完成。
它最值得学的地方在实现方式：每张卡片的位置是算出来的，不是写死的。样式表顶部先定义螺旋半径、卡片角度间隔和纵向间距，再由这几个值推导出每圈放几张、一圈前进多少。每张卡片只需要知道自己的序号，角度和深度都能算出来——所以 48 张共用同一套规则，增删卡片不用改任何坐标。这种参数化写法是它和那些「手写每一张位置」的 3D 效果之间的本质差别，也决定了它能不能长期维护。
要认的限制是滚动驱动动画的兼容性。按 caniuse 的数据，animation-timeline 属性的全球支持率为 85.43%，Chrome 与 Edge 从 115 起支持，Safari 自 26.0 起、Firefox 自 157 起支持。意味着相当一部分 Safari 和 Firefox 用户在近期才会拿到这个能力，之前的版本上螺旋不会随滚动前进。做正式项目建议先检测支持情况，不支持时退回一个静态网格，别让那部分用户对着一堆重叠的卡片。
图片站上线前，这几件事比效果本身重要
画廊选得再好，图片处理不当照样是灾难。下面几条都取自规范与官方文档，是图片密集页面绕不开的。
一、每个 <img> 都要写 width 和 height，哪怕你用 CSS 控制了尺寸。MDN 的说明是：写上宽高之后，浏览器能在图片加载之前算出宽高比，用它预留出显示所需的空间，从而减少甚至避免图片下载并绘制时发生的布局位移。图片墙是布局位移的重灾区——几十张图陆续加载完，页面能跳好几轮，用户刚要点的东西就跑了。
二、懒加载要用，但别给首屏的图用。loading="lazy" 会把加载推迟到图片接近视口时。MDN 特别提醒：视口内的懒加载图片在 load 事件触发时可能还没显示出来，因为该事件只以立即加载的图片为准；而且不与可见区域相交的图片永远不会被加载——未加载的图片宽高都是 0，这会造成用户正在阅读时视口内容突然重排，体验更糟。结论很清楚：首屏可见的那几张用默认的 eager，往下滚才出现的才加 lazy。MDN 同时强调，宽高属性对懒加载的图片尤其重要。
三、装饰性的图要写空 alt，不是不写 alt。按 MDN 的说明，把 alt 设成空字符串（alt=""）表示这张图不是内容的关键部分（属于装饰或跟踪像素），非视觉浏览器可以略过它；而且 alt 为空时，图片加载失败也不会显示破图图标。纯装饰的背景图墙就该这么写。反过来，作品集和产品图属于内容，必须写有信息量的 alt——那既是可访问性，也是图片搜索的抓手。
四、缩略图不要用大图缩着显示。这是图片墙上最贵的错误：一屏 30 张缩略图，每张实际却是 2MB 的原图，浏览器要下载 60MB 才能画完这一屏。缩略图应该单独生成小尺寸文件，点开灯箱时再加载大图。这一条没有任何效果代码能替你完成，但它对加载速度的影响比本文所有优化加起来都大。
最后：按你的图片数量对号入座
几十张到几百张的正式相册，先定第一组的布局，再配第 05 款的灯箱。这是最稳的组合：CSS 排版不会有加载空档，零依赖灯箱不会拖慢首屏。要瀑布流就用第 01 款——原生 Grid masonry 还得等，column-count 是今天唯一能上生产的纯 CSS 方案。
数量固定在十张以内的首页视觉区，第三组和第 07 款更合适。第 08 款做「四选一」、第 07 款做八张放射、第 11 款做九宫格，都是为固定张数设计的，不用为扩展性付代价。
做摄影或艺术类作品集，直接看第 12 款，但要接受它的三条代价。拖拽画布的浏览手感是本文最好的，GSAP 插件授权、SEO 收录和移动端手势冲突这三件事必须提前处理好。第 13、14 款是氛围件不是相册，用在首屏背景上，别指望用户在里面看清任何一张。
本文的 14 款都在童哲网前端特效板块。相关的几篇：轮播与切换效果（一次给一张的那一类）、卡片与布局效果（Bento Grid 与 GSAP Flip，和第一组是同一类排版思路）、Three.js 与 WebGL 网页 3D 特效（第 12 到 14 款想要更重的版本时看这篇）、网页标题与文字特效（图墙配标题时用）。
