# 任务：修复一番赏次数卡支付与退款逻辑

## 1. 项目上下文分析
- **项目**: BindBox (Blind Box / Ichiban Kuji Game Platform)
- **技术栈**: Go (Backend), Vue3/UniApp (Frontend)
- **涉及模块**:
    - 前端：一番赏活动页 (`bindbox-mini/pages-activity/activity/yifanshang/index.vue`)
    - 后端：抽奖接口 (`internal/api/activity/lottery_app.go`)
    - 后端：退款接口 (`internal/api/admin/pay_refund_admin.go`)

## 2. 需求理解与确认
### 原始需求
1.  **不掉支付**: 使用次数卡（Count Card）进行一番赏抽奖时，不应拉起微信支付（因为金额应为0）。
2.  **退款退卡**: 对使用次数卡支付的订单进行退款时，应退还次数卡（次数），而非退款金额（因为金额为0）或无操作。

### 问题分析
通过代码审查，发现以下问题：
1.  **前端支付逻辑缺陷**: `index.vue` 在调用 `joinLottery` 后，未根据返回的订单状态或金额判断是否需要支付，而是无条件调用 `createWechatOrder` 并拉起支付。
2.  **后端抽奖逻辑缺陷**: `lottery_app.go` 在使用次数卡扣费时，虽然将 `ActualAmount` 设为 0，但在 `order.Remark` 中仅记录了 `use_game_pass`，未记录具体使用的次数卡 ID 和扣除数量。
3.  **后端退款逻辑缺陷**: `pay_refund_admin.go` 在退款时尝试从 `order.Remark` 解析 `game_pass:ID`，但由于上述原因无法解析。且当前逻辑仅尝试恢复 `remaining + 1`，未考虑到一单多抽（Count > 1）的情况。

## 3. 智能决策策略
### 决策点 1：前端如何判断跳过支付？
- **方案**: 检查 `joinLottery` 返回的 `actual_amount` 或 `status`。
- **依据**: `lottery_app.go` 中，若金额为 0，`Status` 会被置为 2 (Paid)，且 `ActualAmount` 为 0。
- **实现**: 若 `res.actual_amount === 0` 或 `res.status === 2`，则直接进入抽奖结果展示流程。

### 决策点 2：后端如何记录次数卡使用情况？
- **方案**: 修改 `lottery_app.go`，在 Deduction 循环中记录所有使用的 Pass ID 和对应扣除数。
- **格式建议**: `gp_use:ID1:Count1|gp_use:ID2:Count2`
- **兼容性**: 需确保不破坏现有 Remark 的其他信息。

### 决策点 3：退款如何恢复次数？
- **方案**: 修改 `pay_refund_admin.go`，解析新的 Remark 格式。
- **逻辑**: 遍历所有记录的 ID，按记录的扣除数执行 `UPDATE user_game_passes SET remaining = remaining + ?, total_used = total_used - ? WHERE id = ?`。

## 4. 最终共识 (Consensus)
### 任务边界
1.  **Frontend**: 修改 `yifanshang/index.vue` 的 `onPaymentConfirm` 方法。
2.  **Backend**: 修改 `lottery_app.go` 记录 Game Pass Usage。
3.  **Backend**: 修改 `pay_refund_admin.go` 实现精准的次数卡退还。

### 验收标准
1.  **支付测试**: 使用次数卡购买一番赏（单抽或多抽），前端不弹出微信支付，直接显示抽奖结果。
2.  **数据验证**: 数据库 `orders` 表的 `remark` 字段包含具体的次数卡使用记录（如 `gp_use:101:5`）。
3.  **退款测试**: 对该订单执行全额退款，对应的次数卡（ID 101）的 `remaining` 增加 5，`total_used` 减少 5。
