对象存储用了一年，我才搞明白这几个计费细节

对象存储用了一年，我才搞明白这几个计费细节

起因：账单比预期贵了三倍

去年把一批图片和日志迁到对象存储，本来算下来每月几十块，结果第一个月账单出来是预期的三倍多。查了半天才发现，问题不在存储量，而在请求次数和流量方向上。

这篇把踩过的几个坑记下来，都是实际计费项，不是理论。

坑一：请求次数是按万次单独计费的

存储费只占账单的一小部分，真正的大头是 API 请求。上传、下载、列举各自计费，单价看着很低（每万次几分钱），但架不住量大：

• 一个前台列表页如果每次都调列举接口去枚举对象，一次访问就是一次计费请求，流量一上来就顶不住。
• 把对象存储当数据库用——每次读一小段数据都发一次 GET——是最贵的用法。
• 递归列举在大目录下会产生多次请求，因为服务端要分页返回。

对策：列表这类高频读取走 CDN 或加一层缓存；对象路径设计成可直接拼出来的（比如 user/12345/avatar.jpg），避免用列举接口去"找"文件。

坑二：公网流出流量和入流量不是一个价

上传（入方向）通常免费，下载（出方向）按 GB 计费，而且从公网访问和从同区域内网访问，价格差一个数量级。

最典型的浪费场景：云主机和对象存储在同一区域，但代码里用的是公网域名去拉对象。每一份数据都白交了一次公网流量费。

对策：同区域的访问一律走内网端点，跨区域同步用专门的复制功能而不是自己写脚本拉。

坑三：存储类别选错，钱花得毫无意义

不是所有数据都值得放在标准存储里。日志、备份、归档数据访问频率极低，放标准存储等于用热数据的价格存冷数据。

• 标准存储：频繁访问，毫秒级响应。
• 低频访问：月访问几次，单价明显低，但取回时有额外费用。
• 归档存储：几乎不访问，单价最低，但取回要等（分钟到小时级），且有最短存储期限制——提前删除要补收费用。

这里有个反直觉的点：低频或归档类别不是"越冷越省"。如果你的数据实际每个月都会被读一次，放低频类别反而因为取回费而更贵。选之前先看真实访问模式，别看直觉。

坑四：生命周期规则没配，等于默认永远用最贵的存法

对象存储支持按天数自动转档和删除。不配规则的话，一年前上传的日志会和今天上传的图片享受同样的存储类别和价格。

建议的规则形态大致是：

• 上传后 30 天：标准 → 低频访问
• 上传后 180 天：低频 → 归档
• 上传后 365 天：直接删除（或按合规要求保留）

配一次，之后自动执行，这是性价比最高的一步。

最后：先把计量看明白，再谈优化

我后来养成一个习惯：上线前先估一遍每月的请求次数和出流量，而不是只估容量。容量便宜，请求和流量才是账单主体。

具体到操作上，就是三件事：路径设计成可拼的、同区域走内网端点、生命周期规则配起来。这三件做完，账单基本就回到预期了。