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

做图片站这件事我前后折腾过三个版本从最早一台小机器上跑静态目录到后来上对象存储加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-age31536000, immutable; }immutable这个指令很关键它告诉浏览器这个 URL 的内容永远不会变别来问我有没有更新。因为文件名带哈希内容一变文件名就变所以这个假设是成立的。实测下来命中率能从 80% 出头提到 96% 以上。第三是回源保护。CDN 回源带宽通常比边缘带宽贵如果哪天缓存被刷了或者有人恶意构造不存在的 URL回源请求会暴涨。我在源站侧加了一个简单的限流同时对 404 的 URL 也做了短时间缓存避免同一批不存在的路径反复穿透。至于带宽成本我拿一个真实量级算给你看。假设站点日均 10 万 PV列表页每页加载 20 张缩略图每张按 30KB 算后面会讲这个参数怎么来的那一天的下行流量是10 万 × 20 × 30KB ≈ 60GB/天外加详情页假设 10% 的 PV 会点进详情页看大图每张 300KB1 万 × 300KB ≈ 3GB/天合起来约 63GB/天一个月接近 1.9TB。按常见 CDN 阶梯价每 GB 两毛左右估算月成本大概三百多块。这个数字说明一个很重要的结论图片站的成本大头在流量不在存储。10 万张图按每张 300KB 算才 30GB 存储一个月几块钱但流量费是它的十几倍。所以所有优化精力都应该优先投向把每张图的体积压下来而不是抠存储。成本项量级估算优化优先级CDN 下行流量约 1.9TB/月最高对象存储容量约 30-50GB低回源流量约为下行的 3%-5%中数据库与计算小规格实例足够低2.2 图片处理链路格式、尺寸与压缩参数怎么定这块是省钱的核心也是最容易做错的地方。先把结论摆出来原图只存一份其余全部实时或准实时生成衍生图格式优先 WebPAVIF 做渐进增强JPEG 兜底。为什么不存多套尺寸因为尺寸需求是变化的。今天列表页缩略图 400 宽明天改版可能变 360 宽如果预先生成好改一次版就要重跑全站图片几万张图跑一遍既慢又费钱。用对象存储自带的图片处理能力在 URL 上拼参数实时输出改参数只是改个字符串的事https://img.example.com/photo/2024/a1b2c3d4.jpg?x-oss-processimage/resize,w_400/format,webp/quality,q_78这个 URL 的每一段都有讲究。resize,w_400是等比缩放到宽 400高度自适应比固定宽高好因为写实类图片长宽比差异极大强制裁切会把笑点裁没。format,webp输出 WebP兼容性现在基本没问题。quality,q_78是我反复试出来的平衡点。质量参数到底取多少这个不能拍脑袋。我做过一轮对比拿二十张典型图片分别用 q60、70、78、85、92 压成 WebP然后让几个朋友盲看能不能分辨。结论是q75 到 80 之间基本看不出差别q60 开始文字类的细节会糊q85 以上体积涨得飞快但肉眼收益极小。所以列表页缩略图用 q72 就够详情页大图用 q80原图备份保持原样不压。尺寸上我目前设了三档缩略图宽 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标签带loadingeager并加上fetchpriorityhigh其余全部loadinglazy。不过原生懒加载的触发时机由浏览器决定各家的预加载距离不一样为了控制得更精确我额外用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 个太多了用户不会看。我目前的划分大概是日常场景、工作办公、交通出行、餐饮食物、宠物动物、文字标识、产品说明、建筑空间、运动健身、其他杂项。这个划分覆盖了大部分内容也不至于让人选择困难。标签就不设上限了但要做合并。同一类意思的标签只留一个比如打工人和社畜和上班族统一成一个其余做同义词映射。否则标签越滚越多最后每个标签下面只有一两张图等于没有。维度分类标签数量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 typeimage/avif srcset...?format,avif/resize,w_400 source typeimage/webp srcset...?format,webp/resize,w_400 img src...?format,jpg/resize,w_400 width400 height300 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-age31536000, immutable; }注意none要留着否则用户在浏览器里直接打开图片链接会看不到而且很多应用内打开的场景 Referer 是空的。这个方案挡不住所有情况因为 Referer 可以伪造但能挡住绝大多数随手引用的。第二层是签名 URL。给图片地址加上时间戳和签名过期就失效。这个适合对版权比较在意的场景但代价是缓存效率下降因为 URL 每次都变。所以我只用在大图上缩略图不签。第三层是行为识别。如果发现某个来源短时间内请求大量不同图片且请求间隔极其规律基本可以判定是爬取。这时候可以对这个来源做限速或者验证。这一层我不太愿意做太重因为误伤真实用户的代价比被爬一点图更大。顺便说一句防爬的优先级其实低于防带宽滥用。有人爬你的图损失的是带宽但如果爬完之后在你服务器上疯狂请求不存在的路径损失的是源站性能。所以我对 404 的路径也做了短缓存和限流这个更实际。6. 常见问题与排查技巧实录6.1 图片加载异常速查表下面这张表是我这几年遇到频率最高的问题按现象归类基本覆盖了八成情况。现象常见原因排查方式处理部分图一直转圈URL 拼错或对象不存在直接访问图片 URL 看返回码修正路径或补传全站图都挂CDN 配置变更或域名解析异常换网络访问、看 CDN 控制台回滚配置图显示但很糊请求尺寸参数没生效看响应头里的实际尺寸检查处理参数拼写手机端图变形缺 aspect-ratio 占位看容器高度是否随图变化补宽高属性滚动卡顿DOM 数量过多看渲染的节点数分批渲染加 content-visibility首屏慢但后段快首屏图没设优先级看资源加载瀑布图前几张加 fetchpriority重复图多未做指纹去重抽查 phash 距离补去重流程流量异常上涨被外站引用或爬取看 Referer 统计开防盗链这张表建议贴在工位上出问题时先对号入座比盲猜快得多。6.2 几个只有踩过才知道的坑说几个文档里不会写、但实际很要命的细节。第一个坑图片处理参数要写在文件名之后、查询参数之前的位置不同服务的语法不一样。我第一次换服务商的时候把参数原样搬过去结果全部返回原图白白多跑了三天流量才发现。换服务商的第一件事应该是拿五张图做全链路验证别急着切流量。第二个坑CDN 刷新缓存的代价比想象中大。有次改了图片处理参数想着刷一下缓存就好了结果刷完之后所有图片同时回源源站瞬间被打满页面全挂。后来学乖了改参数的时候新老 URL 并存一段时间让缓存自然过期绝不整站刷新。第三个坑图片的 EXIF 方向信息。手机拍的竖图实际像素是横的靠 EXIF 里的方向标记来旋转显示。如果你在上传时去掉了元数据但没做旋转图就会躺着。这个 bug 极其隐蔽因为在你自己的浏览器里可能正常浏览器读了 EXIF但在某些客户端里就是歪的。处理方式是上传时先按 EXIF 旋转好再清元数据。第四个坑中文文件名的兼容问题。早期我直接拿上传的原始文件名做存储键结果中文名在各种环节被转义、被截断出现一堆 404。后来统一改成日期 随机串 扩展名的规则彻底解决。原始文件名只存在数据库里做展示不参与路径拼接。第五个坑object-fit: cover裁掉笑点。这个问题不是技术问题是内容问题。有一批图的主体在画面边缘缩略图一裁就剩个背景用户根本不知道在讲什么。后来我给每张图加了一个焦点位置字段可选左上、居中、右下几个值渲染时映射到object-position观感立刻不一样。这个字段录入成本很低值不值得做看你站里图的构图分布。第六个坑统计口径不一致。我一度以为某个页面访问量很高后来发现是把爬虫和预加载都算进去了。图片站的预加载请求量可能是真实浏览的数倍统计如果不做过滤所有数据都是虚的。建议在统计里排除掉没有 Referer、UA 异常、以及请求间隔过于规律的流量数据才有参考价值。最后分享一个我觉得挺有用的小习惯给每次改动留一个可回滚的开关。图片站这东西配置一改就是全站生效没有灰度的话出问题是灾难性的。我现在的做法是任何影响展示的改动都走一个配置项出问题改一个值就能退回去。这个习惯救过我至少三次。