Files
xyzw_web_helper/MD说明文件夹/功能优化-发车任务最终验证v3.11.3.md
2025-10-17 20:56:50 +08:00

7.5 KiB
Raw Permalink Blame History

功能优化:发车任务最终验证 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.jssendCar 任务中,在批量发送完成后添加:

// 第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 的变化:

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辆运输中可以添加告警