免费图床说跑就跑：一个独立博主的图片存储"流浪史"

上周我翻到自己三年前写的一篇文章，图片全部变成了红叉叉。当年用的那个图床，早就没了。

这种事，大概每个独立博主都遇到过。

免费图床的”三年之痒”

独立博主用免费图床，本质上是一种权宜之计：省钱、快速、门槛低。但免费服务的宿命往往是这样的——用的人多了，服务商开始限流；开始收费了，部分用户流失；继续运营不下去了，直接关站。

前两年，Gitee图床突然加了防盗链机制，检测Referrer头，不是自家域名的一律屏蔽。当时很多博主发现自己的文章图片集体失效，措手不及。更早之前，用jsDelivr加速GitHub图床的人也知道，这个CDN时不时就会抽风——尤其是在国内访问，稳定性一言难尽。

而2026年了，依然有博主在问”我的图床跑路了，文章图片全挂了怎么办”。

真实案例：一个博主从GitHub Pages到Cloudflare全家桶的迁移

最近看到一位独立博主的分享，挺有代表性。他原本用GitHub Pages搭博客，用Cloudflare CDN加速，访问速度还可以。但图片始终是个问题——直接用GitHub原生访问太慢，jsDelivr加速又不够稳定。

他后来做了一件挺彻底的事：换用Cloudflare R2对象存储做图床，配合GitHub Actions实现图片自动上传。

具体逻辑是：写文章时把图片丢进一个专用分支，GitHub Actions自动检测到改动后，筛选出大于128KB的图片，压缩后上传到R2存储桶，生成CDN加速的访问链接，再把文章里的旧链接替换掉。

整个流程自动化程度很高，上传一次就完事了。最重要的是：R2存储在Cloudflare的免费额度内，对个人博客来说基本不会超限。

为什么要用”全家桶”思路

这里有个有意思的逻辑：为什么不用更简单的方案？

七牛云之类的对象存储确实靠谱，但国内的服务绑定HTTPS还要额外计费，对于只是放几张博客图片的个人站点来说，性价比不够高。而Cloudflare自己的产品线（R2存储+CDN+Workers代理）打包使用，在免费额度内就能覆盖绝大多数场景，而且全部是同一套基础设施，配置起来互相打通，不存在”接口不稳定”的问题。

当然，Cloudflare全家桶也有门槛：你得折腾Workers脚本，得理解CDN的基本原理，对纯新手来说不算友好。但对于愿意投入时间研究的博主而言，这套方案的性价比确实很高。

我的判断：图床问题本质上是个”风险分散”问题

聊了这么多案例，我的核心观点其实很简单：不要把所有图片放在一个篮子里。

具体来说，有几个可以参考的策略：

第一，优先使用”基础设施级别”的存储。 GitHub本身的存储是永久的——只要你仓库不删，图片就不会丢。用Git LFS管理大图，配合CI自动处理，是一个相对稳妥的方案。

第二，如果要上CDN加速，优先选Cloudflare。 不是因为它最好，而是因为它的免费策略对个人博客最友好，而且生态足够大，不容易突然倒闭。

第三，也是最重要的：定期检查图片可用性。 很多博主等到文章图片全挂才发现自己图床没了，但凡在博客后台加一个定期检查的工具，都不至于如此被动。

第四，考虑把关键图片内嵌到文章里。 Markdown支持Base64内嵌图片，缺点是文章体积变大、不好管理，但对于真正重要的配图，这不失为一个保底方案——只要文章还能打开，图片就不会丢。

结语

独立博主折腾图床这件事，本质上是一个持续存在的”技术债务”：你永远不知道你用的那个服务什么时候会变，什么时候会停。与其被动等待，不如主动把图片存储这件事做得更扎实一点。

毕竟，文字是你的，图床是你的选择，而这个选择的后果，最终也只有你自己来承担。

——写完这篇文章，我去检查了一下自己的图床链接。还好，都还在。