搭建博客自然少不了图床，我选择的方案是 CloudFlare-ImgBed。至于存储后端，起初我利用 Telegram Channel Bot “白嫖”，但了解到此举违反 TOS 且有封号风险，于是转而使用对象存储。
相比于直接上 Cloudflare R2，当时我选择了第三方的 Tebi.io，因为它提供更高的免费额度，且无需绑卡，没有被“反薅”的风险。本以为能安枕无忧，近期却收到通知：Tebi.io 的 OSS 服务将于 2026 年 3 月底关停。我的图床不仅承载了个人博客，还包括朋友的 ylqian.com 以及部分论坛交流图片。因此，我必须进行一次“无感迁移”，目标锁定为稳定可靠的 Cloudflare R2。
文件迁移
文件内容的迁移非常简单，直接使用 rclone sync 即可，相信大多数 LLM 都能给出标准的操作流程。
后端迁移与 Metadata 重建
真正的挑战在于图床后端的迁移。OSS 数据同步后，图床自带的“索引重建”功能并未成功索引到所有图片（这可能与下文提到的 Cloudflare KV 写入限制有关），且单纯的重建无法恢复源自 Telegram 的图片索引。
幸运的是，该图床服务支持配置的备份与恢复，备份文件中包含每张图片的 Metadata（含源存储地址）。我写了一个简单的脚本 migrate_tebi_2_r2.py 批量替换备份文件中的存储地址。
原本以为导入修改后的备份即可，结果恢复过程在 30 秒后提示超时失败。原因在于我的图片存量超过 700 张，而作为 Metadata 存储后端的 Cloudflare KV 并不擅长高频写入（更适合超高频读、低频写）。即便我让 LLM 优化了脚本以支持并发写入，依然报错：KV put() limit exceeded for the day.。KV 的免费日写入限额仅 1000 次，在反复调试恢复配置时已被耗尽。
切换至 Cloudflare D1
好在图床后端还支持 D1 存储。相比 KV，D1 更接近传统关系型数据库，写入限制宽松许多。虽然读取性能理论上略低于 KV，但对于个人图床这类场景完全够用。切换到 D1 后，恢复工作迎刃而解。
总结
目前图床已成功迁移至 R2。除非未来 Cloudflare Workers 或 R2 发生重大变动，短期内无需再折腾。这次迁移给我最大的教训是：基础设施尽量在一开始就选择稳定可靠的服务商。 一旦遭遇跑路，迁移的时间成本和潜在的数据丢失风险，远大于当初省下的那笔小钱。