在Web应用开发中，文件上传是一个极其常见的需求。随着云服务的普及，将文件直接存储到云存储服务（如阿里云OSS、腾讯云COS、AWS S3等）已成为标准做法。然而，一个关键的架构问题随之而来：文件上传的路径，究竟应该让前端直接与OSS交互，还是统一经由后端服务器转发？

这个问题没有唯一的正确答案，但有一个在当前环境下被广泛认为是最佳的实践。让我们深入分析一下两种模式的优劣。

方案一：前端直传OSS

在这种模式下，前端应用直接从OSS服务提供商获取一个临时上传凭证，然后使用这个凭证将文件直接上传到OSS，上传成功后，将文件的最终地址告诉后端服务器。

流程大致如下：

1. 前端请求后端API，获取上传凭证（例如，阿里云的STS Token）。
2. 后端校验用户权限，向OSS服务商申请临时Token，并返回给前端。
3. 前端使用这个临时Token，调用OSS的SDK，将文件直接上传至OSS。
4. 上传成功后，OSS返回文件地址。
5. 前端将文件地址提交给后端，保存到业务数据库中。

优势

1. 极高的性能：文件流不经过后端服务器，节省了服务器的上行和下行带宽，大大减轻了后端服务器的负载和压力。
2. 高扩展性与稳定性：OSS等云服务专为海量文件存储和分发设计，自带容灾和扩展能力，上传体验更稳定、更快速。
3. 更好的用户体验：上传进度、断点续传等功能可以由OSS SDK直接提供，体验更佳。

劣势

1. 安全风险管控复杂：虽然使用了临时凭证，但权限控制的粒度需要精心设计。比如，临时Token的权限范围、有效期、允许上传的路径和文件类型等，都需要在后端严格管控，否则可能产生安全漏洞。
2. 后端业务逻辑受限：如果文件上传后需要立即进行处理（如图像压缩、内容审核、病毒扫描等），直传模式就不太方便，通常需要配合OSS的“回调”或“事件通知”功能来实现，增加了架构的复杂性。
3. 客户端依赖：需要在前端引入OSS的SDK，略微增加前端应用的体积。

方案二：后端代理上传

这是传统的方式，前端将文件通过multipart/form-data形式提交给自己的后端服务器，再由后端服务器使用永久秘钥将文件转发到OSS。

流程大致如下：

1. 前端通过表单或API将文件数据发送到后端接口。
2. 后端接收文件流，进行权限验证、病毒扫描、内容校验等。
3. 后端使用自己的AccessKey，调用OSS SDK将文件上传至OSS。
4. 后端将上传成功后的文件地址保存到数据库，并返回给前端。

优势

1. 安全性高，控制力强：所有请求都经过后端服务器，可以方便地进行严格的权限校验、内容安全审查、文件类型和大小限制等。
2. 业务处理无缝衔接：文件上传后可以立即在服务器端进行后续处理，流程简单直接。
3. 对前端透明：前端无需关心使用的是哪家云存储，后端可以随时更换存储服务商而前端无感。

劣势

1. 服务器性能瓶颈：文件流需要经过后端服务器，消耗大量的服务器带宽和CPU资源。当上传大文件或并发量高时，服务器可能成为性能和单点故障的瓶颈。
2. 用户体验可能不佳：上传速度受限于后端服务器的带宽，且实现断点续传、分片上传等功能更为复杂。
3. 扩展性差：需要自行优化服务器和带宽来应对上传流量高峰，成本较高且不灵活。

核心安全机制：STS（安全令牌服务）

在分析前端直传的劣势时，我们提到了安全风险。而STS（Security Token Service） 正是解决这个问题的钥匙。

STS是云厂商提供的一种颁发临时访问凭证的服务。这些临时凭证具备以下特点：

• 时效性极短：通常有效期为15分钟至几小时。
• 权限受限：遵循“最小权限原则”，只能执行特定的操作（如：只能向指定目录上传文件）。
• 无需暴露主账号秘钥：前端使用的是有时效、有限权的Token，即使泄露，危害也远小于泄露后端的永久AccessKey。

通过STS，我们既享受了前端直传的性能优势，又极大地规避了安全风险。这使得“前端直传+STS”的组合成为了事实上的最佳实践。

最佳实践推荐：前端直传 + STS + 后端管控

综合以上分析，我们推荐采用一种混合架构，它集两种模式之长，避两者之短。

架构流程图：

sequenceDiagram
    participant U as 前端用户
    participant S as 后端服务器
    participant STS as 云STS服务
    participant O as 对象存储(OSS)

    U->>S: 1. 请求上传凭证
    Note right of S: 校验用户权限、<br>定义上传策略
    S->>STS: 2. 申请临时Token
    STS-->>S: 3. 返回临时Token
    S-->>U: 4. 返回临时Token和上传配置
    U->>O: 5. 使用临时Token直传文件
    O-->>U: 6. 返回文件URL
    U->>S: 7. 通知上传成功(提交文件URL)
    Note right of S: 保存文件信息到DB

这个方案的核心要点：

1. 上传凭证由后端签发：后端完全掌控了上传的“准入”规则。它可以：

   • 验证用户是否已登录。
   • 动态定义上传路径（如：user_{uid}/avatar/{random_name}.jpg），避免覆盖和冲突。
   • 严格限制上传的文件类型、大小。
   • 通过STS服务，生成一个受限的临时Token返回给前端。

2. 文件流前端直传：前端拿到凭证后，直接与OSS通信，享受高性能和稳定性。可以利用OSS SDK的强大功能，实现分片上传、断点续传和进度条。

3. 后端负责最终登记：前端上传成功后，将最终的文件地址发送回后端，由后端将其与业务实体（如用户、文章）关联，并存入数据库。

4. （可选）结合云函数处理后续任务：如果文件上传后需要即时处理（如生成缩略图），可以配置OSS的事件触发器，当文件上传完成后，自动通知一个云函数（如Serverless Function）或消息队列，由它们来异步处理，从而不阻塞主上传流程。

结论

对于绝大多数场景，“前端直传 + STS临时凭证 + 后端权限与控制” 是现代Web应用上传文件到OSS的最佳实践。

• 追求性能和扩展性？ 它做到了。
• 担心安全问题？ STS和严格的后端策略提供了坚实保障。
• 需要复杂的后处理？ 通过事件驱动和异步处理可以优雅地解决。

因此，在架构选型时，请优先考虑这种混合模式。它有效地在前端的灵活性与后端控制力之间取得了平衡，既能应对高并发海量文件上传的挑战，又能确保业务和数据的安全可靠。