业务量上来以后，用户上传的图片、视频和日志会越攒越多。放在服务器本地磁盘里，扩容麻烦，备份也费劲，这时候很多团队会考虑对象存储。阿里云OSS在国内用得比较广，容量基本不用担心，按量计费，和CDN、函数计算这些产品搭起来也顺手。下面结合实际使用，说说怎么用、怎么省钱，以及哪些地方容易出问题。
先弄清三个层级
用阿里云OSS存储之前，先理解地域（Region）、存储空间（Bucket）和对象（Object）这三层。地域决定数据存在哪个数据中心，选的时候尽量靠近主要用户，访问延迟会低一些。如果和同地域的ECS、RDS部署在一起，内网互通，流量一般不收费。Bucket是存储空间，名称全局唯一，创建后通常不能改，起名时最好带上业务和环境，比如 shop-prod-images。对象就是具体的文件，由文件内容、Key（路径名）和元数据组成。
OSS里的“文件夹”其实是逻辑上的。images/2024/06/cover.jpg 只是一个较长的Key，控制台展示的目录是按前缀模拟出来的。想清楚这一点，设计路径规则和生命周期策略时会少绕弯。
存储类型怎么选
阿里云OSS提供多种存储类型，单价和访问成本差别不小，选对了能省下一截。常见的有四种：
- 标准存储：适合频繁访问的热数据，比如商品图、网站静态资源，读写不产生额外取回费用。
- 低频访问存储：单价更低，但有最小存储时长和取回费用，适合每月只会被访问几次的数据，比如历史订单附件。
- 归档存储：适合很少访问、需要长期保留的数据，比如监控日志、备份文件。取回前要先解冻，需要等一段时间。
- 冷归档和深度冷归档：单价更低，适合合规要求保存多年、基本不会去读的数据。
有人图省事，把所有数据都设成归档，觉得这样最便宜。可如果数据经常被读取，取回费用和解冻等待会把账单抬上去，前台体验也跟着变差。选类型主要看访问频率和保留时长，只盯单价，容易选错。
一个示意场景
下面是一个示意场景，数字为举例。某内容社区每天有几十万张用户上传的图片，早期全部放在标准存储里，月度存储费用一路上涨。团队翻了访问日志，发现图片上传三十天后，超过九成基本没人再看。原图只有在编辑或被举报时才会调出来，真正高频访问的是缩略图。
于是团队调整了三处。上传时同步生成缩略图和中等尺寸图，放在标准存储里，保证前台打开够快。原图配置生命周期规则，上传三十天后转为低频访问，一年后转为归档。访问最频繁的缩略图接入CDN，减少OSS的回源请求。调整之后，存储和流量的综合成本降了不少，用户侧的加载速度没有明显变化。先看数据怎么被读，再决定放在哪一层，这个顺序别反了。
用生命周期规则自动分层
生命周期规则可以按前缀或标签设置，对象到了指定天数后自动转换存储类型，或者直接过期删除。好处是不用人盯着，也不容易忘。要留意最小存储时长：对象还没满最小时长就被删除或再次转换，会产生额外费用。所以规则上线前，最好先估一估数据的实际寿命。
权限配置别省
对象存储出事，多半出在权限上。Bucket被设成公共读写，导致数据被爬取、被乱传文件，这类情况并不少见。日常可以按下面几条做：
- 日常开发用RAM子账号，按最小权限授权，不要拿主账号AccessKey写代码。
- Bucket保持私有读写，需要公开的资源走CDN，或者只对指定前缀开放。
- 私密文件用签名URL分享，过期时间设短一点，别动辄设成几个月。
- 开启服务端加密。敏感数据可以把密钥交给KMS管理。
- 打开访问日志和实时监控，异常流量出现时能第一时间看到。
AccessKey泄露也很常见。别把密钥硬编码进代码，改用环境变量或配置中心读取，并定期轮换。
一段上传代码的参考写法
下面用Python的oss2 SDK写一个最简单的上传和签名URL示例。密钥从环境变量读取，Endpoint和Bucket名称换成你自己的。
import os
import oss2
auth = oss2.Auth(os.environ[“OSS_ACCESS_KEY_ID”], os.environ[“OSS_ACCESS_KEY_SECRET”])
bucket = oss2.Bucket(auth, “https://oss-cn-hangzhou.aliyuncs.com”, “your-bucket-name”)
bucket.put_object_from_file(“images/2024/06/cover.jpg”, “./local/cover.jpg”)
url = bucket.sign_url(“GET”, “images/2024/06/cover.jpg”, 600)
print(url)
这段代码离生产环境还差几步，异常处理、重试和日志都要补上。文件较大时改用分片上传更稳，中断后还能断点续传。
成本容易超在哪
费用除了存储单价，还有请求次数、外网流量和数据取回。账单超预期，常见原因就两个：小文件请求太多，或者大文件直接走外网下载。可以从三处下手。前端静态资源设好缓存，减少重复请求；流量大的场景接CDN，让OSS少直接对外输出；定期看用量账单和存储分析，找出增长最快的Bucket和前缀。
前期规划想清楚，阿里云OSS用起来并不难：地域怎么选，数据怎么分层，权限怎么收紧，成本怎么盯。如果你正从本地存储迁过来，可以先拿一个小Bucket跑通上传、访问、生命周期和监控，再推广到全部业务。
