把文件传到阿里云，多数情况是传到对象存储 OSS。上传方式选对了，服务器带宽能省下来，大文件中途断开也不必从头再传。下面按几种常用方式逐一说明，最后用一个假设的图片社区案例串起完整链路。
先确认文件大小、频率和上传人
动手前先问三件事。文件多大：几十 KB 的头像和几 GB 的视频，走的路不一样。谁来传：运营偶尔手动上传一次，还是用户每天提交几十万次。传输频率：一次性迁移和持续写入的要求也不同。答案不同，方案就不同。
控制台和 ossutil：人工与批量操作
登录 OSS 控制台，进入目标 Bucket，点“上传文件”即可。这种方式适合传一份报表、换一张宣传图之类的少量临时操作。
要做批量迁移或定时同步，ossutil 命令行工具更顺手。它能递归上传整个目录，也支持断点续传，网络断开后接着传。使用前配置好 AccessKey 或 RAM 角色凭证，凭证放在环境变量或本地配置文件里，不要写进脚本正文。脚本一旦进了代码仓库，密钥就等于公开了。
SDK 上传：业务系统的常规做法
业务系统一般通过 SDK 上传。常见语言都有官方支持，比如 Python 的 oss2、Java 的 aliyun-sdk-oss。流程很固定：服务端读取文件，指定 Bucket 和 Object Key，调用 put_object 之类的接口写入。
Object Key 最好在设计阶段就定好规则，比如 avatar/2024/05/用户ID.jpg。路径有结构，后面按目录管理、配置生命周期规则都方便。
上传前计算文件的 MD5 或 CRC64，接收后比对。传输中如果数据损坏，比对能发现，不必等用户反馈图片打不开。
大文件用分片上传
文件超过一定大小后，改用分片上传（Multipart Upload）。分三步：初始化任务，拿到 UploadId；把文件切成若干分片并行上传；所有分片传完后调用合并接口。
分片规格有硬限制：最多 10000 个分片，每片大小在 100KB 到 5GB 之间，最后一片可以小于 100KB。切片前先按这个范围算好分片数。
分片的好处是能并发，也能单独重试。某一片失败，只重传这一片。但如果任务没完成又没人清理，已上传的分片会继续占用存储空间，还可能产生费用。建议配置生命周期规则自动清理，同时定期调用列举接口检查残留分片。
案例：图片社区改成客户端直传
假设某图片社区早期的做法是：用户先把图片传到应用服务器，服务器再转存到 OSS。高峰期，应用服务器的出口带宽被占满，上传超时明显增多。
团队改了两处。第一，服务端不再接收文件内容，改为用 SDK 生成预签名 URL，有效期 10 分钟，只允许写入指定的 Object Key。第二，客户端拿到 URL 后直接 PUT 到 OSS。服务器只处理签发请求，流量很小，上传链路和业务服务器分开。
改完后，应用服务器的带宽压力降了不少，超时也少了。大视频文件改用分片上传后，弱网环境下的成功率也有提高。具体提升多少要看各自业务的压测结果。本案例没有给出数字，不要直接引用。
权限：只给上传需要的权限
上传凭证最需要保护。几条底线：
- 使用 RAM 子账号，只授予目标 Bucket 的 oss:PutObject 等必要权限，不要给 AccessKey 管理员权限。
- 客户端使用 STS 临时凭证，有效期设短。凭证泄露时，影响范围有限。
- 预签名 URL 限定 HTTP 方法、Object Key 和过期时间，不生成长期有效的链接。
- Bucket 开启版本控制，误覆盖文件时可以回滚到旧版本。防盗链按实际访问范围配置。
常见问题排查
- 403 错误：多半是权限不够或签名过期。依次检查 RAM 策略、Bucket 所在地域与请求地域是否一致、服务器系统时间偏差是否过大。
- 上传成功但无法访问：先查 Object 的读权限，再看 CDN 或防盗链规则是否拦截了请求。
- 大文件频繁超时：改用分片上传，适当调大并发数和单片大小。并发过高会把本地带宽占满，需要按实际网络调整。
- 存储费用异常增长：检查未完成的分片任务和旧版本文件，配置生命周期规则定期清理。
选哪种方式，取决于文件多大、谁来传、传得多频。人工操作用控制台，批量任务用 ossutil，业务系统用 SDK，大文件加分片，客户端直传配预签名 URL。
