网站做久了，图片存储迟早会变成一个绕不开的问题。文章封面、教程截图、相册和页面装饰图越来越多以后，直接放在网站服务器、使用对象存储（OSS）、接入专用图床，或再搭配 CDN，看起来都能解决问题，但每种方案都有自己的成本和维护负担。
先说结论：我目前还没有找到一个在价格、速度、管理、稳定性和迁移成本之间都足够理想的方案。下面不是“标准答案”，而是我在折腾不同存储方式时形成的一份阶段性体验。
我真正关心的，不只是“能不能存”
图片能上传只是第一步。对于一个长期维护的网站，我更在意下面这些问题：
- 访问速度：不同地区打开图片是否稳定，首屏会不会被大图拖慢。
- 成本是否可预估：除了存储空间，还要考虑请求次数、外网流量、CDN 回源和图片处理费用。
- 上传与管理体验：能否在 WordPress 中直接选择、替换、生成缩略图，而不是频繁切换后台。
- 图片处理能力：是否支持 WebP、AVIF、按尺寸裁切、质量压缩和自动格式转换。
- 迁移难度：服务不可用或准备更换供应商时，原图和文章链接能否顺利迁出。
- 备份与可控性：有没有独立原图备份，是否过度依赖某个平台。
方案一：对象存储（OSS）
这里的 OSS 泛指云厂商提供的对象存储，而不是某一家具体产品。它通常按存储量、请求次数和流量计费，再配合自定义域名、CDN、HTTPS 与图片处理服务使用。
使用感受
OSS 最大的优点是“像基础设施”。文件结构、访问权限、生命周期、跨域规则和缓存策略都能自己控制，容量也容易扩展。对于访问量逐渐增加的网站，它比把所有图片塞进同一台 Web 服务器更稳妥。
但它并不是开通后就能直接获得理想体验。实际使用中还要处理 Bucket 权限、自定义域名、证书、CORS、防盗链、CDN 回源、缓存刷新等配置。账单也不只有存储费：小文件请求、外网流量、图片处理和 CDN 都可能成为额外支出。
- 优点：扩展性好、权限和生命周期可控、适合与 CDN 组合、迁移工具相对成熟。
- 不足：初始配置较多，费用项目分散，需要自己做好安全、缓存和备份策略。
- 适合：图片数量较大、访问量稳定增长，并且愿意维护基础设施的网站。
方案二：专用图床
图床更像一项面向内容创作者的成品服务。上传后直接得到链接，有些还提供客户端、浏览器扩展、自动压缩、多尺寸图片和全球分发。单纯从“把截图放进文章”这件事看，图床的体验通常最轻松。
它的问题主要出现在长期使用以后：免费额度可能变化，原图导出能力不一定完善，域名和链接格式由平台决定，批量迁移时也可能需要重新替换文章中的 URL。部分服务还会进行内容审核或限制外链用途，因此不适合把“省事”直接等同于“可长期依赖”。
- 优点：上手快、上传方便、通常自带分发与压缩，对个人博客友好。
- 不足：平台依赖较强，规则和额度可能变化，批量迁移与原图管理需要提前确认。
- 适合：图片规模不大、希望减少配置工作、能够接受平台规则的个人站点。
方案三：网站本地、自建存储与其他方案
直接使用 WordPress 媒体库
图片和文章放在一起，编辑体验最自然：上传、选择、替换、特色图和缩略图都在同一个后台完成。缺点是媒体越来越多后，会占用服务器磁盘、备份空间和迁移时间；如果源站带宽有限，图片访问也会与页面请求争抢资源。
自建对象存储、NAS 或兼容 S3 的服务
这类方案的吸引力在于控制权：数据、目录和备份都掌握在自己手里，也可以针对需要配置同步和归档。但控制权的另一面就是维护责任，包括公网访问、安全更新、磁盘健康、异地备份、证书和可用性。它更适合已经有设备和运维习惯的人，而不是为了省一点存储费临时搭建。
仓库、静态资源服务与混合存储
少量文档图片可以跟随静态站点或代码仓库部署，版本关系清楚，但大量二进制文件会让仓库膨胀。实际更可行的往往是混合方案：站点保留编辑入口，公开图片通过独立域名分发，原图另做备份。
几种方案放在一起对比
| 对比维度 | 对象存储 OSS | 专用图床 | 网站本地 / 自建 |
|---|---|---|---|
| 上手难度 | 中等，需要配置域名、权限和缓存 | 低，通常上传即可使用 | 本地较低，自建较高 |
| 访问性能 | 配合 CDN 后较好 | 取决于平台线路与节点 | 取决于源站带宽和部署位置 |
| 费用结构 | 存储、请求、流量、处理分别计费 | 套餐或额度更直观，但规则可能变化 | 服务器、磁盘、带宽和维护成本 |
| 管理体验 | 控制力强，日常操作偏技术化 | 通常最好，适合快速发文 | 与站点整合自然，自建维护较重 |
| 迁移自由度 | 较好，但要规划域名和链接 | 差异较大，依赖导出能力 | 数据最可控，但迁移工作自己承担 |
| 长期风险 | 账单与配置复杂度 | 平台策略、额度和服务持续性 | 硬件、带宽、安全与备份责任 |
比选择供应商更重要的六个习惯
- 上传前先压缩。普通文章图片优先使用 WebP；在观感允许的前提下，把单张图片控制在 500KB 以内。
- 保留合理尺寸。不要把相机原图直接用于网页。封面和正文图片按实际展示宽度输出即可。
- 使用自己的图片域名。以后更换底层存储时，可以通过 DNS、反向代理或批量映射降低文章改动量。
- 原图独立备份。线上可访问文件不是备份，至少保留一份不依赖当前服务商的副本。
- 记录替换关系。批量迁移前导出媒体清单，保留旧 URL、新 URL、附件 ID 和文章引用关系。
- 检查失败场景。关注链接失效、防盗链误拦截、缓存未刷新、跨域失败以及超额后的处理方式。
我现在的阶段性结论
如果只看性能和扩展性，我更倾向于对象存储加 CDN；如果只看写作体验，专用图床明显更轻松；如果最看重控制权，本地媒体库或自建方案又更踏实。但把费用、管理、备份、迁移和日常发布放在一起，但是我暂时还没有找到一个完全适合自己的选择。
目前更现实的做法，是先建立不依赖某个平台的图片规范：统一尺寸、优先 WebP、控制体积、使用独立域名、保留原图备份。等图片数量和访问规模更明确后，再决定长期落在哪种存储上。这样即使以后更换方案，也不会从零开始。
存储方案没有绝对最好，真正重要的是：当价格变化、服务中断或需要迁移时，图片仍然在自己手里，文章也还能正常打开。
