# 文件上传策略分析

## 🎯 业界成熟方案：先上传OSS，再存数据库

### 方案对比

| 方案 | 优点 | 缺点 | 适用场景 |
|------|------|------|----------|
| **先上传OSS，再存数据库** ✅ | 1. OSS上传失败不影响数据库<br>2. 数据库事务可快速回滚<br>3. 用户体验好（文件已上传）<br>4. 孤立文件可定时清理 | 1. 数据库失败会产生孤立文件<br>2. 需要清理机制 | **推荐方案**（业界主流） |
| 先存数据库，再上传OSS | 1. 数据库失败不会上传OSS<br>2. 不会产生孤立文件 | 1. OSS上传失败需要回滚数据库<br>2. 数据库事务时间长<br>3. 用户体验差 | 不推荐 |

### 为什么选择"先上传OSS，再存数据库"？

1. **性能优势**
   - OSS上传是外部服务调用，不应该阻塞数据库事务
   - 数据库事务时间短，减少锁竞争

2. **可靠性优势**
   - OSS上传失败，直接返回错误，不产生脏数据
   - 数据库保存失败，OSS文件可以后续清理（定时任务）

3. **用户体验优势**
   - 文件已上传成功，即使数据库失败，文件还在
   - 可以重试数据库保存，无需重新上传

4. **业界实践**
   - 阿里云、腾讯云、AWS 等主流云服务都推荐此方案
   - 大多数开源项目采用此方案

### 当前实现方案

```
1. 校验（文件分类、配额）
   ↓
2. 读取文件内容
   ↓
3. 上传到OSS（FileService.createFile）
   - 成功：返回 fileUrl 和 filePath
   - 失败：直接抛出异常，不保存数据库
   ↓
4. 保存数据库（事务中）
   - 成功：返回文件ID
   - 失败：删除OSS文件，抛出异常
   ↓
5. 更新配额
```

### 异常处理

1. **OSS上传失败**
   - 直接抛出异常，不保存数据库
   - 用户可重试上传

2. **数据库保存失败**
   - 删除已上传的OSS文件（清理）
   - 抛出异常，用户可重试

3. **孤立文件清理**
   - 定时任务清理未关联数据库的OSS文件
   - 基于 infra_file 表的创建时间判断

### 优化建议

1. **异步清理孤立文件**
   - 定时任务扫描 infra_file 表
   - 删除超过7天未关联 tik_user_file 的文件

2. **重试机制**
   - 数据库保存失败时，记录重试队列
   - 后台任务重试保存

3. **监控告警**
   - 监控OSS上传失败率
   - 监控数据库保存失败率
   - 监控孤立文件数量