功能优化

yudao-module-tik/UPLOAD_STRATEGY.md

@@ -0,0 +1,76 @@
+# 文件上传策略分析
+
+## 🎯 业界成熟方案：先上传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上传失败率
+   - 监控数据库保存失败率
+   - 监控孤立文件数量
+