三年前我把所有文章图片迁到了第三方图床。上个月，我又把它们搬了回来。
这篇是一次复盘，讲清楚我为什么走了一圈又回来。
当初为什么迁出
原因很实际：
- 服务器磁盘小，图片越堆越多。
- 图床自带 CDN，访问速度有提升。
- 不用自己处理压缩和格式转换。
- 免费额度够我用。
这四条在今天仍然成立。所以问题不在「图床不好」，而在别处。
真正的问题：失去控制
用了三年，我遇到过两次图片加载失败。都不是我的问题，是服务端的：一次是节点调整，一次是防盗链规则变了。
我还发现，我的图片在别人的服务器上，URL 是别人的格式，删除按钮在别人的后台里。这种感觉很微妙，像把自己的日记存在别人家。
断链是迟早的事
这不是图床的错，是所有第三方服务的必然：
- 服务可能停止、被收购、改变策略。
- 免费额度可能收紧。
- 你的文章是长期的，它的承诺是年度的。
一篇写于 2024 年的文章，在 2034 年还应该能正常显示。这个要求，第三方服务很难替我保证。
搬回来的方案
我做了三件事：
- 本地化。所有图片下载回服务器，按文章日期建目录。
- 压缩流水线。用 sharp 批量处理：生成 webp 与多分辨率版本，HTML 里用
picture+srcset。 - 对象存储做备份。图片原件存一份在冷归档，成本可以忽略。
# 迁移后的目录结构
img/
├── 2026/
│ ├── 09-gugong/
│ └── 08-cli/
└── 2025/代价
磁盘确实吃紧了。我的办法是：只保留 webp 版本在线，原图进冷存储。服务器上每张图平均不到 80KB，全站图片总体积比图床时代还小。
速度上几乎没差别——因为做了长缓存加 CDN。而「速度」这件事，缓存比图床更管用。
结论
图床的便利是真的，断链的风险也是真的。如果你写的内容是临时的、短期的，图床完全够用；如果你的文章是要放很多年的，把图片放在自己能控制的地方，会让你睡得更踏实。
我是后者。所以搬回来了。