### [网站图片到底放哪里？OSS、图床与其他存储方案的使用体验与对比](https://blog.cikcc.com/article/651)

**Published:** 2026-10-14T01:36:36

**Author:** Cik

**Excerpt:** 从网站维护者的角度，对比对象存储（OSS）、专用图床、WordPress 本地媒体库与自建存储的速度、成本、管…

网站做久了，图片存储迟早会变成一个绕不开的问题。文章封面、教程截图、相册和页面装饰图越来越多以后，直接放在网站服务器、使用对象存储（OSS）、接入专用图床，或再搭配 CDN，看起来都能解决问题，但每种方案都有自己的成本和维护负担。

> **先说结论：**我目前还没有找到一个在价格、速度、管理、稳定性和迁移成本之间都足够理想的方案。下面不是“标准答案”，而是我在折腾不同存储方式时形成的一份阶段性体验。

## 我真正关心的，不只是“能不能存”

图片能上传只是第一步。对于一个长期维护的网站，我更在意下面这些问题：

-   **访问速度：**不同地区打开图片是否稳定，首屏会不会被大图拖慢。
-   **成本是否可预估：**除了存储空间，还要考虑请求次数、外网流量、CDN 回源和图片处理费用。
-   **上传与管理体验：**能否在 WordPress 中直接选择、替换、生成缩略图，而不是频繁切换后台。
-   **图片处理能力：**是否支持 WebP、AVIF、按尺寸裁切、质量压缩和自动格式转换。
-   **迁移难度：**服务不可用或准备更换供应商时，原图和文章链接能否顺利迁出。
-   **备份与可控性：**有没有独立原图备份，是否过度依赖某个平台。

## 方案一：对象存储（OSS）

这里的 OSS 泛指云厂商提供的对象存储，而不是某一家具体产品。它通常按存储量、请求次数和流量计费，再配合自定义域名、CDN、HTTPS 与图片处理服务使用。

### 使用感受

OSS 最大的优点是“像基础设施”。文件结构、访问权限、生命周期、跨域规则和缓存策略都能自己控制，容量也容易扩展。对于访问量逐渐增加的网站，它比把所有图片塞进同一台 Web 服务器更稳妥。

但它并不是开通后就能直接获得理想体验。实际使用中还要处理 Bucket 权限、自定义域名、证书、CORS、防盗链、CDN 回源、缓存刷新等配置。账单也不只有存储费：小文件请求、外网流量、图片处理和 CDN 都可能成为额外支出。

-   **优点：**扩展性好、权限和生命周期可控、适合与 CDN 组合、迁移工具相对成熟。
-   **不足：**初始配置较多，费用项目分散，需要自己做好安全、缓存和备份策略。
-   **适合：**图片数量较大、访问量稳定增长，并且愿意维护基础设施的网站。

## 方案二：专用图床

图床更像一项面向内容创作者的成品服务。上传后直接得到链接，有些还提供客户端、浏览器扩展、自动压缩、多尺寸图片和全球分发。单纯从“把截图放进文章”这件事看，图床的体验通常最轻松。

它的问题主要出现在长期使用以后：免费额度可能变化，原图导出能力不一定完善，域名和链接格式由平台决定，批量迁移时也可能需要重新替换文章中的 URL。部分服务还会进行内容审核或限制外链用途，因此不适合把“省事”直接等同于“可长期依赖”。

-   **优点：**上手快、上传方便、通常自带分发与压缩，对个人博客友好。
-   **不足：**平台依赖较强，规则和额度可能变化，批量迁移与原图管理需要提前确认。
-   **适合：**图片规模不大、希望减少配置工作、能够接受平台规则的个人站点。

## 方案三：网站本地、自建存储与其他方案

### 直接使用 WordPress 媒体库

图片和文章放在一起，编辑体验最自然：上传、选择、替换、特色图和缩略图都在同一个后台完成。缺点是媒体越来越多后，会占用服务器磁盘、备份空间和迁移时间；如果源站带宽有限，图片访问也会与页面请求争抢资源。

### 自建对象存储、NAS 或兼容 S3 的服务

这类方案的吸引力在于控制权：数据、目录和备份都掌握在自己手里，也可以针对需要配置同步和归档。但控制权的另一面就是维护责任，包括公网访问、安全更新、磁盘健康、异地备份、证书和可用性。它更适合已经有设备和运维习惯的人，而不是为了省一点存储费临时搭建。

### 仓库、静态资源服务与混合存储

少量文档图片可以跟随静态站点或代码仓库部署，版本关系清楚，但大量二进制文件会让仓库膨胀。实际更可行的往往是混合方案：站点保留编辑入口，公开图片通过独立域名分发，原图另做备份。

## 几种方案放在一起对比

| 对比维度 | 对象存储 OSS | 专用图床 | 网站本地 / 自建 |
| --- | --- | --- | --- |
| 上手难度 | 中等，需要配置域名、权限和缓存 | 低，通常上传即可使用 | 本地较低，自建较高 |
| 访问性能 | 配合 CDN 后较好 | 取决于平台线路与节点 | 取决于源站带宽和部署位置 |
| 费用结构 | 存储、请求、流量、处理分别计费 | 套餐或额度更直观，但规则可能变化 | 服务器、磁盘、带宽和维护成本 |
| 管理体验 | 控制力强，日常操作偏技术化 | 通常最好，适合快速发文 | 与站点整合自然，自建维护较重 |
| 迁移自由度 | 较好，但要规划域名和链接 | 差异较大，依赖导出能力 | 数据最可控，但迁移工作自己承担 |
| 长期风险 | 账单与配置复杂度 | 平台策略、额度和服务持续性 | 硬件、带宽、安全与备份责任 |

## 比选择供应商更重要的六个习惯

1.  **上传前先压缩。**普通文章图片优先使用 WebP；在观感允许的前提下，把单张图片控制在 500KB 以内。
2.  **保留合理尺寸。**不要把相机原图直接用于网页。封面和正文图片按实际展示宽度输出即可。
3.  **使用自己的图片域名。**以后更换底层存储时，可以通过 DNS、反向代理或批量映射降低文章改动量。
4.  **原图独立备份。**线上可访问文件不是备份，至少保留一份不依赖当前服务商的副本。
5.  **记录替换关系。**批量迁移前导出媒体清单，保留旧 URL、新 URL、附件 ID 和文章引用关系。
6.  **检查失败场景。**关注链接失效、防盗链误拦截、缓存未刷新、跨域失败以及超额后的处理方式。

## 我现在的阶段性结论

如果只看性能和扩展性，我更倾向于对象存储加 CDN；如果只看写作体验，专用图床明显更轻松；如果最看重控制权，本地媒体库或自建方案又更踏实。但把费用、管理、备份、迁移和日常发布放在一起，`但是我暂时还没有找到一个完全适合自己的选择。`

目前更现实的做法，是先建立不依赖某个平台的图片规范：统一尺寸、优先 WebP、控制体积、使用独立域名、保留原图备份。等图片数量和访问规模更明确后，再决定长期落在哪种存储上。这样即使以后更换方案，也不会从零开始。

> 存储方案没有绝对最好，真正重要的是：当价格变化、服务中断或需要迁移时，图片仍然在自己手里，文章也还能正常打开。

**Categories:** 闲聊

---