xyzw_web_helper/MD说明文件夹/问题修复-发车任务超时和Vue组件警告v3.9.3.md

问题修复-发车任务超时和Vue组件警告 v3.9.3

📋 问题描述

用户报告在执行批量发车任务时遇到两个问题：

问题1：Vue 组件警告

[Vue warn]: Failed to resolve component: n-statistic-group
If this is a native custom element, make sure to exclude it from component resolution via compilerOptions.isCustomElement.

问题2：发车任务全部超时失败

❌ [token_xxx] 发车任务失败: Error: 请求超时: car_getrolecar (1500ms)

所有6个账号的发车任务都因为请求超时而失败。

🔍 问题分析

问题1：n-statistic-group 组件不存在

原因：

• TaskProgressCard.vue 中使用了 <n-statistic-group> 组件
• Naive UI 中没有 n-statistic-group 这个组件
• 应该使用 n-space 或其他布局组件来包裹多个 n-statistic 组件

错误代码：

<n-statistic-group>
  <n-statistic label="总任务数" :value="..." />
  <n-statistic label="成功" :value="..." />
  <n-statistic label="失败" :value="..." />
</n-statistic-group>

问题2：WebSocket 请求超时时间过短

原因分析：

从用户提供的日志中可以看到：

🚗 [token_xxx] 开始查询俱乐部车辆...
📤 发送消息: car_getrolecar {}
❌ [token_xxx] 发车任务失败: Error: 请求超时: car_getrolecar (1500ms)

问题点：

1. 超时时间太短：car_getrolecar 请求超时设置为1500ms（1.5秒）
2. 批量请求压力：6个账号同时发送请求，服务器可能响应较慢
3. 网络延迟：实际网络延迟 + 服务器处理时间可能超过1.5秒
4. WebSocket 消息队列：多个并发请求可能导致消息处理延迟

超时位置： 在 batchTaskStore.js 的 sendCar 任务中，有多处调用WebSocket命令，超时时间都设置为1500ms：

命令	调用次数	原超时时间	问题
car_getrolecar	3次	1500ms	查询车辆信息
car_refresh	1次	1500ms	刷新车辆
car_claim	1次	1500ms	收获车辆
car_send	1次	1500ms	发送车辆

✅ 解决方案

修复1：替换不存在的组件

修改文件：src/components/TaskProgressCard.vue

修复前：

<n-statistic-group>
  <n-statistic label="总任务数" :value="Object.keys(taskResults).length" />
  <n-statistic label="成功" :value="successCount" class="success" />
  <n-statistic label="失败" :value="failedCount" class="failed" />
</n-statistic-group>

修复后：

<n-space justify="space-around">
  <n-statistic label="总任务数" :value="Object.keys(taskResults).length" />
  <n-statistic label="成功" :value="successCount" class="success" />
  <n-statistic label="失败" :value="failedCount" class="failed" />
</n-space>

说明：

• 使用 n-space 替代不存在的 n-statistic-group
• 设置 justify="space-around" 使统计项均匀分布
• 保持原有的样式和功能

修复2：增加 WebSocket 请求超时时间

修改文件：src/stores/batchTaskStore.js

2.1 增加 car_getrolecar 超时时间（5000ms）

原因：查询车辆是最频繁的操作，需要更长的超时时间

修改位置：

1. 第1134行：初始查询车辆

// 修改前
const queryResponse = await client.sendWithPromise('car_getrolecar', {}, 1500)

// 修改后
const queryResponse = await client.sendWithPromise('car_getrolecar', {}, 5000)

2. 第1209行：刷新后重新查询车辆

// 修改前
const reQueryResponse = await client.sendWithPromise('car_getrolecar', {}, 1500)

// 修改后
const reQueryResponse = await client.sendWithPromise('car_getrolecar', {}, 5000)

3. 第1280行：发送前重新查询车辆

// 修改前
const finalQueryResponse = await client.sendWithPromise('car_getrolecar', {}, 1500)

// 修改后
const finalQueryResponse = await client.sendWithPromise('car_getrolecar', {}, 5000)

2.2 增加 car_refresh 超时时间（3000ms）

第1182行：

// 修改前
await client.sendWithPromise('car_refresh', { carId: carId }, 1500)

// 修改后
await client.sendWithPromise('car_refresh', { carId: carId }, 3000)

2.3 增加 car_claim 超时时间（3000ms）

第1250行：

// 修改前
await client.sendWithPromise('car_claim', { carId: carId }, 1500)

// 修改后
await client.sendWithPromise('car_claim', { carId: carId }, 3000)

2.4 增加 car_send 超时时间（3000ms）

第1293-1297行：

// 修改前
await client.sendWithPromise('car_send', {
  carId: carId,
  helperId: 0,
  text: ""
}, 1500)

// 修改后
await client.sendWithPromise('car_send', {
  carId: carId,
  helperId: 0,
  text: ""
}, 3000)

📊 超时时间对比

操作	原超时时间	新超时时间	增加比例	说明
car_getrolecar	1500ms	5000ms	+233%	查询操作，数据量大，需要更多时间
car_refresh	1500ms	3000ms	+100%	刷新操作，服务器处理时间较长
car_claim	1500ms	3000ms	+100%	收获操作，需要更新数据库
car_send	1500ms	3000ms	+100%	发送操作，需要更新数据库

🎯 超时时间设计原则

为什么 car_getrolecar 设置为 5000ms？

1. 数据量大：查询所有车辆信息，包括车辆状态、奖励、刷新票等
2. 频繁调用：在一个发车任务中可能调用3次
3. 批量请求：多个账号同时查询时，服务器压力大
4. 容错性：5秒的超时时间提供了足够的容错空间

为什么其他命令设置为 3000ms？

1. 单车操作：每次只操作一辆车，数据量较小
2. 顺序执行：有延迟间隔，不会并发过多
3. 快速响应：服务器处理单车操作相对较快
4. 平衡性：3秒既保证成功率，又不会拖慢整体执行速度

🔄 修复效果

修复前

🚗 开始批量执行任务
📋 Token数量: 6
📋 任务列表: ['sendCar']

❌ [token_1] 发车任务失败: Error: 请求超时: car_getrolecar (1500ms)
❌ [token_2] 发车任务失败: Error: 请求超时: car_getrolecar (1500ms)
❌ [token_3] 发车任务失败: Error: 请求超时: car_getrolecar (1500ms)
❌ [token_4] 发车任务失败: Error: 请求超时: car_getrolecar (1500ms)
❌ [token_5] 发车任务失败: Error: 请求超时: car_getrolecar (1500ms)
❌ [token_6] 发车任务失败: Error: 请求超时: car_getrolecar (1500ms)

📊 统计信息: 成功 0, 失败 6

修复后（预期）

🚗 开始批量执行任务
📋 Token数量: 6
📋 任务列表: ['sendCar']

✅ [token_1] 发车任务完成
✅ [token_2] 发车任务完成
✅ [token_3] 发车任务完成
✅ [token_4] 发车任务完成
✅ [token_5] 发车任务完成
✅ [token_6] 发车任务完成

📊 统计信息: 成功 6, 失败 0

📝 相关文件

修改的文件

1. src/components/TaskProgressCard.vue（第348-363行）

   • 将 <n-statistic-group> 替换为 <n-space justify="space-around">

2. src/stores/batchTaskStore.js

   • 第1134行：car_getrolecar 超时 1500ms → 5000ms
   • 第1182行：car_refresh 超时 1500ms → 3000ms
   • 第1209行：car_getrolecar 超时 1500ms → 5000ms
   • 第1250行：car_claim 超时 1500ms → 3000ms
   • 第1280行：car_getrolecar 超时 1500ms → 5000ms
   • 第1293-1297行：car_send 超时 1500ms → 3000ms

新增文件

• MD说明/问题修复-发车任务超时和Vue组件警告v3.9.3.md

🧪 测试验证

测试1：Vue 组件警告消失

1. 刷新页面（Ctrl + F5）
2. 打开浏览器控制台
3. 执行批量任务
4. 预期结果：
   • 不再出现 Failed to resolve component: n-statistic-group 警告 ✓
   • 统计信息正常显示 ✓

测试2：发车任务成功率提升

1. 设置并发数为6
2. 选择"发车"任务
3. 执行批量任务
4. 预期结果：
   • 所有账号的发车任务成功完成 ✓
   • 不再出现超时错误 ✓
   • 发车状态正确显示 ✓

测试3：高并发场景

1. 设置并发数为20
2. 选择"发车"任务
3. 执行批量任务
4. 预期结果：
   • 大部分账号成功完成 ✓
   • 超时率显著降低 ✓

💡 优化建议

如果仍然遇到超时问题

方案1：进一步增加超时时间

// car_getrolecar 增加到 8000ms
const queryResponse = await client.sendWithPromise('car_getrolecar', {}, 8000)

// 其他命令增加到 5000ms
await client.sendWithPromise('car_refresh', { carId: carId }, 5000)

方案2：降低并发数

• 从并发6个降低到并发3个
• 减少同时发送请求的账号数量
• 降低服务器压力

方案3：增加重试机制

当前已有自动重试机制：

• 在批量任务面板中启用"自动重试失败任务"
• 设置最大重试轮数为5轮
• 设置重试间隔为3秒

方案4：增加请求间隔

在每个请求之间增加延迟：

await new Promise(resolve => setTimeout(resolve, 500)) // 增加到1000ms

🔄 版本信息

• 版本号: v3.9.3
• 修复日期: 2025-01-08
• 修复内容:
  • 修复 Vue 组件警告（n-statistic-group 不存在）
  • 增加发车任务 WebSocket 请求超时时间
  • car_getrolecar: 1500ms → 5000ms
  • car_refresh: 1500ms → 3000ms
  • car_claim: 1500ms → 3000ms
  • car_send: 1500ms → 3000ms
• 依赖版本: v3.9.2

🐛 已知问题

如果网络极度不稳定

在网络质量极差的情况下，可能仍然会遇到超时。建议：

1. 检查网络连接
2. 降低并发数
3. 增加超时时间到8000ms以上

服务器维护期间

如果服务器正在维护或响应缓慢，所有请求都可能超时。建议：

1. 等待服务器恢复正常
2. 检查服务器状态

📈 后续计划

• 添加自适应超时时间（根据网络延迟动态调整）
• 添加请求失败时的详细错误信息
• 优化批量请求的调度策略
• 添加请求耗时统计

---

✅ 问题已修复！刷新页面（Ctrl + F5）即可看到修复效果！