302 lines
10 KiB
Markdown
302 lines
10 KiB
Markdown
# 问题修复 - 服务器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）**：
|
||
```javascript
|
||
// 获取服务器端的发车次数并同步到本地
|
||
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）**：
|
||
```javascript
|
||
// 获取客户端的发车次数记录
|
||
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）**：
|
||
```javascript
|
||
catch (error) {
|
||
const errorMsg = error.message || String(error)
|
||
|
||
if (errorMsg.includes('12000050')) {
|
||
console.log(`⚠️ [${tokenId}] 车辆 ${carId} 发送失败: 今日发车次数已达上限（服务器端限制）`)
|
||
// 没有更新客户端记录，导致客户端和服务器端不一致
|
||
}
|
||
// ...
|
||
}
|
||
```
|
||
|
||
**修改后（v3.10.1）**：
|
||
```javascript
|
||
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 而不是累加？
|
||
|
||
```javascript
|
||
// 错误的做法
|
||
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次）
|
||
- 第二次运行时直接跳过，节省所有发送请求
|
||
|