fix(rock): 修复空闲库存为0时误将已分配订单判定为补货中并拦截发货的严重漏洞

1. 根因修复(状态机死锁)：当一笔订单分配了池中最后一个可用Token后，空闲库存降为0。原PrepareDelivery仅检查AvailableStock<=0，导致已锁定Token的订单在发货校验时被误判为'库存补充中'并硬性拦截发货；
2. 逻辑重构：PrepareDelivery增加已预占Token识别，若当前订单已持有using或bound状态的专属Token，直接豁免空闲库存校验，放行扫码与发货；
3. 协议对齐：在ClaimTokens与RefreshToken中补全Origin与Referer请求头；
4. 单元测试与方案文档：新增TestRockProvider_PrepareDelivery_ZeroStockWithAssignedToken用例，5项Rock专项单测与全量Service测试100%全绿通过，方案文档追加7.5节证据与复盘记录。

backend/internal/service/provider_rock.go

@@ -45,16 +45,41 @@ func (p *RockProvider) PrepareDelivery(ctx context.Context, order *model.Fulfill
 	}
 
 	// 2. 检查可用库存
-	stats, err := p.rockService.GetStats(ctx)
-	if err != nil {
-		return nil, fmt.Errorf("获取库存失败: %w", err)
+	// 注意：若当前订单已经分配并锁定了专属 Token (using 或 bound 状态)，说明该订单库存已经预占成功，
+	// 绝不能因为池子中剩余的空闲库存为 0 而阻断该订单的发货与扫码提货流程！
+	hasAssignedToken := false
+	orderNo := ""
+	if order != nil && strings.TrimSpace(order.OrderNo) != "" {
+		orderNo = strings.TrimSpace(order.OrderNo)
+	} else if openOrder != nil && strings.TrimSpace(openOrder.OrderNo) != "" {
+		orderNo = strings.TrimSpace(openOrder.OrderNo)
 	}
-	if stats.AvailableStock <= 0 {
-		return &DeliveryOrderState{
-			CanShip:          false,
-			CannotShipReason: "当前商品库存补充中，已通知管理员自动补货，请稍后刷新或联系客服",
-			Provider:         ProviderRock,
-		}, nil
+
+	if orderNo != "" {
+		var assignedCount int64
+		_ = p.rockService.db.WithContext(ctx).Model(&model.RockToken{}).
+			Where("assigned_order_no = ? AND status IN (?, ?)", orderNo, model.RockStatusUsing, model.RockStatusBound).
+			Count(&assignedCount).Error
+		if assignedCount > 0 {
+			hasAssignedToken = true
+		}
+	}
+
+	if !hasAssignedToken {
+		stats, err := p.rockService.GetStats(ctx)
+		if err != nil {
+			return nil, fmt.Errorf("获取库存失败: %w", err)
+		}
+		if stats.AvailableStock <= 0 {
+			// 若开启了自动补货，立即触发一次补货检查
+			go p.rockService.CheckStockAndAutoPurchase(context.Background())
+
+			return &DeliveryOrderState{
+				CanShip:          false,
+				CannotShipReason: "当前商品库存补充中，已通知管理员自动补货，请稍后刷新或联系客服",
+				Provider:         ProviderRock,
+			}, nil
+		}
 	}
 
 	sku := ""

backend/internal/service/provider_rock_test.go

@@ -71,6 +71,62 @@ func TestRockProvider_KillSwitch(t *testing.T) {
 	_ = cfg
 }
 
+func TestRockProvider_PrepareDelivery_ZeroStockWithAssignedToken(t *testing.T) {
+	db := newRockTestDB(t)
+	client := NewRockClient("https://example.com")
+	rockSvc := NewRockService(db, client)
+	provider := NewRockProvider(rockSvc)
+
+	// 开启总开关
+	tr := true
+	_, _ = rockSvc.UpdateConfig(context.Background(), UpdateRockConfigReq{
+		AutoDeliveryEnabled: &tr,
+	})
+
+	// 当前数据库没有可用 Token (available = 0)
+	// 场景 1：未分配 Token 的新订单
+	newOrder := &model.FulfillmentOrder{
+		OrderNo:    "ROCK-ORDER-NEW",
+		ProductSKU: model.RockSKUBlackTshirt,
+	}
+	stateNew, err := provider.PrepareDelivery(context.Background(), newOrder, nil)
+	if err != nil {
+		t.Fatalf("prepare new order: %v", err)
+	}
+	if stateNew.CanShip {
+		t.Fatalf("库存为 0 且未分配 Token 时新订单应该不可发货")
+	}
+	if !strings.Contains(stateNew.CannotShipReason, "库存补充中") {
+		t.Fatalf("期望库存补充中提示，实际为: %s", stateNew.CannotShipReason)
+	}
+
+	// 场景 2：已分配并锁定 Token 的订单 (using 或 bound 状态)
+	assignedOrder := &model.FulfillmentOrder{
+		OrderNo:    "ROCK-ORDER-ASSIGNED",
+		ProductSKU: model.RockSKUBlackTshirt,
+	}
+	now := time.Now()
+	token := model.RockToken{
+		UpstreamTokenID: "999888",
+		Token:           "token_assigned",
+		RedeemCode:      "code_assigned",
+		Color:           model.RockColorBlack,
+		Status:          model.RockStatusBound,
+		AssignedOrderNo: "ROCK-ORDER-ASSIGNED",
+		ExpectedUID:     "123456",
+		ClaimedAt:       &now,
+	}
+	db.Create(&token)
+
+	stateAssigned, err := provider.PrepareDelivery(context.Background(), assignedOrder, nil)
+	if err != nil {
+		t.Fatalf("prepare assigned order: %v", err)
+	}
+	if !stateAssigned.CanShip {
+		t.Fatalf("已分配并锁定 Token 的订单即使池子空闲库存为 0 也必须允许继续提货发货: %s", stateAssigned.CannotShipReason)
+	}
+}
+
 func TestRockProvider_AntiGhostAndUIDMismatch(t *testing.T) {
 	db := newRockTestDB(t)
 

backend/internal/service/rock_client.go

@@ -277,7 +277,9 @@ func (c *RockClient) ClaimTokens(ctx context.Context, bearerToken string, color
 	}
 	req.Header.Set("Authorization", fmt.Sprintf("Bearer %s", strings.TrimSpace(bearerToken)))
 	req.Header.Set("Content-Type", "application/json")
-	req.Header.Set("Accept", "application/json")
+	req.Header.Set("Accept", "application/json, text/plain, */*")
+	req.Header.Set("Origin", "https://0666.pro")
+	req.Header.Set("Referer", "https://0666.pro/")
 
 	resp, err := c.httpClient.Do(req)
 	if err != nil {
@@ -345,7 +347,9 @@ func (c *RockClient) RefreshToken(ctx context.Context, bearerToken string, upstr
 	if bearerToken != "" {
 		req.Header.Set("Authorization", fmt.Sprintf("Bearer %s", strings.TrimSpace(bearerToken)))
 	}
-	req.Header.Set("Accept", "application/json")
+	req.Header.Set("Accept", "application/json, text/plain, */*")
+	req.Header.Set("Origin", "https://0666.pro")
+	req.Header.Set("Referer", "https://0666.pro/")
 
 	resp, err := c.httpClient.Do(req)
 	if err != nil {

docs/Rock发货平台代理接入与库存风控实施方案.md

@@ -401,5 +401,38 @@ Content-Type: application/json
 3. **FulfillID 兜底流**：官方单号提取优先从 `token.upstream_fulfill_id` 读取，若兑换后无单独 ID 则平滑兼容；
 4. **编译与单测**：全量单元测试与编译均已 100% 通过。
 
+### 7.5 “提货页补货中与发货报错”死锁漏洞排查记录（基于自身的补货中, 但是后台正常.har 铁证）
+
+#### 证据分类审计表
+| 维度 | 内容详情 | 确信度 |
+| :--- | :--- | :--- |
+| **已知 (Known)** | 1. 用户反馈：自己的发货页面一直提示“补货中”，后台发货一直报错拦截，但上游 0666.pro 平台却可以正常发货；<br>2. 抓包证实 Token 152317 绑定正常且在上游已成功发货（账号：`屛堃`，UID：`3640883661`）；<br>3. 数据库中订单 33 已完成发货，可用 Token 数量正好归零 (`AvailableStock = 0`)。 | **100% (有 HAR 报文与 DB 记录双重佐证)** |
+| **未知 (Unknown)** | 为何订单明明已分配 Token 且绑定成功，提货页与发货接口仍强制判定为不可发货并提示“补货中”？ | **已探明** |
+| **目标 (Goal)** | 修复 `PrepareDelivery` 状态机判定，订单一旦成功预占分配 Token，无论池子空闲库存是否为 0，均允许正常进入扫码与发货履约流程。 | **100% 达成** |
+
+#### 致命逻辑盲区根因解构：
+1. **死锁链条**：
+   - 当一笔订单分配了池中最后一个 Token 后，数据库中 `status = 'available'` 的空闲 Token 数量变为 `0`；
+   - 买家扫码授权后，提货页轮询或点击发货，外层均调用 `PrepareDelivery` 进行发货前瞻校验；
+   - 原代码无条件执行：
+     ```go
+     if stats.AvailableStock <= 0 {
+         return &DeliveryOrderState{CanShip: false, CannotShipReason: "当前商品库存补充中..."}
+     }
+     ```
+   - 原逻辑**完全忽略了当前订单其实早就成功预占了专属 Token**！
+   - 导致提货页直接弹窗横幅提示“当前商品库存补充中”，并在买家点击发货时被 `if !info.CanShip` 硬性拦截报 400 错误！
+   - 此时由于上游 0666.pro 已经完成微信扫码绑定，用户前往 0666.pro 官方后台点击发货自然能够成功，造成了“自己系统报补货中，但官方后台发货正常”的假象。
+2. **修复落地**：
+   - 在 `PrepareDelivery` 中增加专属已占库存识别：如果当前订单号已存在 `using` 或 `bound` 状态的 Token，判定为库存已锁定，豁免空闲库存校验；
+   - 针对未分配 Token 的新订单，在空闲库存不足时若开启了自动采购，即刻触发异步补货巡检；
+   - 在 `ClaimTokens` 与 `RefreshToken` 中补齐 `Origin` 与 `Referer` 头。
+3. **回归测试门禁**：
+   - 新增单元测试 `TestRockProvider_PrepareDelivery_ZeroStockWithAssignedToken`：
+     - 断言 1：空闲库存为 0 时，新订单被正确拦截并提示“库存补充中”；
+     - 断言 2：空闲库存为 0 时，已分配 Token 的订单必须 100% 允许正常发货（`CanShip = true`）。
+   - 包含新增用例在内的 5 项 Rock 专项测试与全量 service 测试全部 100% PASS。
+
+