# 任务中心优化方案

## 1. 现状分析
当前任务中心 (`internal/service/task_center/service.go`) 在奖励发放和进度更新逻辑上存在以下隐患：

1.  **错误处理缺失 (Critical)**: `grantTierRewards` 方法中，调用 `userSvc` (积分、优惠券等) 的返回值被直接忽略 (`_ = ...`)。如果发放失败，系统仍会记录“已发放”日志，导致用户无法收到奖励且无法补发。
2.  **并发安全问题 (High)**:
    -   `OnOrderPaid` 和 `OnInviteSuccess` 中，进度更新（如 `OrderCount++`）是在内存中计算后保存，存在“丢失更新”风险。
    -   `matchAndGrant` 中 `ClaimedTiers` 的更新也存在并发覆盖风险，可能导致同一个奖励被多次领取或领取状态丢失。
3.  **事务一致性 (Medium)**: 奖励发放（User Service）与日志记录（Task Log）不在同一事务中。虽然完全一致性难以在不重构的前提下实现，但目前的“忽略错误”加剧了不一致风险。

## 2. 优化方案

### 2.1 强化错误处理
在 `grantTierRewards` 中，严格检查每一个奖励发放接口的返回值。
-   如果任何一个奖励发放失败，立即返回错误。
-   利用外层事务回滚机制，确保 `TaskEventLog` 不会被写入（状态不会变为 granted）。
-   *副作用*: 对于包含多个奖励的任务，如果中途失败，可能会导致部分奖励重复发放（下次重试时）。但在当前架构下，这是优于“完全不发”的权衡选择。

### 2.2 并发控制与原子更新
1.  **原子计数**: 使用 SQL 层面的原子递增 (`order_count = order_count + 1`) 替代内存自增。
2.  **悲观锁**: 在读取 `UserTaskProgress` 时使用 `SELECT ... FOR UPDATE`，确保同一用户的并发事件（如并发支付）串行处理，防止状态覆盖。

### 2.3 代码重构
-   优化 `OnOrderPaid` 和 `OnInviteSuccess` 逻辑，确保 `matchAndGrant` 在锁的保护范围内执行。

## 3. 实施步骤
1.  修改 `internal/service/task_center/service.go`:
    -   重构 `OnOrderPaid` / `OnInviteSuccess` 使用事务和锁。
    -   重构 `grantTierRewards` 增加错误处理。
2.  验证修改。

## 4. 验收标准
- [ ] 模拟发奖失败场景，确保不会记录 `TaskEventLog`。
- [ ] 代码审查确认所有 `userSvc` 调用均处理了 error。
- [ ] 确认进度更新使用了锁机制。