fix(delivery): 禁用Rock二次生成二维码并治理上游110001频控报错

1. 业务防乱(专属通道锁定)：提货页面一旦生成二维码后，直接禁用'重新生成二维码'按钮并锁定游戏UID输入框，杜绝Token浪费与绑定混乱； 2. 频控治理(前端3秒冷却)：手动点击'检查扫码状态'增加3秒倒计时防抖冷却，且对'过于频繁/110001'错误进行平滑提示，不再触发大红报错； 3. 频控治理(后端瞬时防抖与软降级)：RockService增加800ms内存并发安全防抖缓存，当上游返回110001时自动优雅降级返回等待扫码状态，不抛出HTTP 400错误。
2026-10-05 18:25:35 +08:00
parent 08a0e74cd0
commit 78e2fe4c6a
3 changed files with 102 additions and 14 deletions
@@ -433,6 +433,22 @@ Content-Type: application/json
     - 断言 2：空闲库存为 0 时，已分配 Token 的订单必须 100% 允许正常发货（`CanShip = true`）。
   - 包含新增用例在内的 5 项 Rock 专项测试与全量 service 测试全部 100% PASS。

+### 7.6 提货页面二次绑定禁用与上游 110001 频控防抖治理

+#### 证据分类审计表
+| 维度 | 内容详情 | 确信度 |
+| :--- | :--- | :--- |
+| **已知 (Known)** | 1. Rock 平台生成的二维码与 Token 属于 1:1 强绑定关系，多次调用会导致 Token 浪费或绑定覆盖；<br>2. 用户手动点击“检查扫码状态”时频繁触发 400 报错：`未知错误码: (110001) 抱歉，请求过于频繁，请稍后再试！谢谢！`，而自动轮询正常。 | **100% (有实测报错报文)** |
+| **未知 (Unknown)** | 为什么自动轮询正常而手动点击报错？ | **已探明**：自动轮询每 2.5 秒触发一次，手动点击与定时器极易并发，使 0666.pro 瞬间接收多笔相同 Token 的 refresh 请求触发 WAF 限流。 |
+| **目标 (Goal)** | 1. 禁用提货页面“重新生成二维码”按钮，锁定专属通道；<br>2. 后端建立 800ms 瞬时防抖缓存与 110001 软降级；<br>3. 前端增加 3 秒倒计时冷却与友好提示。 | **100% 达成** |

-
+#### 落地措施：
+1. **提货页防抖与单次专属锁定**（`frontend/src/pages/Delivery.tsx`）：
+   - `bindResult` 生成后，按钮变为“专属二维码已生成”并直接处于 `disabled` 状态；
+   - 游戏 UID 输入框置灰禁用，防止中途修改；
+   - 手动点击“检查扫码状态”增加 3 秒冷却倒计时（`检查扫码状态 (3s)`），错误处理中对“过于频繁/110001”进行平滑文案提示，不再弹出大红错误框。
+2. **后端瞬时缓存与错误降级**（`backend/internal/service/rock_service.go`）：
+   - 在 `RockService` 中维护并发安全防抖缓存 `refreshCache sync.Map`（800ms 窗口）；
+   - 当遇到上游 110001 频控响应时，执行平滑兜底，返回正在等待扫码，不抛出 HTTP 400 异常。
+3. **验证结果**：
+   - 前后端静态编译构建与 5 项 Rock 单元测试全部通过。