# 重构：发车任务复用游戏模块逻辑 v3.11.0

**版本**: v3.11.0  
**日期**: 2025-10-08  
**类型**: Major Refactoring (重大重构)

---

## 问题背景

用户反馈批量自动化的发车功能存在很大问题，虽然经过多次修复（v3.9.5 ~ v3.10.3），但仍然不稳定，包括：
- 超时问题（`car_getrolecar` 20000ms 仍然超时）
- 错误 200400（账号未加入俱乐部）
- 错误 200020（车辆冷却期或状态未同步）
- 激活账号逻辑（`role_getroleinfo`）不稳定
- 等待时间过长（3秒同步延迟）

而游戏功能模块（`CarManagement.vue`）中的发车功能一直工作正常，用户能够在单个 token 上快速、可靠地完成车辆查询、刷新、收获、发送操作。

**用户建议**:
> "我觉得批量自动化的发车还是有很大问题，能不能直接复用游戏功能模块的查询车辆信息，然后先全部收获，再批量刷新（可选的），最后全部发车"

---

## 重构目标

1. **代码复用**: 直接移植游戏功能模块（`CarManagement.vue`）中已验证可用的逻辑到批量自动化（`batchTaskStore.js`）
2. **简化流程**: 移除不必要的"激活账号"步骤和过长的等待时间
3. **统一超时**: 使用游戏模块的超时配置（10000ms for query, 5000ms for refresh/claim/send）
4. **保持一致**: 确保批量自动化和游戏模块的行为完全一致

---

## 重构内容

### 1. 移除"激活账号"步骤

**旧逻辑**:
```javascript
// 第0步：先获取角色信息（激活账号）
console.log(`👤 [${tokenId}] 获取角色信息（激活账号）...`)
try {
  await tokenStore.sendMessageAsync(tokenId, 'role_getroleinfo', {}, 5000)
  console.log(`✅ [${tokenId}] 角色信息获取成功`)
} catch (error) {
  console.warn(`⚠️ [${tokenId}] 角色信息获取失败: ${error.message}，继续尝试查询车辆`)
}

// 等待一下，让服务器处理
await new Promise(resolve => setTimeout(resolve, 1000))
```

**新逻辑**:
```javascript
// 直接查询车辆，无需"激活账号"步骤
```

**理由**:
- 游戏功能模块没有此步骤，直接查询车辆就能成功
- 此步骤增加了 6 秒的额外延迟（5秒超时 + 1秒等待），影响效率
- 实际测试表明，此步骤并非必需

---

### 2. 调整超时时间

**旧配置**:
- `car_getrolecar`: 20000ms (20秒)
- `car_refresh`: 5000ms
- `car_claim`: 5000ms
- `car_send`: 5000ms

**新配置**（与游戏模块保持一致）:
- `car_getrolecar`: 10000ms (10秒)
- `car_refresh`: 5000ms
- `car_claim`: 5000ms
- `car_send`: 5000ms

**理由**:
- 游戏模块使用 10000ms 查询超时，实测非常快（< 1秒）
- 20000ms 的超时时间过于保守，反而掩盖了真实的服务器响应问题
- 如果 10000ms 仍然超时，说明是账号未加入俱乐部等服务器端问题

---

### 3. 简化批量收获逻辑

**旧逻辑**:
```javascript
// 第4步：批量收获
console.log(`🎁 [${tokenId}] 开始批量收获...`)
let claimSuccessCount = 0
let claimSkipCount = 0

for (const carId of carIds) {
  const carInfo = carDataMap[carId]
  const state = getCarState(carInfo)
  
  if (state === 2) { // 已到达
    try {
      await tokenStore.sendMessageAsync(tokenId, 'car_claim', { carId: carId }, 5000)
      claimSuccessCount++
      console.log(`✅ [${tokenId}] 收获车辆成功: ${carId}`)
      carInfo.claimAt = 1 // 标记已收获
      carInfo.sendAt = 0
    } catch (error) {
      console.log(`❌ [${tokenId}] 收获车辆失败: ${carId} - ${error.message}`)
    }
  } else {
    claimSkipCount++
  }
  
  await new Promise(resolve => setTimeout(resolve, 300))
}

// 等待服务器状态同步（收获→待发车需要时间）
console.log(`⏳ [${tokenId}] 等待服务器状态同步（3秒）...`)
await new Promise(resolve => setTimeout(resolve, 3000))

// 重新查询车辆状态
console.log(`🔍 [${tokenId}] 重新查询车辆状态...`)
const finalQueryResponse = await tokenStore.sendMessageAsync(tokenId, 'car_getrolecar', {}, 20000)
```

**新逻辑**（与游戏模块保持一致）:
```javascript
// Step 3.1: 批量收获已到达的车辆（state: 2）
console.log(`🎁 [${tokenId}] 第1步：批量收获已到达的车辆`)
const arrivedCars = carIds.filter(carId => getCarState(carDataMap[carId]) === 2)

if (arrivedCars.length === 0) {
  console.log(`⚠️ [${tokenId}] 没有已到达的车辆可以收获`)
} else {
  console.log(`🎁 [${tokenId}] 找到 ${arrivedCars.length} 辆已到达的车辆`)
  
  for (let i = 0; i < arrivedCars.length; i++) {
    const carId = arrivedCars[i]
    console.log(`🎁 [${tokenId}] 收获进度: ${i + 1}/${arrivedCars.length}`)
    
    try {
      await tokenStore.sendMessageAsync(tokenId, 'car_claim', { carId: carId }, 5000)
      claimSuccessCount++
      console.log(`✅ [${tokenId}] 收获车辆成功: ${carId}`)
    } catch (error) {
      console.error(`❌ [${tokenId}] 收获车辆失败: ${carId} - ${error.message}`)
    }
    
    // 添加间隔（与 CarManagement.vue 保持一致）
    if (i < arrivedCars.length - 1) {
      await new Promise(resolve => setTimeout(resolve, 300))
    }
  }
  
  console.log(`🎁 [${tokenId}] 收获完成：成功 ${claimSuccessCount}, 失败 ${arrivedCars.length - claimSuccessCount}`)
}

// 如果有收获成功的车辆，重新查询车辆列表（与 CarManagement.vue 保持一致）
if (claimSuccessCount > 0) {
  console.log(`🔄 [${tokenId}] 收获成功，等待1秒后重新查询车辆状态...`)
  await new Promise(resolve => setTimeout(resolve, 1000))
  const { carDataMap: newCarDataMap } = await queryClubCars()
  Object.assign(carDataMap, newCarDataMap)
}
```

**关键改进**:
1. **提前筛选**: 只遍历 `state === 2` 的车辆，而不是所有车辆
2. **减少等待**: 收获后只等待 1 秒，而不是 3 秒
3. **条件查询**: 只有当收获成功时才重新查询，而不是无条件查询
4. **移除手动状态修改**: 不再手动修改 `carInfo.claimAt` 和 `carInfo.sendAt`，而是依赖服务器返回的最新状态

---

### 4. 简化批量发送逻辑

**旧逻辑**:
```javascript
// 找到待发车的车辆
const readyToSendCars = carIds.filter(carId => getCarState(carDataMap[carId]) === 0)
const carsToSend = readyToSendCars.slice(0, currentRemainingSendCount)

console.log(`🚀 [${tokenId}] 待发车: ${readyToSendCars.length}辆，剩余额度: ${currentRemainingSendCount}个，将发送: ${carsToSend.length}辆`)

for (const carId of carsToSend) {
  try {
    await tokenStore.sendMessageAsync(tokenId, 'car_send', {
      carId: carId,
      helperId: 0,
      text: ""
    }, 5000)
    sendSuccessCount++
    console.log(`✅ [${tokenId}] 发送车辆成功: ${carId}`)
    
    // 更新发车次数
    const newCount = dailySendCount + sendSuccessCount
    localStorage.setItem(dailySendKey, newCount.toString())
    
    if (newCount >= 4) {
      console.log(`✅ [${tokenId}] 今日发车次数已达上限，停止发送`)
      break
    }
  } catch (error) {
    // 错误处理...
  }
  
  await new Promise(resolve => setTimeout(resolve, 300))
}
```

**新逻辑**（与游戏模块保持一致）:
```javascript
// 筛选待发车的车辆（state: 0）
const readyToSendCars = carIds.filter(carId => getCarState(carDataMap[carId]) === 0)
const currentShippingCars = carIds.filter(carId => getCarState(carDataMap[carId]) === 1)

// 计算剩余可发车次数
const remainingSendCount = 4 - dailySendCount
console.log(`📊 [${tokenId}] 今日已发${dailySendCount}辆，剩余可发${remainingSendCount}辆`)

if (readyToSendCars.length === 0) {
  if (claimSuccessCount === 0 && currentShippingCars.length > 0) {
    console.log(`⚠️ [${tokenId}] 所有车辆都在运输中`)
  } else if (claimSuccessCount === 0) {
    console.log(`⚠️ [${tokenId}] 没有可操作的车辆`)
  } else {
    console.log(`⚠️ [${tokenId}] 没有待发车的车辆`)
  }
} else {
  console.log(`🚀 [${tokenId}] 找到 ${readyToSendCars.length} 辆待发车的车辆`)
  
  // 如果待发车数量大于剩余可发数量，显示提示
  if (readyToSendCars.length > remainingSendCount) {
    console.log(`⚠️ [${tokenId}] 待发车${readyToSendCars.length}辆，但今日仅剩${remainingSendCount}个发车名额`)
  }
  
  // 限制发送数量不超过剩余可发次数
  const carsToSend = readyToSendCars.slice(0, remainingSendCount)
  
  for (let i = 0; i < carsToSend.length; i++) {
    const carId = carsToSend[i]
    console.log(`🚀 [${tokenId}] 发送进度: ${i + 1}/${carsToSend.length}（今日已发${dailySendCount}/4）`)
    
    try {
      await tokenStore.sendMessageAsync(tokenId, 'car_send', {
        carId: carId,
        helperId: 0,
        text: ""
      }, 5000)
      sendSuccessCount++
      console.log(`✅ [${tokenId}] 发送车辆成功: ${carId}`)
      
      // 发送成功后，增加今日发车次数（与 CarManagement.vue 保持一致）
      dailySendCount++
      localStorage.setItem(dailySendKey, dailySendCount.toString())
      
      // 发送成功后检查是否达到上限
      if (dailySendCount >= 4) {
        console.log(`✅ [${tokenId}] 今日发车次数已达上限，停止继续发送`)
        break
      }
    } catch (error) {
      const errorMsg = error.message || String(error)
      
      // 区分不同的错误类型
      if (errorMsg.includes('12000050')) {
        console.log(`⚠️ [${tokenId}] 车辆 ${carId} 发送失败: 今日发车次数已达上限（服务器端限制）`)
        // 服务器返回已达上限，更新客户端记录
        localStorage.setItem(dailySendKey, '4')
        dailySendCount = 4
        break
      } else if (errorMsg.includes('200020')) {
        console.log(`⚠️ [${tokenId}] 车辆 ${carId} 处于发送冷却期`)
      } else {
        console.error(`❌ [${tokenId}] 发送车辆失败: ${carId} - ${errorMsg}`)
      }
    }
    
    // 添加间隔（与 CarManagement.vue 保持一致）
    if (i < carsToSend.length - 1) {
      await new Promise(resolve => setTimeout(resolve, 300))
    }
  }
}
```

**关键改进**:
1. **增强边界检查**: 明确区分"所有车辆都在运输中"和"没有可操作的车辆"
2. **实时计数更新**: 每次发送成功后立即更新 `dailySendCount`，而不是事后累加
3. **更精确的日志**: 显示当前已发次数，便于调试

---

### 5. 新增 `queryClubCars` 辅助函数

为了便于多次查询车辆，新增了一个独立的 `queryClubCars` 辅助函数：

```javascript
// 辅助函数：查询车辆（与 CarManagement.vue 保持一致）
const queryClubCars = async () => {
  console.log(`🚗 [${tokenId}] 开始查询俱乐部车辆...`)
  try {
    const response = await tokenStore.sendMessageAsync(tokenId, 'car_getrolecar', {}, 10000)
    
    if (!response || !response.roleCar) {
      throw new Error('查询车辆失败：未返回车辆数据')
    }
    
    const carDataMap = response.roleCar.carDataMap || {}
    const carIds = Object.keys(carDataMap).sort() // 按ID排序
    
    return { carDataMap, carIds }
  } catch (error) {
    // 检查是否是 200400 错误（账号未加入俱乐部）
    if (error.message && error.message.includes('200400')) {
      throw new Error('该账号未加入俱乐部或没有赛车权限')
    }
    throw error
  }
}
```

**使用场景**:
1. 初始查询车辆
2. 刷新后重新查询车辆
3. 收获后重新查询车辆

---

## 新的执行流程

### 整体流程（与游戏模块保持一致）

```
第1步：查询车辆
  ├─ 使用 tokenStore.sendMessageAsync(tokenId, 'car_getrolecar', {}, 10000)
  ├─ 获取 carDataMap 和 carIds
  └─ 读取客户端的 dailySendCount

第2步：批量刷新（可选，根据 carRefreshCount 配置）
  ├─ 遍历所有车辆
  ├─ 跳过有刷新票的车辆
  ├─ 调用 car_refresh (5000ms 超时)
  ├─ 每次刷新间隔 300ms
  └─ 刷新后等待 500ms，重新查询车辆

第3步：一键发车
  │
  ├─ 3.1: 批量收获已到达的车辆（state: 2）
  │   ├─ 筛选 arrivedCars (state === 2)
  │   ├─ 遍历 arrivedCars，调用 car_claim (5000ms 超时)
  │   ├─ 每次收获间隔 300ms
  │   └─ 如果有收获成功，等待 1 秒，重新查询车辆
  │
  └─ 3.2: 批量发送待发车的车辆（state: 0）
      ├─ 重新读取客户端的 dailySendCount
      ├─ 检查每日发车次数限制（dailySendCount >= 4）
      ├─ 筛选 readyToSendCars (state === 0)
      ├─ 限制发送数量 = min(readyToSendCars.length, 4 - dailySendCount)
      ├─ 遍历 carsToSend，调用 car_send (5000ms 超时)
      ├─ 每次发送成功后，立即更新 dailySendCount
      ├─ 每次发送间隔 300ms
      └─ 达到上限（dailySendCount >= 4）后立即停止
```

---

## 性能对比

### 旧流程（v3.10.3）

```
1. 获取角色信息（激活账号）: 5秒（超时） + 1秒（等待） = 6秒
2. 查询车辆: 20秒（超时）
3. 批量刷新（假设1轮，4辆车）: 4 × 5秒（超时） + 3 × 0.3秒（间隔） = 20.9秒
4. 刷新后查询: 20秒（超时） + 0.5秒（等待） = 20.5秒
5. 批量收获（假设2辆已到达）: 2 × 5秒（超时） + 1 × 0.3秒（间隔） = 10.3秒
6. 等待同步: 3秒
7. 收获后查询: 20秒（超时）
8. 批量发送（假设4辆待发车）: 4 × 5秒（超时） + 3 × 0.3秒（间隔） = 20.9秒

总计（最坏情况，全部超时）: 6 + 20 + 20.9 + 20.5 + 10.3 + 3 + 20 + 20.9 = 121.6秒
总计（正常情况，无超时）: 6 + 1 + 20.9 + 1 + 1 + 3 + 1 + 1 = 34.9秒
```

### 新流程（v3.11.0）

```
1. 查询车辆: 10秒（超时）
2. 批量刷新（假设1轮，4辆车）: 4 × 5秒（超时） + 3 × 0.3秒（间隔） = 20.9秒
3. 刷新后查询: 10秒（超时） + 0.5秒（等待） = 10.5秒
4. 批量收获（假设2辆已到达）: 2 × 5秒（超时） + 1 × 0.3秒（间隔） = 10.3秒
5. 收获后查询: 10秒（超时） + 1秒（等待） = 11秒
6. 批量发送（假设4辆待发车）: 4 × 5秒（超时） + 3 × 0.3秒（间隔） = 20.9秒

总计（最坏情况，全部超时）: 10 + 20.9 + 10.5 + 10.3 + 11 + 20.9 = 83.6秒
总计（正常情况，无超时）: 1 + 20.9 + 1 + 1 + 2 + 1 = 27.9秒
```

**性能提升**:
- 最坏情况（全部超时）: 从 121.6秒 降低到 83.6秒，**节省 31.3%**
- 正常情况（无超时）: 从 34.9秒 降低到 27.9秒，**节省 20.1%**

---

## 影响范围

### 修改的文件
1. `src/stores/batchTaskStore.js` - 批量任务核心逻辑（sendCar case 完全重写）

### 影响的功能
1. **批量自动化 - sendCar 任务**: 
   - 执行流程简化
   - 超时时间调整
   - 日志更详细

### 不受影响的功能
1. **游戏功能模块 - CarManagement.vue**: 无任何修改
2. **其他批量自动化任务**: dailyFix, legionSignIn, autoStudy, claimHangupReward, addClock, climbTower - 均不受影响

---

## 测试建议

### 测试场景 1：所有车辆都在运输中

**预期行为**:
- 查询车辆成功
- 收获阶段：0 辆已到达，跳过收获
- 发送阶段：0 辆待发车，提示"所有车辆都在运输中"

**预期日志**:
```
🚗 [token_xxx] 开始查询俱乐部车辆...
✅ [token_xxx] 查询到 4 辆车（今日已发车: 0/4）
🎯 [token_xxx] 开始一键发车（收获 + 发送）...
🎁 [token_xxx] 第1步：批量收获已到达的车辆
⚠️ [token_xxx] 没有已到达的车辆可以收获
⚠️ [token_xxx] 4辆车正在运输中
🚀 [token_xxx] 第2步：批量发送待发车的车辆
⚠️ [token_xxx] 所有车辆都在运输中
```

---

### 测试场景 2：有2辆已到达，2辆待发车

**预期行为**:
- 查询车辆成功
- 收获阶段：成功收获 2 辆
- 等待 1 秒，重新查询车辆
- 发送阶段：找到 4 辆待发车，成功发送 4 辆

**预期日志**:
```
🚗 [token_xxx] 开始查询俱乐部车辆...
✅ [token_xxx] 查询到 4 辆车（今日已发车: 0/4）
🎯 [token_xxx] 开始一键发车（收获 + 发送）...
🎁 [token_xxx] 第1步：批量收获已到达的车辆
🎁 [token_xxx] 找到 2 辆已到达的车辆
🎁 [token_xxx] 收获进度: 1/2
✅ [token_xxx] 收获车辆成功: car_id_1
🎁 [token_xxx] 收获进度: 2/2
✅ [token_xxx] 收获车辆成功: car_id_2
🎁 [token_xxx] 收获完成：成功 2, 失败 0
🔄 [token_xxx] 收获成功，等待1秒后重新查询车辆状态...
🚗 [token_xxx] 开始查询俱乐部车辆...
🚀 [token_xxx] 第2步：批量发送待发车的车辆
📊 [token_xxx] 今日已发0辆，剩余可发4辆
🚀 [token_xxx] 找到 4 辆待发车的车辆
🚀 [token_xxx] 发送进度: 1/4（今日已发0/4）
✅ [token_xxx] 发送车辆成功: car_id_1
🚀 [token_xxx] 发送进度: 2/4（今日已发1/4）
✅ [token_xxx] 发送车辆成功: car_id_2
🚀 [token_xxx] 发送进度: 3/4（今日已发2/4）
✅ [token_xxx] 发送车辆成功: car_id_3
🚀 [token_xxx] 发送进度: 4/4（今日已发3/4）
✅ [token_xxx] 发送车辆成功: car_id_4
✅ [token_xxx] 今日发车次数已达上限，停止继续发送
🚀 [token_xxx] 发送完成：成功4次，跳过0次
```

---

### 测试场景 3：账号未加入俱乐部（错误 200400）

**预期行为**:
- 查询车辆失败，抛出友好错误："该账号未加入俱乐部或没有赛车权限"
- 任务标记为失败

**预期日志**:
```
🚗 [token_xxx] 开始查询俱乐部车辆...
❌ [token_xxx] 发车任务失败: Error: 该账号未加入俱乐部或没有赛车权限
```

---

### 测试场景 4：今日已发车4次

**预期行为**:
- 查询车辆成功
- 收获阶段：成功收获 N 辆
- 发送阶段：检测到 `dailySendCount >= 4`，跳过发送

**预期日志**:
```
🚗 [token_xxx] 开始查询俱乐部车辆...
✅ [token_xxx] 查询到 4 辆车（今日已发车: 4/4）
🎯 [token_xxx] 开始一键发车（收获 + 发送）...
🎁 [token_xxx] 第1步：批量收获已到达的车辆
...（收获流程）...
🚀 [token_xxx] 第2步：批量发送待发车的车辆
⚠️ [token_xxx] 今日发车次数已达上限: 4/4，跳过发送步骤
```

---

## 注意事项

### 1. 游戏模块逻辑的准确移植

本次重构的核心原则是**完全复用游戏模块的逻辑**，包括：
- 超时时间（10000ms for query, 5000ms for refresh/claim/send）
- 操作间隔（300ms）
- 等待时间（刷新后 500ms，收获后 1000ms）
- 状态判断（getCarState 函数）
- 错误处理（200400, 200020, 12000050）

任何后续修改都应**优先在游戏模块中测试**，验证成功后再同步到批量自动化。

### 2. 服务器 `sendCount` 字段不可靠

从 v3.10.1 开始，我们已经知道服务器的 `roleCar.sendCount` 字段不可靠（总是返回 0）。因此，批量自动化和游戏模块都**不再同步服务器的 sendCount**，而是：
1. 客户端维护 `dailySendCount` 在 `localStorage` 中
2. 每次发送成功后，立即增加 `dailySendCount`
3. 如果服务器返回 `12000050` 错误（今日发车次数已达上限），则将 `dailySendCount` 设置为 4

### 3. 并发控制

当前批量自动化的默认并发数为 1（`maxConcurrency = 1`），这是为了：
- 避免服务器反批量检测
- 减少超时和错误发生的概率

如果用户增加并发数（如 3-6），可能会遇到：
- `car_getrolecar` 超时（即使是 10000ms）
- 错误 200400（账号未加入俱乐部）

这些错误**不是客户端代码的问题**，而是服务器端的限制或账号状态问题。

### 4. 日志的重要性

本次重构增强了日志输出，包括：
- 每一步的进度（`收获进度: 1/2`，`发送进度: 3/4`）
- 每辆车的 ID 和操作结果
- 今日已发车次数的实时更新

这些日志对于调试和用户反馈非常重要，**请不要删除或简化这些日志**。

---

## 总结

本次重构（v3.11.0）彻底简化了批量自动化的发车逻辑，通过**直接复用游戏功能模块的已验证逻辑**，实现了：

✅ **代码复用**: 批量自动化和游戏模块的行为完全一致  
✅ **流程简化**: 移除不必要的"激活账号"步骤和过长的等待时间  
✅ **性能提升**: 正常情况下节省 20.1% 时间，最坏情况节省 31.3% 时间  
✅ **更稳定**: 减少了超时和错误的可能性  
✅ **更易维护**: 逻辑清晰，日志详细，易于调试  

如果后续仍有问题，建议：
1. 先在游戏功能模块（单个 token）中测试，确认问题是否也存在
2. 如果游戏模块正常，批量自动化异常，则是并发或状态管理问题
3. 如果游戏模块也异常，则是服务器端或账号状态问题

---

**版本标识**: v3.11.0  
**后续优化方向**:
1. 在批量自动化执行前，预先检查账号的俱乐部状态，跳过未加入俱乐部的账号
2. 根据实际测试情况，动态调整并发数和超时时间
3. 考虑在游戏模块中添加"批量自动化模式"，使用更保守的配置（更长的超时，更多的等待）