核心需求

在设计图片存储和 CDN 加速系统时，我们需要平衡三个核心需求：加载速度、图片质量和存储成本。这三个目标往往相互制约，需要根据具体业务场景找到最佳平衡点。

需求三角模型

           加载速度
              /\
             /  \
            /    \
           /      \
          /        \
         /          \
        /            \
       /              \
      /                \
     /                  \
    /____________________\
  图片质量 ←----------→ 存储成本

不可能三角：在资源有限的情况下，很难同时达到最优的加载速度、最高的图片质量和最低的存储成本。

一、加载速度（Load Speed）

加载速度是用户体验的核心指标，直接影响页面加载时间、用户留存率和转化率。

1.1 关键指标

图片系统的”快”不能概括成”服务器响应多快”。用户真正关心的是这张图什么时候完整出现在屏幕上，它由首字节延迟、图片体积、缓存命中率和设备渲染能力共同决定。我把指标分成三层来盯：

三个使用上的注意事项：

1. 看分位数，不看均值。图片场景里 P99 往往对应”一张从没被访问过的大图触发了回源”，均值会把这个尖刺抹平。
2. 按维度下钻。同一个命中率，全国平均值可能很好看，但某个省份或某家运营商的边缘节点缺失会被完全掩盖。至少要按地域、运营商、设备类型分组看。
3. 指标必须能对应到动作。如果一个指标涨了却没人知道该改什么（改格式、改 TTL，还是补节点覆盖），它就不该出现在面板上。

1.2 影响加载速度的因素

1.2.1 网络传输延迟

用户请求 → DNS 解析 → TCP 握手 → TLS 握手 → 服务器响应 → 数据传输 → 渲染
   │         │          │          │          │          │         │
  ~10ms    ~20-100ms   ~20ms      ~50ms     ~50-200ms   可变      ~16ms

优化策略：

• 使用 CDN 就近访问，减少网络延迟
• DNS 预解析和预连接
• HTTP/2 或 HTTP/3 多路复用
• TCP 连接复用

1.2.2 图片文件大小

1.2.3 CDN 节点覆盖

CDN 加速的前提是”用户附近有节点”。节点覆盖不是厂商宣传的节点总数，而是你的用户分布与边缘节点分布的重合度。

三个常见的坑：

• 节点多不等于覆盖好。厂商的节点数常按”部署机房”统计，用户实际落到的是这些机房里的某台机器，中间还隔着骨干网和城域网。
• 跨运营商互联不可控。同城电信用户命中了电信节点，但回源时源站在联通机房，这一段仍是跨网，延迟通常明显高于同网。
• 覆盖不足时用户仍然能拿到图，只是慢。所以它不会立刻报错，只表现为某些地区的回源率偏高、源站压力不均。这类问题必须靠按地域拆分指标才能发现。

因此验证节点覆盖不能只看”有没有接入 CDN”，而应该按地域拆开看回源率：如果某个地区的回源率明显高于全国均值，先怀疑覆盖，再怀疑缓存键设计。反过来，如果回源率在地域上分布均匀，说明瓶颈多半不在覆盖，而在缓存策略本身。

1.3 速度优化技术

1.3.1 图片格式优化

格式优化的收益是一次编码、长期兑现：体积降下来之后，CDN 流量费、边缘存储占用、回源带宽、用户手机流量同时受益。

格式不是越多越好，而是越多越贵。每多一种格式，就多一份存储、多一份处理计算、多一份派生图治理成本。所以策略应该是”一个主力格式 + 一个增强格式 + 一个兜底格式”，而不是把所有格式都生成一遍。

转换时机决定了体验和成本：

• 上传时同步转换：用户要等编码结束，AVIF 这类编码慢的格式尤其明显；好处是派生图在第一次访问前就绪。
• 上传后异步转换：上传立刻返回，后台队列生成派生图。这是主流做法，代价是短时间内可能拿到尚未就绪的尺寸，需要前端兜底。
• 边缘按需转换：不预生成，用户请求时由边缘节点实时转换。存储最省，但首次访问有额外延迟，且边缘资源有限。

我的选择是：WebP 异步预生成（主力）、AVIF 异步预生成（增强）、JPEG 兜底，长尾尺寸交给边缘按需处理。

格式协商发生在边缘：浏览器在请求头里声明支持哪些格式，CDN 按 Accept 头返回对应版本。协商的前提是同一张图的不同格式版本在缓存里是不同对象——如果缓存键没带上格式，一个用户拿到的 JPEG 会被缓存下来发给所有用户，这是一类很隐蔽的缓存污染。

1.3.2 响应式图片

同一张原图，在手机上只需要 400px 宽，在高像素屏上可能要 2000px 宽。响应式图片就是让浏览器自己挑合适的那一版。

机制由三个属性配合完成：

浏览器选图的过程是：先用 sizes 和视口宽度算出这张图需要多少 CSS 像素，再乘以设备像素比，最后从 srcset 里挑出不小于这个需求、且最接近的一版下载。

<img
  src="https://cdn.example.com/i/a3f8c2e1_800.webp"
  srcset="https://cdn.example.com/i/a3f8c2e1_400.webp 400w,
          https://cdn.example.com/i/a3f8c2e1_800.webp 800w,
          https://cdn.example.com/i/a3f8c2e1_1200.webp 1200w,
          https://cdn.example.com/i/a3f8c2e1_2000.webp 2000w"
  sizes="(max-width: 640px) 100vw, (max-width: 1024px) 50vw, 800px"
  width="800"
  height="533"
  alt="夜景"
/>

候选尺寸由谁生成，有两条路线：

• 服务端预生成：在固定尺寸白名单（如 400 / 800 / 1200 / 2000）上批量产出派生图。命中率高、首次访问快，代价是存储和无效派生图。
• 边缘按需生成：候选集可以更细，用户请求什么尺寸就生成什么尺寸。存储最省，代价是首次访问有延迟，且必须限制参数空间，否则恶意请求会造出海量变体。

两条路线可以叠加：白名单里的热门尺寸预生成并预热，白名单之外的长尾尺寸走边缘按需。

最容易踩的坑是 sizes 与 CSS 布局不一致。如果 sizes 写的是 50vw，实际布局里图片却被限制成 300px 宽，浏览器会按 50vw 去买更大的图——用户拿到的是一张用不上的大图，钱花在流量上，收益却在画质上。

1.3.3 懒加载（Lazy Loading）

首屏之外的大图如果立刻开始下载，会挤占带宽，让首屏真正重要的那张图变慢。懒加载就是让浏览器推迟加载视口之外的图片。

原生实现的判定机制：

浏览器决定是否加载
    │
    ├─ 图片距离视口的距离在阈值内 → 立即加载
    │    阈值受"有效连接类型"影响：
    │    慢网络 → 拉得更远（提前加载，避免滚到时才发现没网）
    │    快网络 → 拉得更近（不浪费流量）
    │
    └─ 图片在阈值之外 → 暂不下载，滚动接近时再触发

关键点：

1. loading="lazy" 只对”尚未进入视口附近”的图片有意义。首屏图片加上 lazy，等于让 LCP 元素主动推迟自己的加载，是负优化。
2. 懒加载不会让图片消失。触发加载后依然要走完整的 DNS + 连接 + 传输流程，只是把发起时刻推迟了。
3. 降级方案不可省。不支持原生 lazy 的浏览器需要在 onload 里再赋 src，这时要注意别让浏览器把原 src 当成”真实地址”缓存下来。
4. 占位图要先画出来。用 CSS 给图片容器预留宽高比，避免懒加载生效后发生布局抖动。

首屏图片的正确做法是：不写 lazy，用 fetchpriority="high" 提优先级，其余图片统一 loading="lazy" + decoding="async"，让解码不阻塞主线程。

二、图片质量（Quality）

图片质量直接影响用户的视觉体验和产品形象，需要在清晰度和文件大小之间找到平衡。

2.1 质量评估指标

“看起来还行”不能作为验收标准。要判断一张压缩后的图能不能上线，得先有一个可量化的口径。

实践中的三条经验：

1. 单一指标不够。SSIM 高的图可能存在色带，PSNR 低的图可能只是整体亮度偏了一点。要按内容类型组合使用——照片看 SSIM + 人工抽检，UI 截图重点看文字区域的清晰度。
2. 阈值要按内容类型分开定。同一张夜景照和同一张白底产品图，在同一个质量参数下的 SSIM 差异很大，用一个全局阈值一定会误伤其中一类。
3. 把”是否无损”和”是否够用”分开验。PNG 转无损 WebP 要求像素完全一致，用像素差判定；而展示图只要达到目标 SSIM 就够了，剩下的是体积的账。

2.2 质量与大小的权衡

图片体积可以用一个粗略模型理解：

$$\text{bytes} \approx W \times H \times b(q, c)$$

其中 $W$ 和 $H$ 是输出分辨率，$b(q, c)$ 是每像素比特数，$q$ 是质量因子，$c$ 是内容复杂度（纹理、噪点越多，同样的质量下每像素比特数越高）。

这个模型给出三个可以直接用起来的判断：

• 降分辨率是线性降本。宽高各减半，体积大致降到四分之一。
• 降质量因子是边际递减。质量从 80 提到 90，体积涨得比想象中快，而主观差异越来越难察觉。
• 内容复杂度决定曲线位置。同一张图，噪点多的夜景比平滑的风景更”费比特”，两者不能共用一套参数。

于是权衡的实践形态是先选分辨率，再选质量：

常见的一个反直觉结论：把质量因子从 80 降到 70，省下的体积通常不如把宽度从 1200 降到 800。因为宽度是线性项，而质量因子的收益递减。

2.3 智能质量调整

固定质量参数意味着”所有用户、所有场景、所有网络”拿到同一张图。智能质量调整是把这些差异显式建模，在几个可调的档位之间选择。

决策输入（信号）与对应动作：

判定顺序很重要：先由业务和用户档位定”画质下限”，再由网络和设备在这个下限之上做降级，最后才轮到网络。这样可以避免弱网把付费用户的作品压成糊图。

三档位策略长这样：

档位    分辨率上限   质量因子   格式      适用
─────────────────────────────────────────────
high    1600px       q80+       AVIF/WebP 付费用户、详情页、良好网络
medium  900px        q75        WebP      默认档
low     480px        q65        WebP/JPEG 弱网、列表页预览

降质要设下限：再差的网络也不应该给用户一张完全糊掉的图，保留可辨识度比省流量更重要。另一个更稳妥的做法是先给低质、再升级：先返回 480px 版本让页面成形，检测到网络良好后再请求高质版本替换，用户感知是”图慢慢变清晰”，而不是”一直糊”。

最后一个提醒：动态调整会让同一个 URL 在不同用户那里对应不同画质。如果 CDN 按 URL 缓存，同一个 URL 只会有一份缓存，动态调整必须落在 URL 上（不同档位不同 URL）或者干脆由前端选择 URL，否则动态调整就失效了。

2.4 质量监控

质量是唯一不能只靠上线前抽检的维度：压缩策略会升级、设备会变化、内容类型分布也会变。质量监控要回答两个问题：现在的产出是否仍然达标，以及用户是否在投诉。

两个容易忽略的要点：

1. 抽样要按内容类型分层。整体抽样时，自然图像会淹没 UI 截图这类小众但敏感的类型。抽样比例要保证每种内容类型都有足够样本，而不是靠总量稀释。
2. 监控口径要和验收口径一致。开发时用某个 SSIM 阈值验收，线上监控也必须盯同一个阈值；换了口径，指标就失去了对照意义。

质量监控真正的闭环是：处理时记录 → 抽样计算 → 发现偏差 → 调整参数 → 灰度 → 复验。只有”记录”没有”调整”的监控，几个月后只会变成没人看的图表。

三、存储成本（Cost）

存储成本是图片系统运营的主要开支，需要精细管理和优化。

3.1 成本构成

图片系统的账单不是一个总数，而是若干个独立计费项叠出来的。把它们拆开，才能知道该往哪使劲。

两个反直觉的点：

• 请求数可能比流量更贵。在流量单价下降或图片都很小的场景里，海量小请求的费用会盖过流量本身。列表页一次加载 20 张图，就是 20 次请求。
• 存储看着便宜，但它是”复利”支出。原图永不删除、派生图无限增长，容量只会单向上升；而流量费是每天重新结算的。长期看，存储和生命周期管理决定成本曲线是否失控。

3.2 成本估算模型

有了成本构成，就可以写一个模型来做”改一个参数，账单会怎么变”的推演。

月度总成本：

$$C_{month} = C_{storage} + C_{cdn} + C_{origin} + C_{request} + C_{compute} + C_{audit}$$

其中流量相关的两项最值得单独拆出来。设 $N$ 为月请求数，$h$ 为边缘命中率，$\bar{S}$ 为平均单图体积，$p_{edge}$ 与 $p_{origin}$ 分别为 CDN 出网和回源的单价：

$$C_{cdn} = N \cdot \bar{S} \cdot p_{edge}$$ $$C_{origin} = N \cdot (1 - h) \cdot \bar{S} \cdot p_{origin}$$

存储项则由分层决定，设 $V_i$ 为第 $i$ 类对象的容量，$p_{tier(i)}$ 为对应存储类型的单价，$T$ 为计费月数：

$$C_{storage} = T \cdot \sum_i V_i \cdot p_{tier(i)}$$

这个模型最有价值的地方在于它暴露了三个弹性完全不同的杠杆：

几个实用推论：

1. 体积是第一杠杆。体积减半，CDN 流量和回源流量同时减半；命中率从九成提到九成六，回源流量只减少六成左右，而命中率越往上越难提。
2. 模型里的单价必须来自配置而不是硬编码。云厂商的单价会调整，把单价做成可替换的输入，模型才能长期使用。
3. 模型是用来做敏感度分析的。把单价、请求量、体积做成变量，输出”哪个变量动一下省得最多”，比月底看账单再猜要高效得多。

实践上建议把模型做成一张可维护的表：输入假设（请求量、平均体积、命中率、容量分布），输出预估月成本，再和实际账单对比，偏差超出容忍范围时说明模型或实现有问题。

3.3 成本优化策略

3.3.1 存储分层

分层的本质是：用”访问代价”换”存储单价”。热数据留在贵的存储里，冷数据挪到便宜的存储里。

划分依据不是单纯的时间，而是三个信号叠加：

1. 访问频次：最近一段时间的真实访问量，这是最客观的信号。
2. 业务语义：头像不能因为没人访问就归档，付费作品不能因为超过天数就降级；用户主动删除的图片要立刻进删除流程，而不是归档。
3. 可重建性：派生图可以随时重新生成，所以先清理、再降级；原图是事实来源，只能降级，不能随便删。

三个必须注意的坑：

• 分层迁移本身要花钱。大批量迁移会产生请求费用和一次性的操作开销，迁移频率不宜太高。
• 归档后不是”能读”，而是”要先解冻”。任何取回路径都要处理”对象处于归档状态”的分支，否则会变成一串 403。
• 最小存储时长会让”频繁进出”变贵。把对象在低频和标准之间来回搬，看起来省钱，实际可能因为计费周期取整而更贵。

3.3.2 图片生命周期管理

分层解决的是”存得便宜”，生命周期解决的是”该消失的会消失”。

一个图片对象的生命周期可以分为四个阶段：

配套的规则要落到三类对象上：

生命周期规则必须绑定业务语义，不能只按文件年龄粗暴处理。同样是一张很久没访问的图片，头像、营销素材、付费作品、已下架商品图的处理完全不同。规则引擎要能读到这些语义，生命周期才不是”定时炸弹”。

另外两层容易被忽略的工作：

• 可恢复窗口：物理删除前先标记为软删除，保留一段可恢复时间。这既防误删，也给审核召回留了后路。
• 删除要联动清理：删图片不只是删一个对象，还要清掉它的派生图、CDN 缓存和元数据。CDN 缓存不清理的话，即使源文件没了，边缘仍可能在缓存期内继续对外提供。

3.3.3 CDN 缓存优化

缓存优化有三件事要同时做对：缓存键稳定、TTL 分级、刷新与预热有章法。

缓存键决定”什么算同一张图”。参与缓存键的应该只有影响图片内容的参数：

缓存键 = 对象路径 + 尺寸 + 格式 + 质量 + 裁剪方式 + 版本号

不参与缓存键：签名、时间戳、追踪参数、随机数
这些参数在边缘节点校验，而不是用来区分缓存对象

把时间戳放进缓存键是最常见的错误——每次请求都是一个新对象，命中率会掉到接近零。

TTL 分级让不同热度的图片用不同的过期策略：

配合 stale-while-revalidate，可以在缓存过期后先返回旧内容、后台异步更新，用户几乎无感。

刷新解决”必须立刻生效”的场景：审核召回、违规下架、内容被替换。这类场景靠 URL 刷新或目录刷新，把边缘缓存主动清掉，同时保留一个版本号用于整目录切换。刷新是有成本的（逐节点下发），所以只在必要时用。

预热解决”热点来得比缓存填充更快”的场景：运营活动、首页推荐位、突发热点。提前把指定的 URL 推送到边缘节点，避免第一批用户集体触发回源。

最后是污染与排查：

• 用参数白名单限制允许的尺寸和格式组合，防止恶意请求造出海量变体把边缘缓存撑爆。
• 排查”用户看到旧图”时，先确认缓存键是否包含版本号，再看刷新是否覆盖了全部节点，最后才怀疑源站。
• 命中率要按地域、格式、URL 类型分组看。整体命中率被热门 URL 拉高，长尾 URL 的命中率崩塌往往看不出来。

四、平衡策略

4.1 场景化配置

同一套压缩参数套所有场景，是图片系统最常见的浪费。场景化配置的意思是：按图片在业务里的角色，规定它该长什么样。

配置要落在一份可版本化的规则表里，而不是散落在各个业务代码中：

场景规则 = {
  场景标识, 允许的尺寸列表, 允许的格式列表,
  质量因子, 裁剪方式, 是否允许放大, 缓存 TTL
}

三个配套要求：

1. 规则要能约束请求，而不只是指导生成。CDN 回源时要按白名单校验参数，非法参数直接拒绝，否则”场景化配置”会被恶意请求绕过去。
2. 规则变更要走灰度。把规则做成版本号，新旧版本共存一段时间，按比例或按图片 ID 分组切换，出问题能一键回退。
3. 场景要跟业务归属绑定。图片在元数据里就记录了它的业务类型，处理时直接读，不需要前端传参——前端传的场景值是不可信的。

4.2 动态调整策略

场景化配置是静态的，动态调整是运行时的。两者结合，才是完整的平衡策略。

调整发生在三个不同的时间尺度上：

触发调整的信号与护栏：

三条必须坚持的原则：

1. 调整要可逆。每次变更都有版本号、灰度比例和一键回滚开关。成本优化最怕的不是没优化，而是优化到一半回不去。
2. 调整要有观测窗口。参数改动后至少观察完整的业务周期再下结论——一个页面的流量高峰在晚上，用早上的数据评估晚上的改动，结论一定是错的。
3. 动态调整不能破坏缓存语义。只要调整会改变图片内容，它就必须体现在 URL 上（尺寸、格式、质量、版本），否则 CDN 拿缓存里的旧内容发给新请求，等于没调整。

把这三层放在一起，整体策略就是：静态规则定边界，边缘协商做适配，前端在会话内兜底。三者都只做自己能看到的那部分信号，不要越界猜测。

小结

核心原则：

1. 速度第一：用户不会等待慢加载的图片
2. 质量够用：在可接受范围内最大化压缩
3. 成本可控：根据业务价值合理投入

在下一节中，我们将讨论具体的技术方案和架构设计。

上一章节

起点

下一章节

技术方案全景