把摄影图片放上网站之前：为什么需要一条 R2 图片流水线

昨天给摄影集补了一条脚本流水线：本地原图进 photos/raw，脚本处理出 WebP 版本，再上传到 Cloudflare R2，最后生成 content/gallery/*.yaml 给页面读取。

这个需求看起来像"上传图片"，实际拆开后有三件事。

需求一：原图不能直接上网页

相机或手机原图通常很大，一张照片可能几 MB 到几十 MB。直接让网页加载原图，会把首屏、流量和移动端体验一起拖慢。

所以我没有把原图提交到仓库，也没有让页面引用原图。仓库只保留结构化内容数据，真实图片交给 R2。

需求二：同一张图要服务不同场景

摄影页至少有三种访问场景：

• 网格列表需要小图，优先快。
• 弹窗预览需要中等清晰度，优先均衡。
• 查看原图需要更大尺寸，优先细节。

这就是脚本里三档输出的来源：thumb.webp、display.webp、full.webp。它们不是随便压三遍，而是把用户实际路径拆开：先看列表，再点开，再决定是否看大图。

需求三：内容层要可重复生成

图片上传后，页面还需要标题、宽高、拍摄时间、相机参数、URL、模糊占位图等信息。手填这些字段又慢又容易错。

因此处理脚本会写一份 manifest，再由生成脚本转成 YAML。页面只读取 YAML，不关心本地文件在哪里，也不需要知道 R2 的上传细节。

小结

这条流水线的核心不是"省一次手动上传"，而是把摄影图从一堆零散文件变成稳定资产：有尺寸、有地址、有元数据，也能被 Next.js 的内容系统可靠消费。