告别图床刺客：基于 CloudFlare-ImgBed 与 R2 构建高可用边缘图床及自动化管线

一、 序言：写博客最怕的不是没灵感，而是数年后满屏的裂图

维护独立博客超过一年的人，几乎都经历过被“图床”背刺的时刻。

最早写软路由折腾笔记时，为了图省事，我曾把截图随手拖进过几个号称“永久免费”的公共图床。结果不到半年，其中一家因为域名未续费直接蒸发，另一家则突然加上了严苛的跨域拦截—⁠—某天深夜我点开自己半年前写的教程，发现原本夹在文字中间的十几张关键配置截图全变成了灰色的碎裂图标。一篇没有配图的硬件实操手记，读起来就像一份被撕掉图纸的说明书。

后来我也试过两个常见的替代方案，但各自都有绕不开的硬伤：

• 把原图直接塞进 Git 静态仓库：写文章时确实顺手，但手机拍的照片或高分屏截出来的 PNG 动辄三四兆。十几篇文章写下来，.git 目录膨胀到好几百兆，每次 git push 或 CI 构建都要拉取半天，国内访客打开页面更是像在挤牙膏。

• 使用国内传统云厂商的 OSS / COS 对象存储：速度确实快，但它的计费模型里藏着一把悬在头顶的剑—⁠—按量计费的公网出站流量费与 CDN 回源费。个人博客根本招架不住恶意爬虫或盗链脚本的半夜刷量，一觉醒来欠费几百块的案例在社区里比比皆是；而如果为了自保开启极严的空 Referer 拦截，又会导致所有通过 RSS 阅读器看文章的读者看到满屏裂图。

为了彻底终结这种焦虑，在重构本站（HalfAirの博客）时，我基于开源项目 MarSeventh/CloudFlare-ImgBed 配合 Cloudflare R2 对象存储，搭起了本站专属的边缘图床网关（https://img.halfair.top），并在本地写了一套自动压缩、哈希去重与链接回写脚本。现在你在这座博客里看到的每一张文章配图、外设线框图乃至角落里的微贴纸，全部跑在这套零月租的边缘架构上。

二、 架构拆解与模式选型：Pages 还是 Worker？Telegram 还是 R2？

在动手配置之前，有必要先把 CloudFlare-ImgBed 进化到 v2.x 之后的双层架构理清楚。它把“元数据索引”与“二进制文件实体”做了干净的剥离：所有的文件列表、目录树（如 blog/、gear/）、访问黑白名单都存在 Cloudflare KV（img_url） 中；而真正的图片字节流，则支持路由到多种后端存储渠道（uploadChannel）。

在计算载体上，官方提供了 Pages 部署与 Worker 部署两种模式：

1. Cloudflare Pages 模式：需要 Fork 源码仓库并连接 Pages 自动构建。优点是方便自己二次修改前端界面，缺点是每次更新版本都要跑一遍完整的前端编译流程。

2. Cloudflare Worker 模式（推荐生产使用）：直接下载官方编译好的单文件 worker.js 部署在 Workers 上（详见官方 Worker 部署文档）。它省去了冗长的构建步骤，冷启动极快，绑定 KV 和 R2 也更加直观。

而在后端存储渠道的选择上，强烈建议参考下表根据自己的场景做取舍：

三、 生产级部署全流程：从 R2 桶绑定到边缘缓存加固

下面以我部署 https://img.halfair.top 所采用的 Worker + R2 主存储 + KV 索引 方案为例，完整梳理一遍从零落地的四个标准步骤。

第一步：创建 KV 索引库与 R2 存储桶

登录 Cloudflare 控制台，先准备好两个底层存储容器：

1. 进入 存储和数据库 -> KV，点击创建命名空间，名称填写 img_url（用于存放全站图片索引、文件夹结构与后台设置）。

2. 进入 R2 对象存储 -> 概述，点击创建存储桶（Bucket），名称填写 halfair-imgbed（位置选择自动即可）。

第二步：创建 Worker 并挂载硬件绑定

进入 计算 (Workers & Pages) -> 创建 Worker，取名 cloudflare-imgbed。前往 MarSeventh/CloudFlare-ImgBed Releases 下载最新版的 worker.js，将代码粘贴进 Worker 在线编辑器（或使用 Wrangler CLI 推送）并保存。

随后进入该 Worker 的 设置 (Settings) -> 绑定 (Bindings)，挂载刚刚创建的两个容器（注意：变量名必须严格与下列名称一致，否则程序无法识别）：

• 添加 KV 命名空间绑定：变量名称填 img_url，选择刚才创建的 img_url 命名空间。

• 添加 R2 存储桶绑定：变量名称填 img_r2，选择刚才创建的 halfair-imgbed 存储桶。

第三步：配置后台鉴权与多渠道参数

在 Worker 的 设置 -> 变量和机密 (Variables and Secrets) 中，或是部署后首次访问后台的图形化设置页（/admin）里，配置核心安全锁：

第四步：绑定自定义域名与配置边缘强缓存（性能关键）

在 Worker 的「触发器 / 自定义域」里添加你自己的二级域名（例如 img.halfair.top）。域名生效后，强烈建议去 Cloudflare 域名控制台的 Caching (缓存) -> Cache Rules (缓存规则) 新增一条专门针对图床静态路径的强缓存规则：

• 匹配条件：主机名 等于 img.halfair.top 且 URI 路径 开头为 /file/

• 缓存操作：选择 符合缓存条件 (Eligible for cache)，将 边缘 TTL (Edge TTL) 设为 1 个月，浏览器 TTL (Browser TTL) 设为 1 年。

为什么这一步如此重要？因为默认情况下，Worker 动态返回的流可能不会在边缘节点长久驻留。加上这条缓存规则后，任何一张图片只要被第一个读者加载过一次，就会直接缓存在离读者最近的 Cloudflare 边缘机房里—⁠—后续成千上万次访问不仅能做到 15ms 内秒开，而且完全不再消耗你的 Worker 每日请求配额和 R2 读取次数！

四、 终极生产力闭环：API 鉴权上传与博客自动化去重管线

图床搭好之后，如果每次写文章还要手动打开网页后台、把截图拖进去、复制链接再切回编辑器粘贴，写一篇二十张图的文章还是太折腾了。

好在 CloudFlare-ImgBed 提供了极其规整的 /upload RESTful 接口。为了把写文章的摩擦降到零，我在本博客的工程仓库里直接内置了一套自动化资产治理脚本（scripts/upload-images.js）。平时我在本地写 Markdown 时，只需要把相机照片或截图丢进本地目录，跑一行 npm run images:upload，脚本就会在几秒钟内自动完成四件事：

1. 智能转码与尺寸收敛：调用 sharp 高性能图像引擎，将宽度超过 1440px 的超清原图等比缩放，并以 quality: 82 编码为现代 WebP 格式—⁠—实测一张 4.2 MB 的相机实拍图，转码后仅剩 95 KB 左右，体积削减超过 97%，肉眼几乎看不出画质损失。

2. SHA-256 + MD5 双重指纹去重：上传前先计算二进制内容的 SHA-256 与 MD5 哈希值，比对仓库根目录的 asset-manifest.json 账本。如果发现这张图以前已经传过了，直接秒级复用已有的 https://img.halfair.top/file/blog/... 链接，100% 杜绝重复上传产生垃圾文件。

3. 自动调用 /upload 接口上云：对真正新增的图片，携带 .env 中的 IMGBED_TOKEN 发送 FormData 请求至 cfr2 渠道，自动归档到云端的 blog/ 文件夹下。

4. 源码无感原地回写：拿到图床返回的永久 CDN 链接后，自动扫描并替换 .md 文稿中的本地路径，全程无需手动复制粘贴一次 URL。

五、 结语：把数字资产的主权握在自己手里

折腾独立博客这么久，我越来越相信一个朴素的道理：凡是打算留存五年、十年以上的内容，它的底层寻址权就绝不能寄托在别人的免费施舍上。

借助 MarSeventh/CloudFlare-ImgBed 与 Cloudflare R2，我们不需要编写复杂的后端鉴权代码，也不需要为每月的服务器带宽掏一分钱，就能拥有一座完全受自己域名（img.halfair.top）统辖的现代图床。即便未来某天你想迁移到别的存储平台，因为域名解析权牢牢攥在你自己手里，只需把 R2 桶里的文件同步过去、改一下路由指向，全站成百上千篇文章里的图片链接依然一个字都不用改。

这大概就是自建边缘基建最让人踏实的地方。