边缘处理

预生成 vs 边缘处理：一个两难选择

到这一步，“光影”的图片系统有两条路可以走：

路线 A：预生成所有变体

用户上传后，Worker 生成 3 种尺寸 × 2 种格式 = 6 个文件，全部存到 OSS，CDN 只做缓存和分发。

优点：所有文件提前准备好，首次访问也快
缺点：存储成本高、上传处理慢、不够灵活

路线 B：边缘按需处理

只存一张原图，用户请求时由 CDN 边缘节点实时裁剪和格式转换。

优点：存储成本低、灵活、上传快
缺点：首次处理有延迟、边缘节点计算资源有限

我决定做一个对比实验。

对比实验设计

结果：

=== 存储成本对比 ===
路线 A（预生成）: 706 GB, 85 元/月
路线 B（边缘处理）: 488 GB, 59 元/月
节省: 31%

=== 首次访问延迟对比 ===
路线 A: 80ms
路线 B: 280ms
差异: +200ms

=== 综合月度成本对比 ===
路线 A（预生成）: 96 元/月
路线 B（边缘处理）: 72 元/月
  - 存储: 59 元
  - CDN: 11 元
  - 回源: 0.01 元
  - 边缘处理: 0.25 元

边缘处理方案每月省 24 元，而且省了上传处理时间。

边缘处理的实现

方案一：Cloudflare Workers

Cloudflare 的边缘计算平台可以在全球 300+ 个节点上运行 JavaScript 代码：

方案二：阿里云 EdgeRoutine + OSS 图片处理

混合策略：最佳实践

实际上，最优方案是混合策略——热门尺寸预生成 + 长尾需求边缘处理：

边缘处理的局限

边缘处理不是万能的。有些操作不适合在边缘节点做：

边缘处理适合的：
✅ 缩放（resize）       — 计算量小，速度快
✅ 格式转换（WebP/JPEG）— 常见操作
✅ 质量调整             — 简单参数
✅ 裁剪（crop）          — 计算量小

边缘处理不适合的：
❌ 智能压缩（需要 AI 分析）— 计算量大，延迟高
❌ 人脸检测/模糊         — 需要重型模型
❌ 批量处理              — 边缘节点资源有限
❌ 内容审核              — 需要 AI 模型，不适合边缘
❌ 水印添加              — 可以做，但效果不如服务端

这些操作仍然需要在服务端（Worker）预完成。