图片缓存的核心思路是把常用资源留在离用户更近或更快可访问的地方：浏览器与CDN负责短时响应，服务端与CDN负责分发和削峰，前端离线缓存（Service Worker/Cache API/IndexedDB）和应用端磁盘缓存负责离线与持久化。配合合理的版本控制、压缩与格式选择，可以在不牺牲更新可控性的前提下，大幅降低带宽与首屏时延。
为什么要做图片缓存？先讲个直观的例子
想象你打开一个商品详情页，页面上有十几张图片。每次都从原始服务器拉取，延迟高且耗流量；如果把常用图片缓存到更快的层级，页面就能几乎瞬间显示，用户体验提升很明显。图片缓存的价值，就是把“慢的、昂贵的、易波动”的网络访问替换成“快的、便宜且稳定”的读取。
图片缓存的四大层次（从近到远）
- 浏览器缓存：用户端最靠近的缓存，受 HTTP 头部控制。
- 前端离线缓存（Service Worker/Cache API/IndexedDB）：比浏览器缓存更可控，适合离线场景与策略化缓存。
- CDN（内容分发网络）与边缘缓存：把资源复制到靠近用户的节点，减少跨区域延迟。
- 源服务器与代理缓存（例如反向代理）：服务端级别缓存，减轻源站压力并控制版本。
把每一层拆开讲清楚
1. 浏览器缓存（最常见也最基础）
浏览器根据响应头决定是否缓存和缓存多久。常见头部有：
- Cache-Control：最重要的头，可以指定 max-age、no-cache、no-store、must-revalidate 等。
- Expires：旧式的过期时间，通常被 Cache-Control 覆盖。
- ETag 与 Last-Modified：用于条件请求（If-None-Match / If-Modified-Since），帮助判断资源是否变更，节省流量。
实战要点：对静态、长期不变的资源建议设置较长的 max-age（例如一年），并通过文件名或查询串带版本号实现强制刷新；对频繁变化的资源建议短缓存或使用条件缓存。
2. 前端离线缓存：Service Worker 与 Cache API
浏览器缓存有时不可控（例如更新策略难以精准），Service Worker 提供更强的控制权。简单来说，你可以在安装阶段把关键图片预缓存（precache），也可以在运行时用自定义策略决定是否从网络获取或读取缓存。
常见策略包括：
- Cache First：优先读缓存，缓存不存在再去网络；适合变更少的资源。
- Network First：优先网络，失败时回退缓存；适合需要实时性的内容（例如用户头像可能会更新）。
- Stale-While-Revalidate：立即返回缓存，同时后台更新缓存；用户体验和数据新鲜度兼顾。
注意：Cache API 存储是按键值组织的，IndexedDB 更适合存储大量二进制或带元数据的图片。
3. CDN 与边缘缓存
把图片推到 CDN，可以把资源放在更靠近用户的节点，减少跨洋或跨省的 RTT。CDN 通常支持：
- 基于路径或扩展名的缓存规则
- 缓存清理（purge）、前缀失效或基于版本的自动失效策略
- 图片处理加速（按需转码、压缩、WebP/AVIF 输出）
实操建议：把 CDN 的缓存时间和源站的 Cache-Control 配合起来，并利用文件指纹（例如带 hash 的文件名）做长缓存策略。
4. 源站与代理缓存
服务端可以通过反向代理（如 Nginx、Varnish）做二次缓存，减轻应用服务器压力。这里易犯的错误是忽略缓存失效逻辑，导致旧图片长时间存在或频繁主动清理造成性能抖动。
图片优化与缓存的配合要点
缓存并不是万能，合理的图片处理能让缓存发挥最大效果：
- 选择合适格式：WebP/AVIF 对照片类图片通常比 JPEG 更小，PNG 用于图形与透明背景。
- 按需分辨率：为不同终端提供不同分辨率（srcset、picture），避免传输过大的图片。
- 压缩与质量平衡：无损或有损压缩，结合视觉测试找到合适的质量值。
- 渐进/占位加载：用低质量占位图(LQIP)或 SVG 占位提升感知速度。
HTTP 缓存头常见配置参考
| 场景 | Cache-Control | 说明 |
| 长期不变资源（带指纹） | public, max-age=31536000, immutable | 可缓存一年，immutable 表示不需要 revalidate |
| 频繁更新的图片 | no-cache | 每次请求都带条件校验，服务器可返回 304 |
| 用户生成内容（头像等） | public, max-age=3600 | 短缓存+条件请求折中策略 |
版本控制与缓存失效（缓存穿透与缓存雪崩略讲）
版本控制（fingerprint）是最可靠的强缓存失效手段：当资源内容改变时，文件名（或路径）带上新的 hash，浏览器与 CDN 会把它当成新资源拉取。避免直接依赖“主动清理 CDN”来刷新所有用户的缓存，因为清理可能带来瞬时高峰（缓存雪崩）。
移动端与原生应用的图片缓存
原生应用通常有两层缓存：内存缓存用于快速显示（生命周期短），磁盘缓存用于长期持久。常用库与建议：
- Android：Glide、Coil、Fresco，都提供内存/磁盘缓存策略与占位图支持。
- iOS：SDWebImage 等，支持缓存策略、自动解码与磁盘存储。
- 移动端注意点：在低内存情况下需要主动清理内存缓存，磁盘缓存要限制总大小并按 LRU 策略淘汰。
具体场景与推荐策略
电商商品列表（大量缩略图）
- 缩略图使用低分辨率 WebP，CDN 做边缘缓存，Cache-Control 可设长缓存并使用文件指纹。
- 配合 lazy-loading 和占位图，确保首屏快速呈现。
用户头像（可能会频繁更新）
- 短缓存（例如 1 小时）+ 条件请求（ETag/Last-Modified），或采用头像 URL 带版本号策略。
- 在 Service Worker 中用 Network First 策略以保证更新及时性，失败时回退缓存。
无障碍场景或离线优先应用
- 尽可能把关键图片加入 pre-cache，采用 Stale-While-Revalidate 策略保持体验与新鲜度。
- 在低带宽环境下结合占位图和渐进增强展示。
调试与验证缓存的常用方法
- 浏览器开发者工具的 Network 面板，观察响应头、状态码（200/304）与缓存命中。
- 使用 curl -I 查看服务器响应头，验证 Cache-Control、ETag、Expires 是否正确。
- CDN 控制台查看边缘命中率与缓存命中率指标，调整规则。
常见误区与陷阱
- 误区：只靠浏览器缓存就能解决一切。实际上需要 CDN + 源站配合。
- 误区：长缓存就万无一失。若没有版本控制，更新将难以传播。
- 陷阱：频繁全量清理 CDN 会造成瞬时访问压力，设计失效策略时要考虑平滑过渡。
实战清单：部署图片缓存前要做的 12 项检查
- 为静态图片设置合理的 Cache-Control 并使用文件指纹。
- 为可能变更的图片准备短缓存 + ETag 或带版本号的 URL。
- 在 CDN 上配置好缓存规则与清理策略。
- 针对移动端准备不同分辨率的图片（响应式图片）。
- 考虑图片格式转换到 WebP/AVIF 并保留回退方案。
- 在前端使用 lazy-loading、占位图与渐进加载。
- 为离线场景实现 Service Worker 缓存策略。
- 限制磁盘缓存大小并采用 LRU 淘汰策略。
- 在服务端做好压缩与缓存头配置。
- 监控 CDN 命中率和边缘延迟。
- 提供回滚/清理计划以应对错误的缓存配置。
- 记录并测试缓存失效后的用户体验路径。
参考资料（可进一步阅读）
- HTTP 缓存入门与最佳实践
- Service Worker 和 Cache API 官方文档
- 各大 CDN 的缓存规则与图片处理文档（如常见厂商控制台说明）
- 移动端图片加载库文档：Glide / Coil / SDWebImage
写到这里，想到一个小提醒：不要把缓存当成万能保险箱，缓存是改善体验的工具，但也需要配合版本管理、监控与回滚计划才能稳妥运作。平时多观察命中率与错误率，遇到问题一步步排查响应头、CDN 配置与前端策略，往往就能把问题定位清楚。