图片CDN与边缘优化实战:缓存策略、图片处理型CDN与动态裁剪

图片是大多数站点里流量最重、请求最多的一类资源。一个电商详情页轻轻松松几十张图,一个内容站的首屏也压着好几兆。把这些图交给 CDN 分发,几乎是标配。但很多团队接了 CDN 之后,命中率上不去、成本降不下来、图片改了半天不更新,问题往往不在 CDN 本身,而在于缓存策略和图片处理链路没设计对。

这篇文章想把图片 CDN 这条链路拆开讲清楚:缓存 key 怎么定、命中率怎么提、图片处理型 CDN 的动态裁剪怎么用、边缘怎么做格式自适应、刷新和防盗链怎么搞。文末照例老实交代几个绕不开的坑,别把 CDN 当成一接就万事大吉的银弹。

缓存 key:命中率的地基

CDN 的本质是一层分布在边缘节点的缓存。一个请求进来,边缘节点先算出这个请求的缓存 key,拿 key 去本地找;找到了就是命中(HIT),直接返回;没找到就回源站(MISS),取回来存一份再返回。命中率的高低,一大半取决于缓存 key 是怎么算的。

默认情况下,缓存 key 通常是 协议 + 域名 + 路径 + 查询字符串。这里最容易翻车的就是查询字符串。假设你的图片 URL 后面跟着一堆统计参数:

复制代码

/photo/cat.jpg?utm_source=weibo&t=1720512000

同一张图,来自微博的和来自朋友圈的,utm_source 不一样;每次刷新 t 时间戳还在变。如果缓存 key 把整个查询字符串都算进去,那么这张图在缓存里会存成无数个互不相同的副本,命中率被稀释到接近于零,每次几乎都在回源。这就是典型的缓存碎片。

解决办法是精细化控制缓存 key,只保留真正影响图片内容的参数(比如裁剪尺寸),把跟内容无关的统计参数、时间戳全部剔除出 key。绝大多数 CDN 控制台都支持配置"忽略指定参数"或"仅保留指定参数"。在 Nginx 自建缓存层里,思路是这样的:

nginx 复制代码

# 只把影响图片内容的参数纳入缓存 key,其余一律忽略
map $arg_w $img_w { default ""; ~^\d+$ $arg_w; }   # 宽度,只认纯数字
map $arg_h $img_h { default ""; ~^\d+$ $arg_h; }   # 高度,只认纯数字

proxy_cache_path /data/cache levels=1:2 keys_zone=img:100m
                 max_size=20g inactive=30d use_temp_path=off;

server {
    location ~* \.(jpg|jpeg|png|webp)$ {
        proxy_cache img;
        # 缓存 key 只由 路径 + 宽 + 高 组成,utm/时间戳不参与
        proxy_cache_key "$uri|w=$img_w|h=$img_h";
        proxy_cache_valid 200 30d;      # 正常图缓存 30 天
        proxy_cache_valid 404 1m;       # 404 也短暂缓存,挡住穿透
        add_header X-Cache-Status $upstream_cache_status;  # HIT/MISS 可观测
        proxy_pass http://origin;
    }
}

上线后别忘了看 X-Cache-Status 这个响应头。把它接进日志统计,HIT 占比就是你的命中率,这是后续所有优化的度量基准。命中率能不能从 80% 提到 95%,直接决定回源带宽和源站压力。

图片处理型 CDN:一张原图,按需出图

传统 CDN 只做分发,你存什么它发什么。图片处理型 CDN 更进一步:源站只存一张高清原图,前端请求时通过 URL 参数指定要什么尺寸、什么格式、什么质量,边缘现场处理后返回,并把处理结果缓存下来。

一个常见的 URL 约定长这样:

复制代码

/photo/cat.jpg?w=400&h=300&fit=cover&format=webp&q=80

w / h:目标宽高
fit:裁剪模式,cover 铺满裁掉多余、contain 完整留白
format:输出格式,转 WebP/AVIF
q:压缩质量

好处很直接:列表页用 400px 缩略图,详情页用 1200px 大图,统统一张原图搞定,不用在上传时预生成一堆尺寸,也不用在源站堆一柜子文件。前端做响应式也简单,一套 srcset 把不同宽度列出来,浏览器自己挑:

html 复制代码

<img
  src="/photo/cat.jpg?w=800&format=webp"
  srcset="/photo/cat.jpg?w=400&format=webp 400w,
          /photo/cat.jpg?w=800&format=webp 800w,
          /photo/cat.jpg?w=1200&format=webp 1200w"
  sizes="(max-width: 600px) 100vw, 800px"
  alt="示例图">

如果你想自建这层能力,边缘参数解析可以这么组织,核心是先白名单校验参数,再交给底层图片库处理:

js 复制代码

// 边缘函数:解析并校验图片处理参数
function parseImageParams(url) {
  const p = new URL(url).searchParams;
  const clamp = (v, min, max) => Math.min(Math.max(v | 0, min), max);

  // 尺寸设上限,防止有人请求 w=99999 把节点内存打爆
  const w = p.has('w') ? clamp(+p.get('w'), 1, 4096) : null;
  const h = p.has('h') ? clamp(+p.get('h'), 1, 4096) : null;

  // 格式走白名单,非法值一律回退,避免参数爆炸
  const allowFmt = ['webp', 'avif', 'jpeg', 'png'];
  const format = allowFmt.includes(p.get('format')) ? p.get('format') : null;

  const q = p.has('q') ? clamp(+p.get('q'), 30, 90) : 80;
  const fit = ['cover', 'contain'].includes(p.get('fit')) ? p.get('fit') : 'cover';

  return { w, h, format, q, fit };
}

注意里面两处防御:尺寸设硬上限,格式走白名单。这两条不是可选项,原因下面讲坑的时候会展开。

边缘做 WebP/AVIF 自适应:一个 URL 服务所有浏览器

WebP 比 JPEG 小 25%~35%,AVIF 更狠,但老浏览器不一定认。传统做法是前端用 <picture> 写多个 <source> 让浏览器降级,但这样 HTML 里就写死了格式,不够干净。

更优雅的做法是把格式协商放到边缘。浏览器每个请求都带 Accept 头,声明自己支持哪些格式。边缘节点读这个头,支持 AVIF 就返回 AVIF,只支持 WebP 就发 WebP,都不支持退回 JPEG------URL 始终是同一个,格式在边缘动态决定。

这里有个关键的缓存陷阱:同一个 URL 现在会因浏览器不同返回不同格式的字节。如果缓存 key 不区分,A 浏览器把 AVIF 存进缓存,B 浏览器(不支持 AVIF)命中后拿到一张打不开的图。解决办法是给响应加上 Vary: Accept,让 CDN 按 Accept 分桶缓存。但 Accept 头取值五花八门,直接 Vary 会把缓存切得太碎,所以实践中一般在边缘把它归一化成有限几档再参与 key:

nginx 复制代码

# 把杂乱的 Accept 头归一化成 avif / webp / jpeg 三档
map $http_accept $img_variant {
    default          "jpeg";
    "~*image/avif"   "avif";
    "~*image/webp"   "webp";
}

location ~* \.(jpg|jpeg|png)$ {
    proxy_cache img;
    # variant 参与 key:同一 URL 按能力分三桶,而不是按原始 Accept 无限分
    proxy_cache_key "$uri|w=$img_w|fmt=$img_variant";
    proxy_pass http://image_processor;
}

三档缓存桶,既拿到了格式自适应的收益,又把缓存碎片控制在可接受范围。

缓存刷新与版本:改图之后怎么让它立刻生效

图片进了 CDN 强缓存,好处是快,代价是改了不更新。有两条路。

主动刷新(Purge):改图后调 CDN 的刷新接口,把对应 URL 从边缘节点清掉,下次请求重新回源。适合运营手动改图这种低频场景。缺点是刷新有生效延迟(通常几秒到几分钟),而且大批量刷新往往有频率限制。

版本化 URL(Cache Busting) :更推荐。图片内容一变,URL 就变------要么文件名带内容 hash(cat.a1b2c3.jpg),要么挂一个版本参数(cat.jpg?v=2)。URL 变了,缓存 key 就变,新图天然是一次全新的 MISS,老图缓存自然过期淘汰。这样图片可以设永久强缓存 (Cache-Control: max-age=31536000, immutable),完全不用刷新,命中率还高。

两者不冲突:构建产物、上传即定的图用版本化;确实需要"原地覆盖同一个 URL"的运营场景,才动用 Purge 兜底。

防盗链:别让别人白嫖你的带宽

图片 URL 是公开的,别的站点直接 <img> 引你的图,带宽账单算你头上。最基础的一层是校验 Referer,只放行自己域名的来源:

nginx 复制代码

location ~* \.(jpg|jpeg|png|webp)$ {
    valid_referers none blocked server_names *.yoursite.com;
    if ($invalid_referer) {
        return 403;   # 非白名单来源直接拒绝
    }
    proxy_pass http://origin;
}

Referer 能挡住大部分傻瓜盗链,但它可以伪造,不是强防护。真要防付费内容被扒,得上URL 签名 :给每个 URL 附一个带过期时间的签名参数(?sign=xxx&expire=xxx),边缘校验签名和时效,过期即失效。代价是 URL 不再是静态可缓存的固定串,签名一变缓存 key 就变,得把签名参数排除出缓存 key、只做鉴权,别让它污染缓存。安全和命中率之间,这里要自己权衡。

老实说几个绕不开的坑

CDN 这套东西收益很大,但下面几个问题,规模一上来就会找上门,提前知道比事后救火强。

缓存击穿与雪崩 :一张热门图缓存刚好过期的瞬间,成千上万请求同时打到源站,把源站瞬间压垮。要靠回源合并(Nginx 的 proxy_cache_lock,同一 key 只放一个请求回源,其余等结果)加上过期时间加随机抖动来缓解,别让一批图在同一秒集体过期。

参数爆炸导致缓存碎片 :图片处理型 CDN 最容易踩的坑。w 从 1 到 4096 每个值都能生成一张独立缓存,再乘上格式、质量、裁剪模式,组合是天文数字。绝大多数是长尾,命中率极低,白占存储还拉低整体命中。务必在业务层收敛尺寸档位------前端只允许出几个固定宽度(400/800/1200),而不是任由 URL 传任意值。前面代码里的白名单和 clamp,就是干这个的。

回源成本不是零:命中率 95% 听着很高,但那 5% 的 MISS,尤其是需要现场裁剪转码的首次请求,会实打实消耗源站 CPU 和回源带宽。图片处理是计算密集型的,大图转 AVIF 尤其吃 CPU。评估成本要把回源和边缘计算量一起算进去,不能只盯着分发带宽便宜就以为稳了。

多级缓存的一致性 :浏览器缓存、CDN 边缘缓存、源站缓存,三层各有各的过期逻辑。你在 CDN Purge 了,用户浏览器里那份 max-age 没到期照样是旧图。所以浏览器端对可能更新的图别设太长的 max-age,把长缓存留给版本化 URL,这两类要分开对待。

小结与顺手一提

图片 CDN 优化的核心就三件事:把缓存 key 设干净 (只留影响内容的参数)、用处理型 CDN 收敛源站存储 (一张原图按需出图)、把格式协商放到边缘(一个 URL 服务所有浏览器)。剩下的刷新、防盗链、防击穿,都是在这三条主线上打的补丁。度量始终围绕命中率,它是钱和体验的共同抓手。

写代码之外,日常处理图还是离不开一堆现成工具:命令行批处理有 ImageMagick、libvips;Node 侧有 sharp;想在浏览器里直接压图、转格式、抠图、改尺寸不装软件的,tudingai.cn 这类在线工具也能应付大部分零散需求。工具是次要的,把上面这套缓存和处理的思路理顺,才是图片这条链路真正省钱又快的关键。