342 lines
9.9 KiB
Markdown
342 lines
9.9 KiB
Markdown
# 问题修复 - 发车超时和统计错误 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` 函数在失败时**返回一个对象**：
|
||
```javascript
|
||
catch (error) {
|
||
return {
|
||
task: '发车',
|
||
success: false, // ❌ 返回失败标记
|
||
error: error.message
|
||
}
|
||
}
|
||
```
|
||
|
||
2. 但 `executeTokenTasks` 函数**没有检查这个标记**：
|
||
```javascript
|
||
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：正确检查任务结果
|
||
|
||
**修改前**：
|
||
```javascript
|
||
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++
|
||
}
|
||
```
|
||
|
||
**修改后**：
|
||
```javascript
|
||
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可配置）
|
||
- 新用户开箱即用，成功率高
|
||
|
||
### 任务结果检查逻辑
|
||
|
||
**关键判断**：
|
||
```javascript
|
||
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](./功能更新-批量任务添加发车功能v3.9.0.md)
|
||
- [发车任务超时和Vue组件警告 v3.9.3](./问题修复-发车任务超时和Vue组件警告v3.9.3.md)
|
||
- [发车任务超时优化 v3.9.4](./问题修复-发车任务超时优化v3.9.4.md)
|
||
|