做文件上传，很多人先找工具，把文件传上去再说。但存储类型选错，后面的上传方式、费用和维护都会跟着别扭。先弄清文件给谁用、访问得多不多、要存多久，再动手，省事得多。
先分清 OSS 和 NAS 各管什么
OSS（对象存储）更像一个按文件存取的大仓库。图片、视频、日志、安装包这类非结构化数据放进去，每个文件通过 HTTP 地址访问，还能接 CDN 加速。网站素材、用户上传的附件，基本都适合放这里。日常业务文件如果不需要像本地磁盘那样一层层管理，OSS 通常就够用。
NAS（文件存储）的用法更接近挂载的一块网络硬盘。它的价值在于多台服务器要读写同一份目录，比如几台应用服务器共用一批配置或素材。如果只是让网站把图片存下来、让用户能访问，NAS 反而是绕远路，多花的钱换不来对应的好处。
一个简单的判断方法：问自己这些文件是通过网址被读取，还是通过目录被程序读写。前者选 OSS，后者再考虑 NAS。
常见的上传方式
阿里云上传的方式不止一种，按场景选就行：
- 控制台手动上传：偶尔传几个文件时最直接，但批量或定时任务就不合适了。
- ossutil 命令行工具：适合上传整个目录，写进脚本后可以做定时备份。
- 官方 SDK：Java、Python、Node.js、Go 等语言都有，适合嵌在网站或应用里做用户上传。
- 表单直传配合 STS 临时授权：前端把文件直接传到 OSS，不经过业务服务器。上传量一上来，服务器压力会小很多，但临时凭证的签发和权限要配对。
个人站点用控制台或 ossutil 就够了。用户随时能上传头像和附件的应用，用 SDK 加表单直传更合适。
一个电商站的迁移过程
一个小型电商团队的商品图片最初都存在自己的服务器上，再由服务器转存到本地磁盘。商品做到几万件时，磁盘很快吃紧，图片越来越慢，高峰期页面基本打不开。小团队里这种情况很常见，问题往往不在某一处，而是所有压力都压在了同一台机器上。
后来他们分两步调整。第一步把图片迁到 OSS，并开通 CDN，静态资源的访问速度明显变快。第二步把上传改成前端通过 STS 临时凭证直传 OSS，服务器只负责签发授权和记录图片地址。带宽占用降下来不少，高峰期的卡顿也消失了。
这个例子说明，上传方案不只要能传上去，还要在存储成本、访问速度和服务器压力之间找到平衡。
上传前要确认的几项配置
Bucket 权限默认设成私有
读写权限决定文件能不能被外部看到。敏感文件保持私有，网站图片才考虑公共读。权限配错是数据泄露最常见的原因之一，所以先私有，确有需要再逐个开放。
AccessKey 不要写进前端代码
很多教程为了演示方便，会把 AccessKey 直接写在代码里。代码一旦公开，账号就可能被人滥用。更稳妥的做法是用 RAM 子账号，上传时通过 STS 临时凭证授权。
文件名和目录提前规划
文件名尽量避开中文、空格和特殊字符，前面加上日期或随机串，能减少重名覆盖。目录按业务类型和年月划分，之后查找和清理都会省力。
大文件用分片上传
文件超过一定大小，就用分片上传（Multipart Upload）。它支持断点续传，网络抖动时不用从头再传。官方 SDK 基本都封装好了，直接调用即可。
上传报错时先查什么
- 返回 403：先看 AccessKey 是否有效，再确认 RAM 策略里有没有 oss:PutObject 权限。多数情况是权限或签名的问题。
- 跨域报错：前端直传时最常见。需要在 Bucket 里配置 CORS 规则，放行对应的域名和请求方法。
- 上传慢：先检查服务器所在地域和 Bucket 地域是否一致，再考虑传输加速或就近的上传节点。
- 文件打不开：核对文件路径，检查 Bucket 是否允许读取，顺便看看是不是误用了内网域名。
成本怎么控
云存储按量计费，除了容量，还要算请求次数和外网流出流量。上传到 OSS 本身通常不收外网流量费，但大量小文件的请求数会悄悄增加账单。合并小文件、设置生命周期规则自动归档或删除过期数据，是控制长期成本最直接的办法。
账单和访问日志也值得定期看一眼。异常流量往往先在账单上露出来，越早发现，损失越小。
小结
阿里云上传看着简单，实际要处理的是存储选型、上传方式、权限安全和成本，这几件事彼此牵连。先想清楚业务需求，再选 OSS 还是 NAS，定好上传方式，并把权限和命名规则确定下来，大部分坑都能提前避开。
