做 Web 或移动应用时，文件上传看起来简单，真正上线后却容易出问题：大文件超时、速度慢、服务器带宽被占满，严重时密钥还会泄露。阿里云对象存储 OSS 提供了成熟的上传方案，选对方式就能避开大部分坑。本文用一个典型场景，梳理阿里云文件上传的几种方式和配置要点。
一、一个常见的踩坑场景
某在线教育平台需要讲师上传课程视频，单个文件从几百 MB 到数 GB 不等。最初的做法是前端把文件发给自家应用服务器，再由服务器转存到 OSS。上线后问题很快出现：视频流量占满服务器带宽，页面其他接口明显变慢；大文件要经过两次传输，超时频繁；高峰期服务器临时磁盘空间吃紧，经常告警。
后来团队改了思路，让文件从浏览器直接传到 OSS，应用服务器只负责发放上传凭证。服务器压力随之下降，讲师端的上传成功率也跟着好转。这次调整的要点很简单：服务器只负责“发证”，不再负责“搬运”。
二、OSS 常见的上传方式
阿里云 OSS 的上传方式主要有四种，适用场景各不相同：
- 简单上传（PutObject）：一次请求上传整个文件，适合小文件。单个文件上限为 5GB，超过这个大小就要换方案。
- 分片上传（Multipart Upload）：把大文件切成多个分片并行上传，最后合并。适合大文件和网络不稳定的场景，断点续传也基于这一机制。
- 表单上传（PostObject）：通过 HTML 表单或简单请求直接提交到 OSS，适合只需要基础上传能力的页面。
- 服务端签名直传：应用服务器生成带签名的临时上传策略，前端凭策略直接请求 OSS。多数生产环境会选这种方式。
三、服务端签名直传怎么做
直传的前提是安全。AccessKey 绝对不能写进前端代码，一旦泄露，账号下的存储资源都可能被人滥用。比较稳妥的流程是：
- 前端请求应用服务器，拿到上传所需的临时凭证或签名参数。
- 服务器用 RAM 子账号或 STS 临时安全令牌生成凭证，有效期设成几分钟即可，过期自动失效。
- 前端带着凭证直接上传到指定的 Bucket 和 Object 路径。
- 上传完成后，前端通知服务器记录文件信息，由服务器完成入库和后续处理。
有两个细节容易被忽略。一是限制上传范围：凭证只允许写入指定目录，并限定文件大小和类型，否则凭证被拿去传别的东西也拦不住。二是文件路径设计：按用户 ID 和日期分层存放，文件名用 UUID。这样好管理，也不会因重名覆盖文件，还能减少原始文件名泄露的风险。
四、大文件上传的几个参数
回到前面的教育平台。视频动辄数 GB，团队最终采用分片上传加断点续传。阿里云各语言 SDK 已经封装了分片逻辑，实际开发时主要调下面几个参数：
- 分片大小：要在并发效率和请求次数之间取舍。分片太小，请求数量会猛增；太大，单片失败后重传的成本又高。可以按文件大小动态设定，比如几百 MB 的文件用较小分片，几 GB 的文件用较大分片。
- 并发数：并发太高容易触发限流，还会占用浏览器资源。一般 3 到 5 路并发就够用，之后再根据实际表现微调。
- 重试机制：网络抖动导致单片失败时，用指数退避方式重试，避免短时间内反复请求同一个地址。
- 进度记录：把已完成的分片信息存到本地，页面刷新后可以从断点接着传，不必从头再来。
五、跨域与权限配置
前端直传 OSS 一定会遇到跨域问题。需要在 Bucket 的跨域规则里添加允许的来源域名、请求方法（PUT、POST），以及需要暴露的响应头，比如 ETag。这一步配错是最常见的“上传失败”原因。遇到问题时，先看浏览器控制台有没有 CORS 报错，能省下不少排查时间。
Bucket 的读写权限建议保持私有。需要公开访问的文件，通过 CDN 或签名 URL 对外提供。上传用的子账号只授予必要的写入权限，不要图省事直接给全量权限，出问题时影响范围会小很多。
六、选型建议
小文件直接用简单上传即可，大文件走分片上传和断点续传，只要涉及前端直传，就用服务端签名的方式。配置时把凭证范围、跨域规则和重试策略一起确定下来，上传链路才会稳定。文中案例的数字和场景为示意，实际的分片大小、并发数等参数，建议结合自己的业务做一轮压测再定。
