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

## 1. 需求描述与验收标准
### 需求描述
- **不掉支付**: 使用次数卡支付时，若订单金额为0，前端不应拉起微信支付，直接视为支付成功。
- **退款退卡**: 次数卡支付的订单退款时，需准确退还使用的次数卡次数。

### 验收标准
1.  **前端支付流程**:
    - [ ] 使用次数卡全额抵扣时，点击“去支付”后直接弹出成功/翻牌界面，无微信支付弹窗。
    - [ ] 混合支付（次数卡不足补差价）时，仍正常拉起支付（本次主要关注全额抵扣）。
2.  **后端订单记录**:
    - [ ] 数据库 `orders.remark` 字段正确记录 `gp_use:<ID>:<Count>`。
    - [ ] 支持单次使用多张次数卡的情况（如 `gp_use:101:5|gp_use:102:1`）。
3.  **退款流程**:
    - [ ] 对次数卡订单执行退款，对应的 `user_game_passes` 记录 `remaining` 增加，`total_used` 减少。
    - [ ] 退还数量与扣除数量完全一致。
    - [ ] 退款流水清晰。

## 2. 技术实现方案
### 前端 (Mini-Program)
- 修改 `bindbox-mini/pages-activity/activity/yifanshang/index.vue`。
- 在 `onPaymentConfirm` 中，接收 `joinLottery` 响应后，判断 `order.ActualAmount == 0` 或 `Status == 2`。
- 若满足，直接调用 `onPaymentSuccess` 或模拟成功逻辑，跳过 `createWechatOrder`。

### 后端 (Go)
- **抽奖 (Lottery)**:
    - 修改 `internal/api/activity/lottery_app.go`。
    - 在扣除 Game Pass 的循环中，动态构建 Remark 字符串，记录每个 Pass 的扣除量。
- **退款 (Refund)**:
    - 修改 `internal/api/admin/pay_refund_admin.go`。
    - 升级 Remark 解析逻辑，支持 `gp_use:ID:Count` 格式。
    - 遍历所有使用的 Pass，逐一执行恢复 SQL。

## 3. 任务边界限制
- 仅针对一番赏业务（Ichiban）。
- 仅针对 Game Pass (次数卡) 支付方式。
- 不涉及优惠券退款逻辑变更（除非受全额退款逻辑影响，需确保兼容）。

## 4. 确认所有不确定性已解决
- 已确认当前 Frontend 无条件拉起支付是 Bug。
- 已确认当前 Backend 未记录详细 Pass ID 是导致无法精确退款的原因。
- 已确认 Refund 逻辑需升级以支持多卡/多数量退还。
