xyzw_web_helper/MD说明文件夹/问题修复-服务器sendCount不可靠v3.10.1.md

问题修复 - 服务器sendCount不可靠 (v3.10.1)

📋 问题发现

v3.10.0 测试结果

在v3.10.0中，我们尝试同步服务器端的 sendCount 字段，但测试发现了一个严重问题：

✅ [token_xxx] 查询到 4 辆车（今日已发车: 0/4）  ← 服务器返回 sendCount=0
📊 [token_xxx] 检查每日发车次数限制: 0/4
🚀 [token_xxx] 待发车: 4辆，剩余额度: 4个，将发送: 4辆
⚠️ [token_xxx] 车辆 xxx 发送失败: 今日发车次数已达上限（服务器端限制）
⚠️ [token_xxx] 车辆 xxx 发送失败: 今日发车次数已达上限（服务器端限制）
⚠️ [token_xxx] 车辆 xxx 发送失败: 今日发车次数已达上限（服务器端限制）
⚠️ [token_xxx] 车辆 xxx 发送失败: 今日发车次数已达上限（服务器端限制）
🚀 [token_xxx] 发送完成：成功0次，跳过0次

矛盾点

数据来源	显示的发车次数	是否准确
服务器 roleCar.sendCount	0/4	❌ 不准确
服务器实际记录（通过错误码推断）	4/4（已达上限）	✅ 准确

结论

服务器的 roleCar.sendCount 字段不可靠！

• 该字段总是返回 0，即使服务器内部已经记录了发车次数
• 真实的发车次数只能通过尝试发车时的错误码 12000050 来判断
• 我们不能依赖 sendCount 字段来同步客户端的发车次数

💡 v3.10.1 修复方案

核心思路

放弃服务器 sendCount，依靠错误码 12000050 来同步

1. 不再从服务器同步 sendCount：因为该字段不可靠
2. 保留客户端 localStorage 记录：作为主要的发车次数记录
3. 使用 12000050 错误码作为同步信号：当收到此错误时，说明服务器端实际已达上限（4次），更新客户端记录

修复内容

1. 移除服务器 sendCount 同步逻辑

修改前（v3.10.0）：

// 获取服务器端的发车次数并同步到本地
const serverSendCount = queryResponse.roleCar?.sendCount || 0
const dailySendKey = getTodayKey(tokenId)
let dailySendCount = parseInt(localStorage.getItem(dailySendKey) || '0')

// 以服务器端的值为准（服务器端更权威）
if (serverSendCount !== dailySendCount) {
  console.log(`🔄 [${tokenId}] 同步服务器发车次数: 客户端${dailySendCount} → 服务器${serverSendCount}`)
  localStorage.setItem(dailySendKey, serverSendCount.toString())
  dailySendCount = serverSendCount
}

修改后（v3.10.1）：

// 获取客户端的发车次数记录
const dailySendKey = getTodayKey(tokenId)
let dailySendCount = parseInt(localStorage.getItem(dailySendKey) || '0')

// 注意：服务器的 sendCount 字段不可靠（总是返回0），所以不同步
console.log(`✅ [${tokenId}] 查询到 ${carIds.length} 辆车（今日已发车: ${dailySendCount}/4）`)

2. 使用 12000050 错误码更新客户端记录

修改前（v3.10.0）：

catch (error) {
  const errorMsg = error.message || String(error)
  
  if (errorMsg.includes('12000050')) {
    console.log(`⚠️ [${tokenId}] 车辆 ${carId} 发送失败: 今日发车次数已达上限（服务器端限制）`)
    // 没有更新客户端记录，导致客户端和服务器端不一致
  }
  // ...
}

修改后（v3.10.1）：

catch (error) {
  const errorMsg = error.message || String(error)
  
  if (errorMsg.includes('12000050')) {
    console.log(`⚠️ [${tokenId}] 车辆 ${carId} 发送失败: 今日发车次数已达上限（服务器端限制）`)
    
    // 服务器返回已达上限，说明服务器端实际已有4次发车记录
    // 更新客户端记录以保持一致
    console.log(`🔄 [${tokenId}] 根据服务器错误码，更新客户端发车次数: ${dailySendCount} → 4`)
    localStorage.setItem(dailySendKey, '4')
    dailySendCount = 4
    
    // 已达上限，停止继续发送
    break
  }
  // ...
}

关键改进：

• 当收到 12000050 错误时，将客户端的 dailySendCount 强制设置为 4
• 使用 break 停止继续发送，避免浪费请求
• 下次运行时，客户端会提前检测到已达上限，不会再尝试发送

3. 移除其他同步逻辑

同时移除了以下位置的服务器同步代码：

• 刷新车辆后的同步（已移除）
• 发送前的同步（已移除）

📊 修复效果对比

修改前（v3.10.0）

场景：服务器端已有4次发车记录

✅ 查询到 4 辆车（今日已发车: 0/4）  ← 从服务器同步的错误值
📊 检查每日发车次数限制: 0/4
🚀 待发车: 4辆，剩余额度: 4个，将发送: 4辆
⚠️ 车辆 xxx 发送失败: 今日发车次数已达上限  ← 尝试发送，失败
⚠️ 车辆 xxx 发送失败: 今日发车次数已达上限  ← 继续尝试
⚠️ 车辆 xxx 发送失败: 今日发车次数已达上限  ← 继续尝试
⚠️ 车辆 xxx 发送失败: 今日发车次数已达上限  ← 继续尝试
🚀 发送完成：成功0次，跳过0次

客户端记录依然是 0/4（错误！）
下次运行还会继续尝试发送（浪费！）

修改后（v3.10.1）

场景：服务器端已有4次发车记录

✅ 查询到 4 辆车（今日已发车: 0/4）  ← 客户端记录（暂时不准确）
📊 检查每日发车次数限制: 0/4
🚀 待发车: 4辆，剩余额度: 4个，将发送: 4辆
⚠️ 车辆 xxx 发送失败: 今日发车次数已达上限（服务器端限制）
🔄 根据服务器错误码，更新客户端发车次数: 0 → 4  ← 立即更新！
🚀 发送完成：成功0次，跳过0次

客户端记录已更新为 4/4（正确！）
下次运行会提前检测到已达上限（高效！）

第二次运行（已更新客户端记录）：

✅ 查询到 4 辆车（今日已发车: 4/4）  ← 客户端记录准确
📊 检查每日发车次数限制: 4/4
⚠️ 发送前检查: 今日发车次数已达上限(4/4)，跳过发送  ← 提前退出！

不再尝试发送，节省4次请求！

🎯 关键优势

特性	v3.10.0	v3.10.1
数据来源	服务器 sendCount（不可靠）	客户端 localStorage + 错误码反馈
同步时机	查询、刷新、发送前都尝试同步	只在收到 12000050 时更新
准确性	❌ 不准确（服务器总是返回0）	✅ 准确（错误码是真实反馈）
效率	❌ 每次都尝试发送4辆车	✅ 第二次运行提前退出
用户体验	❌ 多次失败尝试	✅ 清晰告知原因

🔄 完整流程图

第一次运行（服务器端已有4次记录）

1. 查询车辆
   └─ 客户端记录: 0/4 (不准确)
   
2. 检查发车次数
   └─ 0 < 4，继续
   
3. 尝试发送第1辆车
   └─ 服务器返回: 12000050
   └─ 捕获错误，更新客户端: 0 → 4
   └─ break 停止发送
   
4. 结束
   └─ 客户端记录: 4/4 (准确)

第二次运行（客户端记录已更新）

1. 查询车辆
   └─ 客户端记录: 4/4 (准确)
   
2. 检查发车次数
   └─ 4 >= 4，已达上限
   
3. 提前退出
   └─ 跳过发送，节省4次请求
   
4. 结束
   └─ 客户端记录: 4/4 (准确)

📝 技术细节

为什么服务器的 sendCount 不可靠？

可能的原因：

1. 字段未实现：服务器端可能没有正确实现这个字段的更新逻辑
2. 缓存问题：服务器可能返回了缓存的旧数据
3. 协议版本：可能是协议版本不匹配导致的字段缺失

为什么依赖 12000050 错误码？

1. 唯一可靠的真实信号：这是服务器端在真正检查发车次数后返回的错误
2. 实时反馈：每次发车请求都会触发服务器端的真实检查
3. 精确判断：错误码 12000050 专门表示"今日发车次数已达上限"

为什么设置为 4 而不是累加？

// 错误的做法
dailySendCount++  // 从 0 变成 1，但服务器实际是 4

// 正确的做法
dailySendCount = 4  // 直接设置为上限值

因为：

1. 错误码 12000050 表示已达上限，而不是"再发一次就达上限"
2. 服务器端的上限是固定的 4 次
3. 直接设置为 4 可以避免多次尝试

🧪 测试建议

测试场景1：服务器端已有4次发车记录

1. 清除客户端 localStorage 中的发车记录
2. 运行批量自动化的发车任务
3. 预期结果：
   • 第1次运行：尝试发送1辆车，失败，更新客户端为 4/4
   • 第2次运行：提前检测到 4/4，跳过发送

测试场景2：服务器端有2次发车记录

1. 清除客户端 localStorage 中的发车记录
2. 运行批量自动化的发车任务
3. 预期结果：
   • 成功发送2辆车
   • 客户端更新为 4/4
   • 第2次运行时跳过发送

测试场景3：服务器端0次发车记录

1. 等待服务器日切后（每日0次）
2. 运行批量自动化的发车任务
3. 预期结果：
   • 成功发送4辆车
   • 客户端更新为 4/4
   • 第2次运行时跳过发送

🔗 相关文档

• MD说明/问题分析-发车失败错误12000050v3.9.9.md - 问题发现
• MD说明/功能优化-同步服务器发车次数v3.10.0.md - 失败的尝试
• MD说明/问题修复-服务器sendCount不可靠v3.10.1.md - 本次修复（当前文档）

📋 更新日志

版本: v3.10.1
日期: 2025-10-08
类型: 问题修复

修改内容:

1. ❌ 移除了从服务器 sendCount 字段同步发车次数的逻辑
2. ✅ 保留客户端 localStorage 作为主要的发车次数记录
3. ✅ 使用 12000050 错误码作为同步信号
4. ✅ 当收到 12000050 时，立即将客户端记录更新为 4
5. ✅ 使用 break 停止继续发送，避免浪费请求

影响范围:

• src/stores/batchTaskStore.js - sendCar 任务

解决问题:

• 服务器 sendCount 字段不可靠（总是返回0）
• 客户端和服务器端发车次数不一致
• 重复尝试发送已达上限的车辆

性能提升:

• 第一次运行时减少3次无效请求（从4次减少到1次）
• 第二次运行时直接跳过，节省所有发送请求