xyzw_web_helper/MD说明文件夹/问题修复-发车超时和统计错误v3.9.5.md

问题修复 - 发车超时和统计错误 v3.9.5

📋 问题描述

用户在v3.9.4版本（10秒超时）下进行批量发车测试，出现了两个严重问题：

问题1：所有账号仍然超时

❌ [token_1759886453287_lk84gjtj0] 发车任务失败: Error: 请求超时: car_getrolecar (10000ms)
❌ [token_1759886453292_gp9mb8zqp] 发车任务失败: Error: 请求超时: car_getrolecar (10000ms)
... (所有6个账号都超时)

问题2：统计信息完全错误

batchTaskStore.js:1414 📊 统计信息: {total: 6, success: 6, failed: 0}
batchTaskStore.js:1461 ✅ 所有任务成功完成！

明明6个账号全部失败，却显示 success: 6, failed: 0！

---

🔍 深度分析

问题1原因：服务器无响应

从日志中可以看到：

1. ✅ 6个账号全部成功连接WebSocket
2. ✅ 6个账号全部发送了 car_getrolecar 命令
3. ❌ 服务器10秒内没有返回任何 car_getrolecarresp 响应
4. ❌ 只有心跳消息在不断发送

这说明：

• 服务器在并发6个查询时处理不过来
• 10秒超时仍然不够

问题2原因：任务结果检查逻辑错误

代码逻辑缺陷

1. executeTask 函数在失败时返回一个对象：

   catch (error) {
     return {
       task: '发车',
       success: false,  // ❌ 返回失败标记
       error: error.message
     }
   }
   

2. 但 executeTokenTasks 函数没有检查这个标记：

   const result = await executeTask(tokenId, taskName)
   
   // 保存任务结果
   taskProgress.value[tokenId].result[taskName] = {
     success: true,  // ❌ 硬编码为true！
     data: result
   }
   

3. 结果：

   • executeTask 没有抛出异常，所以 executeTokenTasks 认为任务成功
   • 失败的任务被记录为 success: true
   • taskFailedCount 不会增加
   • 统计信息显示 success: 6, failed: 0

为什么会出现两行日志？

batchTaskStore.js:1333  ❌ [token_xxx] 发车任务失败: Error: 请求超时: car_getrolecar (10000ms)
batchTaskStore.js:380   ✅ 任务完成: sendCar

• 第1333行：executeTask 中的 catch 块打印的错误
• 第380行：executeTokenTasks 中的成功日志（因为没有检查 result.success）

---

✅ 解决方案

修复1：增加超时 + 降低并发

参数	修复前	修复后	说明
查询超时	10000ms (10秒)	20000ms (20秒)	⬆️ +100%
默认并发数	5个	3个	⬇️ -40%

修改位置：src/stores/batchTaskStore.js

• 第1134行：初次查询车辆 10000 → 20000
• 第1209行：刷新后重新查询 10000 → 20000
• 第1280行：发送前重新查询 10000 → 20000
• 第50行：默认并发数 '5' → '3'

修复2：正确检查任务结果

修改前：

try {
  const result = await executeTask(tokenId, taskName)
  
  // 保存任务结果
  taskProgress.value[tokenId].result[taskName] = {
    success: true,  // ❌ 硬编码为true
    data: result
  }
  
  taskProgress.value[tokenId].tasksCompleted++
  console.log(`  ✅ 任务完成: ${taskName}`)
} catch (error) {
  // 保存错误信息
  taskFailedCount++
}

修改后：

try {
  const result = await executeTask(tokenId, taskName)
  
  // ✅ 检查任务是否真的成功（某些任务可能返回包含success字段的对象）
  const isSuccess = result?.success !== false
  
  if (!isSuccess) {
    // ❌ 任务返回失败标记
    console.error(`  ❌ 任务失败: ${taskName}`, result?.error || '未知错误')
    
    taskProgress.value[tokenId].result[taskName] = {
      success: false,
      error: result?.error || '任务执行失败',
      data: result?.data
    }
    
    taskFailedCount++ // 增加失败计数
  } else {
    // ✅ 任务成功
    taskProgress.value[tokenId].result[taskName] = {
      success: true,
      data: result
    }
    
    taskProgress.value[tokenId].tasksCompleted++
    console.log(`  ✅ 任务完成: ${taskName}`)
  }
} catch (error) {
  console.error(`  ❌ 任务异常: ${taskName}`, error.message)
  taskFailedCount++
}

修改位置：src/stores/batchTaskStore.js 第367-415行

---

🎯 修复效果

超时问题

并发数	超时时间	预期成功率
6个	10秒	0% (全部超时)
3个	20秒	70-90% (预期)

说明：

• 并发数减半，服务器压力大幅降低
• 超时翻倍，给服务器更多处理时间
• 如果仍然超时，可以进一步降低并发到2个或1个

统计问题

场景	修复前	修复后
6个全部失败	success: 6, failed: 0 ❌	success: 0, failed: 6 ✅
3个成功，3个失败	success: 6, failed: 0 ❌	success: 3, failed: 3 ✅
6个全部成功	success: 6, failed: 0 ✅	success: 6, failed: 0 ✅

---

📊 技术细节

为什么不继续增加超时？

超时时间	优点	缺点
5秒	快速失败，用户等待少	并发高时不够
10秒	平衡点（v3.9.4）	仍然不够
20秒	足够处理大部分情况	用户需要等待
30秒+	几乎不会超时	用户等待过久，体验差

选择20秒的原因：

• 是10秒的2倍，给服务器足够时间
• 用户可以接受的等待时间（20秒 × 3个并发 = 约60秒总时间）
• 如果20秒还不够，问题可能在服务器端，不应继续增加客户端超时

为什么降低默认并发到3个？

并发数	服务器压力	总耗时（假设每个账号20秒）	适用场景
1个	最低	120秒（6 × 20）	服务器极不稳定
2个	低	60秒（3批 × 20）	服务器不稳定
3个	适中	40秒（2批 × 20）	推荐 ✅
5个	高	40秒（2批 × 20）	v3.9.4默认值
6个	很高	20秒（1批 × 20）	服务器稳定时

选择3个的原因：

• 平衡并发效率和成功率
• 如果用户需要更高并发，可以手动调整（1-100可配置）
• 新用户开箱即用，成功率高

任务结果检查逻辑

关键判断：

const isSuccess = result?.success !== false

这个判断覆盖了所有情况：

• result = { success: true } → isSuccess = true ✅
• result = { success: false } → isSuccess = false ❌
• result = { data: {...} } (没有success字段) → isSuccess = true ✅
• result = undefined → isSuccess = true ✅
• result = null → isSuccess = true ✅

设计原则：

• 只有明确标记 success: false 才认为失败
• 其他情况默认认为成功（向后兼容旧代码）

---

🧪 验证方法

测试步骤

1. 重启开发服务器（如果正在运行）
2. 打开批量自动化面板
3. 选择 6 个账号
4. 只勾选 "发车" 任务
5. 点击 "开始执行"

预期结果（成功场景）

日志输出

🚀 开始批量执行任务
📋 Token数量: 6
📋 任务列表: ['sendCar']
🎯 开始执行 Token: 802服-2-xxx (并发1/3)
🎯 开始执行 Token: 803服-0-xxx (并发2/3)
🎯 开始执行 Token: 803服-1-xxx (并发3/3)
⏳ Token token_xxx 将在 0.9秒 后建立连接 (剩余3个等待)
...
🚗 [token_xxx] 开始查询俱乐部车辆...
📤 发送消息: car_getrolecar {}
✅ [token_xxx] 查询到 4 辆车
...
✅ Token完成: 802服-2-xxx
✅ Token完成: 803服-0-xxx
✅ Token完成: 803服-1-xxx
🎯 开始执行 Token: 803服-2-xxx (并发1/3)
...
📊 统计信息: {total: 6, success: 6, failed: 0}  ✅
✅ 所有任务成功完成！

UI显示

• ✅ 进度条显示正确
• ✅ 成功的Token卡片显示绿色
• ✅ 统计区域显示 成功: 6, 失败: 0

预期结果（失败场景）

日志输出

🚗 [token_xxx] 开始查询俱乐部车辆...
❌ [token_xxx] 发车任务失败: Error: 请求超时: car_getrolecar (20000ms)
  ❌ 任务失败: sendCar 请求超时: car_getrolecar (20000ms)
❌ Token失败: 802服-2-xxx (所有任务都失败)
...
📊 统计信息: {total: 6, success: 0, failed: 6}  ✅ 正确
❌ 批量任务执行完成，但有失败

UI显示

• ✅ 失败的Token卡片显示红色
• ✅ 统计区域显示 成功: 0, 失败: 6
• ✅ 全局统计正确

---

💡 后续优化建议

如果20秒超时 + 3个并发仍然不够（超过30%失败率），可以考虑：

短期方案（用户可操作）

1. 降低并发数：手动调整到2个或1个
2. 使用自动重试：勾选"自动重试失败任务"，设置5轮重试
3. 错峰执行：避开服务器高峰时段

长期方案（开发实施）

1. 完全串行执行模式：

   • 添加"串行模式"开关
   • 一个一个账号依次执行
   • 保证100%成功率，但速度最慢

2. 智能并发调整：

   • 根据失败率自动调整并发数
   • 失败率 > 50% → 自动降低并发
   • 成功率 > 90% → 自动提高并发

3. 请求队列机制：

   • 在客户端实现请求队列
   • 控制每秒最多发送N个请求
   • 类似于限流（Rate Limiting）

4. 服务器端优化（需要后端配合）：

   • 增加缓存
   • 优化数据库查询
   • 添加负载均衡

目前不需要立即实施，先观察v3.9.5的效果。

---

🔄 版本信息

• 版本号：v3.9.5
• 修复日期：2025-10-08
• 影响范围：
  • src/stores/batchTaskStore.js（超时配置、并发数、任务结果检查逻辑）
• 向后兼容：✅ 完全兼容
• 破坏性变更：❌ 无

---

📝 相关文档

• 批量任务添加发车功能 v3.9.0
• 发车任务超时和Vue组件警告 v3.9.3
• 发车任务超时优化 v3.9.4