这是 Beta 探索课程，内容结构、实验步骤和示例可能会继续调整。
成本优化
一张账单
我记得第一次看到图片系统的月度账单时的震惊：存储费用比预期高了 3 倍，CDN 带宽费用占了总成本的 60%，而且还在以每月 20% 的速度增长。
图片系统的成本会随着业务增长持续放大：原图占存储，派生图占存储和处理资源，CDN 消耗带宽，审核和压缩消耗计算，历史图片还会长期占用冷数据空间。如果没有成本模型，系统在功能上可用，但运营上不可持续。
成本拆解
把成本拆成五类，才能针对性治理：
| 成本类型 | 构成 | 占比参考 | 治理手段 |
|---|---|---|---|
| 存储 | 原图、派生图、备份 | 30% | 冷热分层、派生图清理、压缩 |
| 带宽 | CDN 回源、边缘分发 | 40% | 提高命中率、WebP/AVIF、边缘缓存 |
| 计算 | 压缩、审核、处理 | 15% | 异步处理、GPU 加速、批量处理 |
| 审核 | 机审调用、人审工时 | 10% | 预览图审核、规则过滤、模型优化 |
| 运维 | 监控、告警、人力 | 5% | 自动化、告警降噪 |
冷热分层
不是所有图片都需要低延迟访问。根据访问热度分层存储：
热图片（近 7 天有访问）→ 标准存储 + 长边缘缓存
温图片（近 30 天有访问）→ 标准存储 + 短边缘缓存
冷图片（超过 30 天无访问）→ 低频存储 + 仅保留原图
归档图片（超过 180 天无访问）→ 归档存储 + 仅保留原图
过期图片（业务已删除）→ 删除或合规保留生命周期规则必须和业务语义绑定，不能只按文件年龄粗暴删除。比如用户头像即使长期不访问也不能删，营销活动图片在活动结束后可以归档。
def lifecycle_policy(image):
days_since_last_access = (now - image.last_accessed_at).days
days_since_upload = (now - image.created_at).days
if image.business_type == 'avatar':
return 'keep_standard' # 头像永久保留
if image.business_type == 'marketing' and image.campaign_ended:
return 'archive' # 营销活动结束后归档
if days_since_last_access > 180:
return 'archive'
elif days_since_last_access > 30:
return 'cold'
elif days_since_last_access > 7:
return 'warm'
else:
return 'hot'派生图治理
派生图是存储成本的大头。一张原图可能生成 10 种尺寸 × 3 种格式 = 30 张派生图，但其中很多从未被访问。
治理策略：
- 访问驱动生成：只生成实际被访问的尺寸和格式，不预生成所有组合
- 定期清理：扫描超过 90 天无访问的派生图，删除（需要时可重新生成）
- 限制参数空间：通过白名单限制允许的尺寸和格式，防止恶意请求制造无限变体
- 热门尺寸预生成：对访问量 Top 100 的尺寸，上传后异步生成并预热
成本可观测
成本优化不能只依靠人工巡检。元数据表需要记录：
图片成本元数据 = {
图片ID, 业务归属, 图片类型,
原图体积, 派生图数量, 派生图总体积,
存储级别, 访问次数, 最后访问时间,
本月带宽消耗, 本月处理次数,
预计月度费用, 成本趋势
}定时任务根据这些指标做迁移、清理和告警；报表按业务线、图片类型和访问场景展示成本变化。这样产品、研发和运营才能讨论同一个事实，而不是只在账单暴涨后临时处理。
带宽优化
CDN 带宽通常是最大的成本项，优化手段：
- 提高命中率：稳定缓存键、长缓存时间、热门图片预热，目标命中率 > 95%
- 格式优化：WebP 比 JPEG 小 25-35%，AVIF 再小 20%，全站启用可省 30% 带宽
- 按需加载：列表页用缩略图，详情页才加载原图，懒加载非首屏图片
- 响应式图片：根据设备屏幕尺寸返回合适大小的图片，避免在手机上加载 4K 图
- 带宽封顶：和 CDN 厂商谈判带宽封顶价格，大流量场景下成本可控
验收标准
完成本章后，你会形成一套可执行的成本治理方案：
- 哪些图片要保留：根据业务语义和访问热度决定
- 哪些派生图可以删除：长期无访问的派生图定期清理
- 哪些对象应该转冷：超过阈值无访问的图片转低频/归档存储
- 哪些请求导致带宽异常：通过成本报表定位异常流量
- 如何在不明显损害用户体验的前提下降低长期成本：冷热分层、格式优化、按需生成
读到这里时，你需要把成本优化看成架构能力，而不是财务报表后的补救动作。一个成熟系统应该在图片创建时就带上归属和生命周期，在访问时持续更新热度，在处理时控制派生数量，在下线时自动回收资源。