搞笑写实图片站全链路：存储分发、懒加载与成本优化

做图片站这件事，我前后折腾过三个版本，从最早一台小机器上跑静态目录，到后来上对象存储加CDN，再到把图片处理链路整个搬到云端做实时裁切，中间踩的坑基本覆盖了一个中小型图片站能遇到的所有问题。搞笑写实图片站这个方向尤其典型——它看起来只是"把图堆上去"，实际上牵扯到图片采集与去重、存储格式选型、前端瀑布流渲染、弱网加载策略、内容分类与合规审核、带宽成本控制这一整条链路。我见过太多人一开始兴致勃勃搭了个页面，图放了两千张就卡得打不开，或者流量稍微起来一点，账单直接翻十倍。这篇文章就把这条链路上的关键决策点、参数取值、以及那些文档里不会写的经验，一次讲透。不管你是刚想动手做个自己的图片合集站，还是已经有一个跑着但体验不太行、想优化一下，下面这些内容应该都能直接用上。

1. 先想清楚：搞笑写实图片站到底在做什么

1.1 从标题里拆出来的三层真实需求

"搞笑"和"写实"这两个词放在一起，其实已经把内容风格框死了：不是表情包那种二次元或夸张变形的东西，而是真实场景里发生的、有反差感的画面——比如构图正经但内容荒诞的街拍、一本正经的说明书配图、生活中的意外巧合。这类图片的特点是单张信息密度高、依赖上下文理解、观众看一眼就能笑，但同时对图片清晰度有要求，糊成一团就失去笑点了。这就决定了你在压缩参数上不能像表情包站那样把质量压到 50，得留够细节。

用户来这类站点，行为路径非常集中：进来 → 快速下滑翻图 → 遇到好笑的点开看大图 → 分享出去。整个过程平均停留时间也就一两分钟，翻图速度极快。这意味着首屏之后的加载体验比首屏本身更重要，因为你永远不知道用户会在第几张图停下来，任何一张图转圈超过一秒，他就滑走了。

而站长的需求又是另一套：图要能持续更新、要能分类、要能被人搜到（不然没人来）、服务器不能因为几张图被转发出去就崩。这三层需求——内容风格、用户行为、站长运维——叠在一起，才是这个项目真正的全貌。很多人只盯着第一层，做完发现没人来；或者只盯着第三层，做完发现没人愿意看。

我的判断是：这类站点的核心竞争力不在技术，技术只是保证"不拖后腿"。真正决定成败的是图片筛选的品味和更新频率，但技术一旦拖后腿，品味再好也白搭。所以下面的内容会重点讲那些"不做就会死"的技术环节。

1.2 为什么我不建议一上来就写代码

我第一版就是直接开写，两天撸出一个能传图能展示的页面，然后兴致勃勃传了三百张图。结果第一个问题立刻出现：同一张图被不同来源重复传了七八次，页面上全是重复内容，自己看着都烦。第二个问题：手机打开，前三张图加载完，往下滑全是白块，得等五六秒才出来。第三个问题：有个帖子被转到某个群里，一晚上来了两万多访问，图片全挂，因为源站带宽被打满了。

这三个问题分别对应去重、懒加载、分发，每一个都不是写业务代码能解决的。所以正确的顺序应该是：先把图片从"进站"到"出站"的完整链路画出来，确定每个环节用什么方案，再动手。链路大概是这样：

采集/上传 → 格式与尺寸标准化 → 生成指纹去重 → 入库并打标签 → 生成多尺寸衍生图 → 分发到边缘 → 前端按需加载 → 统计与回收

这条链路上任何一个环节偷懒，后面都要花三倍时间补。我见过有人为了省事，上传时不做尺寸限制，结果站里混进了几张 8000 像素宽的原图，前端一渲染直接卡死浏览器；也见过不做指纹去重的，数据库里同图存了十几份，白白多付存储费。所以第一章先把思路理顺，比急着敲键盘划算得多。

提示：如果你只是想做一个几十张图的小合集给自己看，下面很多内容属于过度设计，直接用静态页面加手动压缩就够了。但只要你有"持续更新"和"被别人访问"这两个诉求，就该按完整链路来规划。

2. 技术选型：图片站的骨架怎么搭

2.1 存储与分发：对象存储配CDN这笔账怎么算

图片站最忌讳把图片和应用服务器放在一起。原因很直白：应用服务器通常是按 CPU 和内存计费的，带宽往往是共享的、有限的，一旦图片流量上来，要么应用被拖慢，要么直接触发带宽上限。而图片这个东西天生适合"一次写入、无数次读取"，正是对象存储加 CDN 的标准场景。

我目前的组合是：对象存储放原图和衍生图，CDN 做边缘缓存，源站只处理元数据和页面渲染。选型上有几个具体考量点，值得展开说。

第一是存储的访问方式。有些对象存储默认走内网免流量费，公网访问才计费，如果你的应用和存储在同一区域，元数据读写走内网，能省下一大笔。这个细节在选型时一定要看清楚计费说明，我吃过亏——早期把应用和存储放在不同区域，结果每天有几块钱的跨区流量费，看着不多，一年下来也是一笔钱。

第二是CDN 的缓存命中率。图片站的访问有明显的长尾特征：新图刚发出来访问集中，老图偶尔被搜到。如果缓存策略设得太短，老图频繁回源，CDN 等于白买。我的做法是给图片 URL 加上内容哈希（比如文件名带一段指纹），然后设置近乎永久的缓存：

location ~* \.(jpg|jpeg|png|webp|avif)$ { expires 365d; add_header Cache-Control "public, max-age=31536000, immutable"; }

immutable这个指令很关键，它告诉浏览器"这个 URL 的内容永远不会变，别来问我有没有更新"。因为文件名带哈希，内容一变文件名就变，所以这个假设是成立的。实测下来，命中率能从 80% 出头提到 96% 以上。

第三是回源保护。CDN 回源带宽通常比边缘带宽贵，如果哪天缓存被刷了或者有人恶意构造不存在的 URL，回源请求会暴涨。我在源站侧加了一个简单的限流，同时对 404 的 URL 也做了短时间缓存，避免同一批不存在的路径反复穿透。

至于带宽成本，我拿一个真实量级算给你看。假设站点日均 10 万 PV，列表页每页加载 20 张缩略图，每张按 30KB 算（后面会讲这个参数怎么来的），那一天的下行流量是：

10 万 × 20 × 30KB ≈ 60GB/天

外加详情页，假设 10% 的 PV 会点进详情页看大图，每张 300KB：

1 万 × 300KB ≈ 3GB/天

合起来约 63GB/天，一个月接近 1.9TB。按常见 CDN 阶梯价每 GB 两毛左右估算，月成本大概三百多块。这个数字说明一个很重要的结论：图片站的成本大头在流量，不在存储。10 万张图按每张 300KB 算才 30GB 存储，一个月几块钱，但流量费是它的十几倍。所以所有优化精力都应该优先投向"把每张图的体积压下来"，而不是抠存储。

2.2 图片处理链路：格式、尺寸与压缩参数怎么定

这块是省钱的核心，也是最容易做错的地方。先把结论摆出来：原图只存一份，其余全部实时或准实时生成衍生图，格式优先 WebP，AVIF 做渐进增强，JPEG 兜底。

为什么不存多套尺寸？因为尺寸需求是变化的。今天列表页缩略图 400 宽，明天改版可能变 360 宽，如果预先生成好，改一次版就要重跑全站图片，几万张图跑一遍既慢又费钱。用对象存储自带的图片处理能力，在 URL 上拼参数实时输出，改参数只是改个字符串的事：

https://img.example.com/photo/2024/a1b2c3d4.jpg?x-oss-process=image/resize,w_400/format,webp/quality,q_78

这个 URL 的每一段都有讲究。resize,w_400是等比缩放到宽 400，高度自适应，比固定宽高好，因为写实类图片长宽比差异极大，强制裁切会把笑点裁没。format,webp输出 WebP，兼容性现在基本没问题。quality,q_78是我反复试出来的平衡点。

质量参数到底取多少，这个不能拍脑袋。我做过一轮对比，拿二十张典型图片，分别用 q=60、70、78、85、92 压成 WebP，然后让几个朋友盲看能不能分辨。结论是：q=75 到 80 之间基本看不出差别，q=60 开始文字类的细节会糊，q=85 以上体积涨得飞快但肉眼收益极小。所以列表页缩略图用 q=72 就够，详情页大图用 q=80，原图备份保持原样不压。

尺寸上我目前设了三档：

• 缩略图：宽 400，用于列表瀑布流
• 中等图：宽 900，用于点击后的快速预览
• 大图：宽 1600，用于详情页
• 超过 2400 像素的原图，上传时统一缩到 2400，再大的分辨率对这种观看场景没有意义

第三档和第二档的差价很明显。同一张图，宽 1600 的 WebP 大约 180KB，宽 2400 的可能到 400KB。而用户实际屏幕宽度也就 400 到 800 个 CSS 像素，视网膜屏撑死两倍，1600 完全够。

这里有个坑要提醒：不要用 GIF 存"写实搞笑图"。GIF 只有 256 色，写实照片放进去会有明显的色带和噪点，而且体积巨大。动图需求如果确实有，用短视频格式更合适。另外，PNG 只留给需要透明背景的素材，普通照片一律走有损。

2.3 数据库与检索：分类、标签与相似图去重

图片站的数据库设计，最容易犯的错是把标签直接塞进一个字段用逗号拼接。一开始觉得省事，等到要做"按标签筛选"或者"统计某标签下有多少图"的时候，就会发现只能全表扫，几万条数据还撑得住，几十万条就明显慢了。

我的做法是三张表：图片主表、标签表、关联表。主表存 id、存储路径、宽高、体积、格式、指纹、状态、创建时间；标签表存标签名和 slug；关联表就是图片 id 和标签 id 的对应关系。这样查某个标签下的图，一次 join 就出来了，加索引后响应很快。如果数据量再大一些，或者需要模糊搜索标题和描述，可以再上一个全文检索，但我的经验是在十万级数据量下，做好索引的普通数据库完全够用，没必要为了搜索单独维护一套检索服务，运维成本不划算。

真正值得单独说的是相似图去重。这个问题在靠采集攒图的场景下极其严重，我第一版三百张图里就有二十多组重复。后来接入感知哈希（pHash）才算解决。原理不复杂：把图片缩到 32×32 灰度，做离散余弦变换，取低频部分的系数，和均值比较生成一个 64 位的指纹串。两张图的指纹做异或后数 1 的个数，就是汉明距离。距离越小越像。

阈值怎么定？我实测下来，汉明距离 ≤ 8 基本可以判定为同一张图的不同版本（包括略微裁剪、加水印、重新压缩的），9 到 12 之间需要人工看一眼，大于 12 就是不同的图。注意这个阈值只适用于 pHash，换成均值哈希或者差值哈希，数字会不一样，别混用。另外，图片被水平翻转后 pHash 会失效，如果你要防"镜像搬运"，得额外算一次翻转后的指纹一起比对。

-- 主表关键字段示意 CREATE TABLE images ( id BIGINT PRIMARY KEY AUTO_INCREMENT, storage_key VARCHAR(255) NOT NULL, width INT NOT NULL, height INT NOT NULL, bytes INT NOT NULL, format VARCHAR(10) NOT NULL, phash CHAR(16) NOT NULL, status TINYINT NOT NULL DEFAULT 1, created_at DATETIME NOT NULL, INDEX idx_phash (phash), INDEX idx_created (created_at) );

入库流程上，我会在上传阶段就同步算完指纹，先去库里查有没有距离很近的，有就直接拦掉并提示"疑似重复"，避免脏数据进主表。这一步放在上传时做，比事后写脚本清理省事得多。

3. 前端体验：让"翻图"这件事变得顺滑

3.1 瀑布流布局的实现与三个坑

搞笑写实图的长宽比五花八门，用固定网格会留大片空白，所以基本都会选瀑布流。实现方式主要有三种，我把它们的特点摊开讲。

第一种是纯 CSS 的多列布局（column-count）。写起来最省事，几行代码就出效果。但它有个致命问题：阅读顺序是竖向优先的，也就是内容会先填满第一列再填第二列。对于按时间倒序排列的图片流来说，用户看到的顺序是乱的，第一列全是最新的，第二列是稍旧的，体验很怪。另外列数变化时元素会跳，不适合响应式。

第二种是 JS 计算分列，维护一个列高度数组，每次把新元素塞进当前最矮的列。效果最接近直觉中的瀑布流，顺序也基本正确。缺点是布局依赖 JS，首屏如果等 JS 算完再渲染，会有明显的闪烁，而且窗口尺寸变化要重排，重排时图片位置跳动很难看。

第三种是 CSS Grid 配合aspect-ratio做占位。给每个图片容器提前算好宽高比，用grid-auto-rows和一个精细的行高来模拟。其实最后我选的是第二种和占位方案的混合：服务端渲染时把每张图的宽高写进aspect-ratio，容器先撑出正确的高度，JS 只负责把容器分配到各列里，这样首屏高度不会跳。

.card { width: 100%; aspect-ratio: var(--w) / var(--h); background: #f2f2f2; border-radius: 6px; overflow: hidden; } .card img { width: 100%; height: 100%; object-fit: cover; display: block; }

aspect-ratio用 CSS 变量从行内样式传，这个方案最大的好处是彻底消灭了布局偏移。做过之后你会发现，CLS 这个指标在图片站上几乎是致命的，因为用户滑得快，图一加载就往下顶，很容易点错。我优化前后对比过，加占位之后跳出率明显下降。

坑还有一个：列数不要做太多。桌面端我最多给 4 列，再宽就 5 列。有人喜欢 6 列 8 列铺满，但缩略图小到 200 像素宽的时候，写实照片里的梗根本看不清，等于白放。

3.2 首屏加载与懒加载的具体参数

图片站的首屏，我的目标是"一屏半"。也就是视口内加上往下半屏的内容，总共大约 8 到 12 张图，必须在 1.5 秒内出完。剩下的全部交给懒加载。

具体做法：服务端渲染时，前 6 张图的img标签带loading="eager"，并加上fetchpriority="high"，其余全部loading="lazy"。不过原生懒加载的触发时机由浏览器决定，各家的预加载距离不一样，为了控制得更精确，我额外用IntersectionObserver做了一层：

const io = new IntersectionObserver((entries) => { entries.forEach(entry => { if (!entry.isIntersecting) return; const img = entry.target; img.src = img.dataset.src; img.removeAttribute('data-src'); io.unobserve(img); }); }, { rootMargin: '300px 0px', threshold: 0.01 });

rootMargin设成 300px 意味着图片还有 300 像素进入视口时就开始加载，翻页过程中基本感觉不到等待。这个值不能太大，否则等于全量加载，白做懒加载；也不能太小，太小了用户滑到了才开始下，必然白屏。300 到 500 之间是比较舒服的区间，移动端网络慢的可以调到 500。

还有一个细节：不要一次把几十张图的 DOM 全渲染出来。图片流做到后面，一页可能几百上千张图，全渲染会吃满内存，滚动也卡。我的做法是分批渲染，初始 20 张，滚动到底部再追加 20 张，配合content-visibility: auto让屏幕外的容器跳过渲染：

.card { content-visibility: auto; contain-intrinsic-size: 320px 240px; }

contain-intrinsic-size是给浏览器一个预估尺寸，否则滚动条长度会跳来跳去。这两个属性组合起来，实测在一千张图的页面上滚动依然流畅。

3.3 移动端适配与弱网降级策略

移动端在这个项目里的重要性不亚于桌面，甚至更高——这类图片被分享到聊天工具里，绝大部分点击都发生在手机上。移动端有两个特殊问题。

第一是竖图占满屏。写实搞笑图里竖构图的不少，缩略图如果按宽度铺满，高度会很高，一屏只能看到一张多，翻图效率低。我的处理是限制卡片最大高度，超出的部分用object-fit: cover裁掉中间一段。裁的时候要注意，不要把主体裁没，所以我在入库时人工标一下"主体偏上/居中/偏下"，渲染时用object-position动态调整。这个标记成本很低，但观感差别很大。

第二是弱网下的体验。地铁、电梯这种场景很常见，网络一差，图片全变灰块。我做了一套降级：用navigator.connection.effectiveType判断网络类型，如果是slow-2g或2g，直接把请求尺寸从 400 降到 240，质量从 72 降到 60，并关掉预加载。同时给每个图片容器一个占位背景，加载失败时显示一个"点击重试"的按钮，而不是留白。

const conn = navigator.connection; const slow = conn && /^(slow-)?2g$/.test(conn.effectiveType); const w = slow ? 240 : 400; const q = slow ? 60 : 72;

这套判断不是万能的，navigator.connection在某些浏览器上拿不到真实值，所以还得配合onerror兜底。但只要有七八成生效，体验提升就很明显。

另外提醒一句：移动端不要用100vh做满屏容器。地址栏收起展开会让100vh变化，导致页面跳动。用100dvh或者干脆不用满屏高度。

4. 内容运营：写实搞笑图的生命周期管理

4.1 分类体系怎么设计才不越做越乱

分类这件事，我吃过最大的亏是"边加边想"。一开始只有"搞笑"一个分类，后来图多了，加了"职场""校园""动物"，再后来发现有些图跨好几个分类，又开始加"综合"。半年下来分类树歪歪扭扭，同一张图挂三四个分类，用户点进去看到重复内容，体验很差。

后来我重构了一次，原则是：分类按"场景"分，标签按"梗"打，两者分开。分类是固定的、数量有限的、互斥的，一张图只属于一个主分类；标签是开放的、可以叠加的、用来描述具体内容的。比如一张图，分类可能是"日常生活"，标签可以是"装修翻车""说明书""尺寸误会"。

分类控制在 8 到 12 个，太多了用户不会看。我目前的划分大概是：日常场景、工作办公、交通出行、餐饮食物、宠物动物、文字标识、产品说明、建筑空间、运动健身、其他杂项。这个划分覆盖了大部分内容，也不至于让人选择困难。

标签就不设上限了，但要做合并。同一类意思的标签只留一个，比如"打工人"和"社畜"和"上班族"，统一成一个，其余做同义词映射。否则标签越滚越多，最后每个标签下面只有一两张图，等于没有。

还有一点很实用：给每张图写一句真实描述。别小看这句话，它既是搜索的入口，也是分享时的文案。我试过纯靠标签，用户搜"公交车"能搜到，但搜"公交车上那个牌子写错了"就搜不到。加了描述之后，长尾搜索的命中率明显提升，而且描述本身也帮用户理解了笑点在哪。

4.2 结合热词做专题页的实际操作

热词这个东西，用于图片站最有效的场景不是首页，而是专题页。因为用户搜热词进来，期待的是"围绕这个词的一批内容"，而不是单张图。所以我的做法是：盯几个热词来源，发现某个词和站内已有内容能对上，就快速拼一个专题页。

具体流程：先看站内哪个标签最近访问涨了，或者哪个词在搜索日志里出现频率突然抬头；然后用关键词去已有图片的描述和标签里做匹配，捞出二三十张；再写一段两百字左右的专题导语，说清楚这个专题讲什么；最后生成一个独立 URL，加上规范的标题和描述。

这个动作的关键在于快。热词的窗口期往往就几天，等你想清楚架构、设计好页面、走完发布流程，热度已经过去了。所以我把专题页做成了配置驱动：一个 JSON 文件描述标题、导语、引用的图片 id 列表，提交后自动生成页面，十分钟就能上线。

{ "slug": "topic-2024-xx", "title": "那些把说明书用错的人", "intro": "……", "imageIds": [10231, 10455, 10872] }

要注意的是，专题页不能只是把图堆上去，否则和分类页没区别，搜索引擎也会判重。导语必须自己写，图片顺序要有节奏——开头放一张最有冲击力的，中间穿插几张需要想一下才懂的，结尾放一张余味长的。这个编排很影响停留时长。

提示：热词相关的内容一定要先确认站内是否真有对应素材。硬凑出来的专题，用户点进来发现文不对题，反而伤口碑。宁可这次不做，也别凑数。

4.3 审核与合规边界必须提前划好

图片站最怕的就是内容出问题。我的经验是：把审核做成流程里的一环，而不是事后补救。具体分三道。

第一道在上传时，做一个基础的机审，主要是识别明显不适宜的内容。这一步不用追求多高的准确率，能把最明显的挡在门外就行，剩下的交给人工。

第二道是人工过一遍。我给自己定的规矩是：任何一张图进公开列表之前，必须自己完整看过。这个成本看起来高，但一张图看两秒，一百张也就三分钟。写实类图片的风险点在于背景里的文字、标识、人物，很多问题不在画面主体上，而在角落里。所以我要求自己放大看四个角和背景。

第三道是定期回扫。有些内容当时看没问题，过一段时间可能有新的理解，所以每隔一段时间要把最近上架的内容再扫一遍，发现问题及时下线。下线不是删库，是把状态字段改成不可见，保留记录便于追溯。

另外，描述和标题也要审。有些问题不在图上，在文案的措辞上，用词不当一样会引发争议。我给自己的原则是：只描述画面里客观存在的东西，不臆测人物身份，不评价个人，不使用可能引发对立的表述。宁可写得平淡一点，也不为了"更搞笑"去加戏。

版权这块也得说一句。这类图片很多是转载来的，来源复杂。我的做法是：只收允许转载的内容，来源不明的宁可不用；每张图尽量记录来源链接；收到权利人反馈立即下线，不做争辩。这个态度比任何技术手段都重要。

5. 成本与性能：带宽、缓存、防盗链的实操账

5.1 把每张图的体积压下来的六个具体手段

前面算过，流量是成本大头。所以压体积这件事，值得反复做。我总结了六个按性价比排序的手段。

第一，控制上传原图的尺寸上限。超过 2400 像素宽的一律缩到 2400。这一步能砍掉大量"手机直出"的大文件，那些原图动辄四五兆，缩完可能只剩几百 K，画质肉眼无差。

第二，一律输出 WebP。同等画质下，WebP 比 JPEG 小 25% 到 35%。这是最省力的一步，只要在图片处理参数里加format,webp就完事。AVIF 更小，但编码慢、兼容性还没铺满，我目前只对少量大图做 AVIF 输出，用<picture>做渐进增强：

<picture> <source type="image/avif" srcset="...?format,avif/resize,w_400"> <source type="image/webp" srcset="...?format,webp/resize,w_400"> <img src="...?format,jpg/resize,w_400" width="400" height="300" alt="描述"> </picture>

第三，质量参数分场景。缩略图 72，预览图 76，大图 80。别全站一个值，大图压太狠细节全丢，缩略图压太松纯属浪费。

第四，去掉元数据。手机拍的照片里塞着定位、设备型号、拍摄参数，这些对展示毫无用处，还占几十 KB。图片处理时加个去元数据的参数，或者上传时用工具统一清一遍。

第五，合理裁切。缩略图按object-fit: cover裁剪之后，实际只需要图片中间一部分。如果能提前裁好再输出，体积还能再降。但这个要看具体实现，实时裁切的服务不一定支持，得看选型。

第六，长缓存加内容哈希。前面讲过，命中率从 80% 提到 96%，等于回源流量少了四分之三。这一条不直接减体积，但直接减账单。

把这六条叠起来，我同一批图的总下行流量比优化前少了差不多六成。这个幅度值得花两天时间做。

5.2 防盗链与防爬的几个层次

图片站被别的站直接引用图片，是很常见的。轻则白付流量，重则对方页面看起来比你还正规。防护手段我有三层，按成本从低到高。

第一层是 Referer 白名单。在 CDN 或源站配置里判断请求来源，只允许自己的域名和空 Referer（直接访问）通过，其余返回 403。配置很简单：

location ~* \.(jpg|jpeg|png|webp|avif)$ { valid_referers none blocked server_names *.example.com; if ($invalid_referer) { return 403; } expires 365d; add_header Cache-Control "public, max-age=31536000, immutable"; }

注意none要留着，否则用户在浏览器里直接打开图片链接会看不到，而且很多应用内打开的场景 Referer 是空的。这个方案挡不住所有情况，因为 Referer 可以伪造，但能挡住绝大多数随手引用的。

第二层是签名 URL。给图片地址加上时间戳和签名，过期就失效。这个适合对版权比较在意的场景，但代价是缓存效率下降，因为 URL 每次都变。所以我只用在大图上，缩略图不签。

第三层是行为识别。如果发现某个来源短时间内请求大量不同图片，且请求间隔极其规律，基本可以判定是爬取。这时候可以对这个来源做限速或者验证。这一层我不太愿意做太重，因为误伤真实用户的代价比被爬一点图更大。

顺便说一句，防爬的优先级其实低于防带宽滥用。有人爬你的图，损失的是带宽；但如果爬完之后在你服务器上疯狂请求不存在的路径，损失的是源站性能。所以我对 404 的路径也做了短缓存和限流，这个更实际。

6. 常见问题与排查技巧实录

6.1 图片加载异常速查表

下面这张表是我这几年遇到频率最高的问题，按现象归类，基本覆盖了八成情况。

这张表建议贴在工位上，出问题时先对号入座，比盲猜快得多。

6.2 几个只有踩过才知道的坑

说几个文档里不会写、但实际很要命的细节。

第一个坑：图片处理参数要写在文件名之后、查询参数之前的位置，不同服务的语法不一样。我第一次换服务商的时候，把参数原样搬过去，结果全部返回原图，白白多跑了三天流量才发现。换服务商的第一件事应该是拿五张图做全链路验证，别急着切流量。

第二个坑：CDN 刷新缓存的代价比想象中大。有次改了图片处理参数，想着"刷一下缓存就好了"，结果刷完之后所有图片同时回源，源站瞬间被打满，页面全挂。后来学乖了，改参数的时候新老 URL 并存一段时间，让缓存自然过期，绝不整站刷新。

第三个坑：图片的 EXIF 方向信息。手机拍的竖图，实际像素是横的，靠 EXIF 里的方向标记来旋转显示。如果你在上传时去掉了元数据但没做旋转，图就会躺着。这个 bug 极其隐蔽，因为在你自己的浏览器里可能正常（浏览器读了 EXIF），但在某些客户端里就是歪的。处理方式是上传时先按 EXIF 旋转好，再清元数据。

第四个坑：中文文件名的兼容问题。早期我直接拿上传的原始文件名做存储键，结果中文名在各种环节被转义、被截断，出现一堆 404。后来统一改成"日期 + 随机串 + 扩展名"的规则，彻底解决。原始文件名只存在数据库里做展示，不参与路径拼接。

第五个坑：object-fit: cover裁掉笑点。这个问题不是技术问题，是内容问题。有一批图的主体在画面边缘，缩略图一裁就剩个背景，用户根本不知道在讲什么。后来我给每张图加了一个"焦点位置"字段，可选左上、居中、右下几个值，渲染时映射到object-position，观感立刻不一样。这个字段录入成本很低，值不值得做，看你站里图的构图分布。

第六个坑：统计口径不一致。我一度以为某个页面访问量很高，后来发现是把爬虫和预加载都算进去了。图片站的预加载请求量可能是真实浏览的数倍，统计如果不做过滤，所有数据都是虚的。建议在统计里排除掉没有 Referer、UA 异常、以及请求间隔过于规律的流量，数据才有参考价值。

最后分享一个我觉得挺有用的小习惯：给每次改动留一个可回滚的开关。图片站这东西，配置一改就是全站生效，没有灰度的话出问题是灾难性的。我现在的做法是，任何影响展示的改动都走一个配置项，出问题改一个值就能退回去。这个习惯救过我至少三次。