186 lines
7.5 KiB
Markdown
186 lines
7.5 KiB
Markdown
# 功能优化：发车任务最终验证 v3.11.3
|
||
|
||
## 📋 更新时间
|
||
2025-10-08
|
||
|
||
## 🎯 优化目标
|
||
解决批量自动化中"发车"任务完成后，执行进度卡片可能显示不准确（如"3/4"）的问题。
|
||
|
||
## ❌ 问题描述
|
||
|
||
### 场景
|
||
用户反馈：批量自动化完成发车任务后，执行进度卡片显示"3/4"，但实际进入游戏功能模块查看时，发现是"4/4"（4辆车都在运输中）。
|
||
|
||
### 原因分析
|
||
1. **本地计数延迟**：批量发送过程中，`localStorage` 中的 `dailySendCount` 可能因为各种原因（网络延迟、异步更新等）未能及时同步
|
||
2. **服务器状态不一致**：客户端记录的发车数与服务器实际状态存在短暂的不一致
|
||
3. **缺少最终验证**：任务完成后没有再次查询服务器，直接使用本地记录
|
||
|
||
## ✅ 解决方案
|
||
|
||
### 核心思路
|
||
在发车任务的所有操作（查询、刷新、收获、发送）完成后，**增加第4步"最终验证"**：
|
||
1. 等待1秒，让服务器状态完全同步
|
||
2. 重新查询车辆状态
|
||
3. 统计实际运输中的车辆数量
|
||
4. 如果与本地记录不一致，更新 `localStorage`
|
||
5. 确保返回的发车数是准确的
|
||
|
||
### 实现步骤
|
||
|
||
#### 1. 添加最终验证逻辑
|
||
在 `src/stores/batchTaskStore.js` 的 `sendCar` 任务中，在批量发送完成后添加：
|
||
|
||
```javascript
|
||
// 第4步：最终验证 - 重新查询车辆状态，确保发车数准确
|
||
console.log(`🔍 [${tokenId}] 开始最终验证，重新查询车辆状态...`)
|
||
try {
|
||
await new Promise(resolve => setTimeout(resolve, 1000)) // 等待1秒让服务器状态同步
|
||
const { carDataMap: finalCarDataMap, carIds: finalCarIds } = await queryClubCars()
|
||
|
||
// 统计最终运输中的车辆数量
|
||
const finalCarsInTransit = finalCarIds.filter(carId => getCarState(finalCarDataMap[carId]) === 1)
|
||
|
||
console.log(`📊 [${tokenId}] 最终验证：运输中${finalCarsInTransit.length}辆车`)
|
||
|
||
// 如果运输中的车辆数量大于当前记录，更新为运输中的数量
|
||
if (finalCarsInTransit.length > dailySendCount) {
|
||
console.log(`🔄 [${tokenId}] 最终验证发现差异，更新发车次数: ${dailySendCount} → ${finalCarsInTransit.length}`)
|
||
dailySendCount = finalCarsInTransit.length
|
||
localStorage.setItem(dailySendKey, dailySendCount.toString())
|
||
}
|
||
|
||
sendCarResults.push({
|
||
task: '最终验证',
|
||
success: true,
|
||
message: `运输中${finalCarsInTransit.length}辆，今日发车${dailySendCount}/4`
|
||
})
|
||
|
||
console.log(`✅ [${tokenId}] 发车任务完成（最终验证: ${dailySendCount}/4）`)
|
||
} catch (verifyError) {
|
||
console.warn(`⚠️ [${tokenId}] 最终验证失败: ${verifyError.message}，使用当前记录: ${dailySendCount}/4`)
|
||
sendCarResults.push({
|
||
task: '最终验证',
|
||
success: false,
|
||
message: `验证失败，使用记录: ${dailySendCount}/4`
|
||
})
|
||
}
|
||
```
|
||
|
||
#### 2. 容错设计
|
||
- 使用 `try-catch` 包裹验证逻辑，确保即使验证失败也不影响整体任务成功
|
||
- 验证失败时，记录警告日志并使用当前本地记录值
|
||
- 验证结果会添加到 `sendCarResults` 中，便于追踪
|
||
|
||
#### 3. 更新触发
|
||
`TaskProgressCard.vue` 组件会通过 `watch` 监听 `props.progress?.result?.sendCar` 的变化：
|
||
```javascript
|
||
watch(
|
||
() => props.progress?.result?.sendCar,
|
||
(newValue) => {
|
||
if (newValue) {
|
||
console.log(`🔄 [${props.tokenId}] 发车任务结果更新，刷新发车次数...`)
|
||
setTimeout(() => {
|
||
refreshCarSendCount()
|
||
}, 100)
|
||
}
|
||
},
|
||
{ deep: true }
|
||
)
|
||
```
|
||
|
||
当发车任务完成并更新 `localStorage` 后，卡片会自动刷新显示最新的发车数。
|
||
|
||
## 🎉 优化效果
|
||
|
||
### 用户体验
|
||
1. ✅ **准确显示**：执行进度卡片始终显示准确的发车数（如"4/4"）
|
||
2. ✅ **实时同步**：自动同步服务器实际状态，避免客户端与服务器不一致
|
||
3. ✅ **可追溯性**：日志中包含完整的验证过程，便于调试
|
||
|
||
### 技术优势
|
||
1. ✅ **主动验证**：任务完成后主动查询服务器，而非被动等待
|
||
2. ✅ **容错能力**：验证失败不影响整体任务，降低风险
|
||
3. ✅ **可扩展性**：验证逻辑独立，易于后续优化
|
||
|
||
## 📊 日志示例
|
||
|
||
### 成功场景（发现差异并更新）
|
||
```
|
||
🚀 [token_1759891638868_c3e1sfcb9] 发送完成：成功3次，跳过0次
|
||
🔍 [token_1759891638868_c3e1sfcb9] 开始最终验证，重新查询车辆状态...
|
||
🚗 [token_1759891638868_c3e1sfcb9] 开始查询俱乐部车辆...
|
||
✅ [token_1759891638868_c3e1sfcb9] 查询到 4 辆车（今日已发车: 3/4）
|
||
📊 [token_1759891638868_c3e1sfcb9] 最终验证：运输中4辆车
|
||
🔄 [token_1759891638868_c3e1sfcb9] 最终验证发现差异，更新发车次数: 3 → 4
|
||
✅ [token_1759891638868_c3e1sfcb9] 发车任务完成（最终验证: 4/4）
|
||
```
|
||
|
||
### 成功场景（无差异）
|
||
```
|
||
🚀 [token_1759891638868_c3e1sfcb9] 发送完成：成功4次，跳过0次
|
||
🔍 [token_1759891638868_c3e1sfcb9] 开始最终验证，重新查询车辆状态...
|
||
🚗 [token_1759891638868_c3e1sfcb9] 开始查询俱乐部车辆...
|
||
✅ [token_1759891638868_c3e1sfcb9] 查询到 4 辆车（今日已发车: 4/4）
|
||
📊 [token_1759891638868_c3e1sfcb9] 最终验证：运输中4辆车
|
||
✅ [token_1759891638868_c3e1sfcb9] 发车任务完成（最终验证: 4/4）
|
||
```
|
||
|
||
### 失败场景（容错）
|
||
```
|
||
🚀 [token_1759891638868_c3e1sfcb9] 发送完成：成功3次，跳过0次
|
||
🔍 [token_1759891638868_c3e1sfcb9] 开始最终验证，重新查询车辆状态...
|
||
⚠️ [token_1759891638868_c3e1sfcb9] 最终验证失败: 请求超时: car_getrolecar (10000ms)，使用当前记录: 3/4
|
||
```
|
||
|
||
## 🧪 测试建议
|
||
|
||
### 测试场景1：正常发车
|
||
1. 运行批量自动化，选择"发车"任务
|
||
2. 观察日志，确认最终验证步骤执行
|
||
3. 检查执行进度卡片显示的发车数是否准确
|
||
4. 进入游戏功能模块的"俱乐部赛车"页面，对比实际状态
|
||
|
||
### 测试场景2：网络延迟
|
||
1. 在网络较慢的环境下运行批量自动化
|
||
2. 观察是否有"最终验证发现差异"的日志
|
||
3. 确认最终显示的发车数与服务器状态一致
|
||
|
||
### 测试场景3：验证失败
|
||
1. 模拟网络中断或超时（手动断网）
|
||
2. 观察验证失败时的容错处理
|
||
3. 确认整体任务仍然标记为成功
|
||
|
||
## 📝 相关文件
|
||
|
||
### 修改的文件
|
||
- `src/stores/batchTaskStore.js` - 发车任务逻辑，新增最终验证步骤
|
||
|
||
### 相关文件（无需修改）
|
||
- `src/components/TaskProgressCard.vue` - 执行进度卡片，已有的 `watch` 机制自动生效
|
||
- `src/components/CarManagement.vue` - 游戏功能模块的赛车管理（参考对比）
|
||
|
||
## 🔄 版本历史
|
||
|
||
### v3.11.3 (2025-10-08)
|
||
- ✨ 新增：发车任务完成后的最终验证步骤
|
||
- ✨ 新增：自动检测并同步服务器实际状态
|
||
- 🐛 修复：执行进度卡片可能显示不准确的发车数（如"3/4"实际是"4/4"）
|
||
|
||
### v3.11.2 (2025-10-08)
|
||
- 🐛 修复：游戏功能模块的赛车管理也会统计运输中的车辆
|
||
|
||
### v3.11.1 (2025-10-08)
|
||
- 🐛 修复：俱乐部签到错误码 2300190（已签到）不应视为失败
|
||
|
||
### v3.11.0 (2025-10-08)
|
||
- 🔄 重构：发车任务直接复用游戏功能模块的逻辑
|
||
|
||
## 💡 后续优化建议
|
||
|
||
1. **验证时机优化**：考虑根据网络状况动态调整验证等待时间（目前固定1秒）
|
||
2. **批量验证**：如果并发运行多个token，可以考虑批量验证以提高效率
|
||
3. **状态缓存**：考虑在短时间内复用验证结果，减少不必要的查询
|
||
4. **异常告警**：如果验证结果与预期差异过大（如发送3次但只有1辆运输中），可以添加告警
|
||
|