482 lines
14 KiB
Markdown
482 lines
14 KiB
Markdown
# 问题修复 - 批量加钟任务失败修复 v3.13.4
|
||
|
||
## 问题描述
|
||
|
||
**现象：**
|
||
- 批量自动化里的加钟任务失败
|
||
- 错误信息：`请求超时: system_mysharecallback (5000ms)`
|
||
- 实际游戏并没有加钟成功
|
||
|
||
**影响范围：**
|
||
- 批量任务中的 `addClock`（加钟）任务
|
||
- 用户在批量自动化中无法成功加钟，影响挂机奖励的获取
|
||
|
||
## 问题分析
|
||
|
||
### 原因定位
|
||
|
||
通过对比游戏功能模块和批量任务模块的加钟实现，发现了关键差异：
|
||
|
||
#### 1. 批量任务的加钟实现（修复前）
|
||
```javascript
|
||
// 位置：src/stores/batchTaskStore.js 第1642-1645行
|
||
const result = await client.sendWithPromise('system_mysharecallback', {
|
||
type: 3, // ❌ 错误：使用了 type: 3
|
||
isSkipShareCard: true
|
||
}, 5000)
|
||
```
|
||
|
||
**问题：**
|
||
- 使用了错误的参数 `type: 3`
|
||
- 只发送1次请求
|
||
- 虽然设置了5000ms超时，但由于参数错误导致服务器无响应
|
||
|
||
#### 2. 游戏功能模块的加钟实现（正确的）
|
||
```javascript
|
||
// 位置：src/components/GameStatus.vue 第435-486行
|
||
for (let i = 0; i < 4; i++) {
|
||
const result = tokenStore.sendMessage(tokenId, 'system_mysharecallback', {
|
||
isSkipShareCard: true,
|
||
type: 2 // ✅ 正确：使用 type: 2
|
||
})
|
||
}
|
||
```
|
||
|
||
**正确做法：**
|
||
- 使用参数 `type: 2`（分享/加钟类型）
|
||
- 发送4次请求，每次间隔300ms
|
||
- 游戏功能模块能正常工作
|
||
|
||
### 参数含义
|
||
|
||
根据代码分析：
|
||
- `type: 2` - 分享游戏/加钟操作
|
||
- `type: 3` - 其他功能（可能是领取挂机奖励后的操作）
|
||
|
||
## 修复方案
|
||
|
||
### 修复内容
|
||
|
||
**修改文件：** `src/stores/batchTaskStore.js`
|
||
|
||
**修改位置：** 第1633-1692行（`addClock` 任务）
|
||
|
||
**核心改动：**
|
||
|
||
1. **参数修复：** `type: 3` → `type: 2`
|
||
2. **请求次数：** 1次 → 4次
|
||
3. **请求间隔：** 增加每次间隔300ms
|
||
4. **保持超时：** 维持5000ms超时（避免连接池模式下的网络拥堵）
|
||
|
||
### 修复后的代码
|
||
|
||
```javascript
|
||
case 'addClock':
|
||
// 加钟（挂机时间延长）- 必须在领取挂机奖励之后
|
||
// 🔧 修复：参考游戏功能模块的加钟逻辑，使用 type: 2 并发送4次
|
||
return await executeSubTask(
|
||
tokenId,
|
||
'add_clock',
|
||
'加钟',
|
||
async () => {
|
||
try {
|
||
console.log(`🕐 [${tokenId}] 开始加钟操作（发送4次请求）`)
|
||
|
||
// 🔧 关键修复：参考 GameStatus.vue 的 extendHangUp 函数
|
||
// 发送4次分享回调请求，使用 type: 2（而不是 type: 3）
|
||
const promises = []
|
||
for (let i = 0; i < 4; i++) {
|
||
const promise = (async () => {
|
||
// 每次请求间隔300ms
|
||
if (i > 0) {
|
||
await new Promise(resolve => setTimeout(resolve, 300))
|
||
}
|
||
|
||
console.log(`🕐 [${tokenId}] 发送第${i+1}/4次加钟请求`)
|
||
const result = await client.sendWithPromise('system_mysharecallback', {
|
||
isSkipShareCard: true,
|
||
type: 2 // 🔧 修复：使用 type: 2（分享/加钟），而不是 type: 3
|
||
}, 5000) // 保持5000ms超时，避免连接池模式下的网络拥堵
|
||
|
||
console.log(`✅ [${tokenId}] 第${i+1}/4次加钟请求完成`)
|
||
return result
|
||
})()
|
||
promises.push(promise)
|
||
}
|
||
|
||
// 等待所有请求完成
|
||
const results = await Promise.all(promises)
|
||
console.log(`✅ [${tokenId}] 加钟操作完成（已发送4次请求）`)
|
||
|
||
return {
|
||
success: true,
|
||
message: '加钟完成',
|
||
results: results
|
||
}
|
||
} catch (error) {
|
||
const errorMsg = error.message || String(error)
|
||
|
||
// 错误码 3100030 表示加钟次数已达上限或其他限制
|
||
if (errorMsg.includes('3100030')) {
|
||
console.log(`⚠️ [${tokenId}] 加钟: 次数已达上限或功能受限`)
|
||
return {
|
||
limitReached: true,
|
||
message: '加钟次数已达上限或功能受限'
|
||
}
|
||
}
|
||
|
||
// 其他错误正常抛出
|
||
throw error
|
||
}
|
||
},
|
||
false
|
||
)
|
||
```
|
||
|
||
## 修复效果
|
||
|
||
### 预期效果
|
||
|
||
✅ **加钟任务成功执行**
|
||
- 发送4次 `system_mysharecallback` 请求（type: 2）
|
||
- 每次请求间隔300ms，确保稳定性
|
||
- 挂机时间成功延长
|
||
|
||
✅ **日志输出清晰**
|
||
```
|
||
🕐 [tokenId] 开始加钟操作（发送4次请求）
|
||
🕐 [tokenId] 发送第1/4次加钟请求
|
||
✅ [tokenId] 第1/4次加钟请求完成
|
||
🕐 [tokenId] 发送第2/4次加钟请求
|
||
✅ [tokenId] 第2/4次加钟请求完成
|
||
🕐 [tokenId] 发送第3/4次加钟请求
|
||
✅ [tokenId] 第3/4次加钟请求完成
|
||
🕐 [tokenId] 发送第4/4次加钟请求
|
||
✅ [tokenId] 第4/4次加钟请求完成
|
||
✅ [tokenId] 加钟操作完成（已发送4次请求）
|
||
```
|
||
|
||
✅ **错误处理完善**
|
||
- 识别错误码 3100030（次数上限）
|
||
- 超时保护（5000ms）
|
||
- 详细的错误日志
|
||
|
||
## 测试建议
|
||
|
||
### 测试步骤
|
||
|
||
1. **启动批量任务**（包含加钟任务）
|
||
```
|
||
完整套餐 或 快速套餐
|
||
```
|
||
|
||
2. **观察控制台日志**
|
||
- 检查是否输出 "开始加钟操作（发送4次请求）"
|
||
- 检查是否成功发送4次请求
|
||
- 检查是否有错误信息
|
||
|
||
3. **检查游戏内挂机时间**
|
||
- 执行前记录挂机剩余时间
|
||
- 执行后检查时间是否延长
|
||
- 每次加钟应延长2小时（4次 × 30分钟）
|
||
|
||
### 预期结果
|
||
|
||
✅ **正常情况**
|
||
- 控制台显示4次加钟请求成功
|
||
- 游戏内挂机时间增加约2小时
|
||
- 任务状态显示 "加钟完成"
|
||
|
||
⚠️ **达到上限**
|
||
- 控制台显示 "加钟: 次数已达上限或功能受限"
|
||
- 任务仍标记为成功（不影响整体任务流程）
|
||
|
||
❌ **网络错误**
|
||
- 控制台显示具体错误信息
|
||
- 任务标记为失败（触发重试机制）
|
||
|
||
## 相关代码对比
|
||
|
||
### system_mysharecallback 参数类型说明
|
||
|
||
根据项目中的使用场景：
|
||
|
||
| type值 | 用途 | 位置 | 备注 |
|
||
|--------|------|------|------|
|
||
| `type: 2` | 分享游戏/加钟 | GameStatus.vue (extendHangUp)<br>batchTaskStore.js (分享游戏)<br>batchTaskStore.js (加钟) | ✅ 正确的加钟参数 |
|
||
| `type: 3` | 未明确 | ~~旧的加钟实现~~ | ❌ 导致加钟失败 |
|
||
|
||
### 一键补差中的分享任务
|
||
|
||
```javascript
|
||
// 位置：src/stores/batchTaskStore.js 第1124-1133行
|
||
const shareResult = await client.sendWithPromise('system_mysharecallback', {
|
||
isSkipShareCard: true,
|
||
type: 2 // 使用 type: 2
|
||
}, 3000)
|
||
```
|
||
|
||
**说明：** 一键补差中的"分享游戏"任务也使用 `type: 2`，进一步证实了参数的正确性。
|
||
|
||
## 技术细节
|
||
|
||
### 为什么要发送4次？
|
||
|
||
游戏服务器的加钟机制可能需要：
|
||
1. 每次分享回调可延长30分钟
|
||
2. 4次请求共延长2小时
|
||
3. 服务器可能有防作弊机制，需要多次确认
|
||
|
||
### 间隔300ms的作用
|
||
|
||
1. **避免请求过快**导致服务器拒绝
|
||
2. **确保每次请求独立处理**
|
||
3. **防止触发反作弊机制**
|
||
|
||
### 5000ms超时的意义
|
||
|
||
1. **连接池模式优化**：在连接池模式下，同时有多个Token在执行任务，网络可能拥堵
|
||
2. **避免误判**：较长的超时时间减少因网络波动导致的失败
|
||
3. **平衡性能**：不会因超时设置过长导致任务卡住
|
||
|
||
## 🔧 追加修复：串行执行问题（v3.13.4.1）
|
||
|
||
### 问题发现
|
||
|
||
用户反馈：虽然发送了4次请求，但**实际只加了3次钟**。
|
||
|
||
### 问题分析
|
||
|
||
原代码使用了**并发执行**：
|
||
|
||
```javascript
|
||
// ❌ 错误的并发执行
|
||
const promises = []
|
||
for (let i = 0; i < 4; i++) {
|
||
const promise = (async () => {
|
||
if (i > 0) {
|
||
await new Promise(resolve => setTimeout(resolve, 300))
|
||
}
|
||
// 发送请求
|
||
})()
|
||
promises.push(promise)
|
||
}
|
||
await Promise.all(promises)
|
||
```
|
||
|
||
**实际执行时序：**
|
||
- **0ms:** 第1个请求发送 ✅
|
||
- **300ms:** 第2、3、4个请求**几乎同时发送** ❌
|
||
|
||
**问题根源：** 所有promise同时创建并启动，导致后3个请求在300ms后几乎同时到达服务器，可能被服务器识别为异常请求而拒绝其中1个。
|
||
|
||
### 修复方案
|
||
|
||
改为**串行执行**：
|
||
|
||
```javascript
|
||
// ✅ 正确的串行执行
|
||
const results = []
|
||
for (let i = 0; i < 4; i++) {
|
||
// 每次请求前间隔300ms（第1次除外）
|
||
if (i > 0) {
|
||
await new Promise(resolve => setTimeout(resolve, 300))
|
||
}
|
||
|
||
const result = await client.sendWithPromise('system_mysharecallback', {
|
||
isSkipShareCard: true,
|
||
type: 2
|
||
}, 5000)
|
||
|
||
results.push(result)
|
||
}
|
||
```
|
||
|
||
**正确的执行时序：**
|
||
- **0ms:** 第1个请求发送 ✅
|
||
- **300ms:** 第2个请求发送 ✅
|
||
- **600ms:** 第3个请求发送 ✅
|
||
- **900ms:** 第4个请求发送 ✅
|
||
|
||
每次请求都有**300ms的间隔**，服务器可以正确处理每个请求。
|
||
|
||
---
|
||
|
||
## 🔄 再次调整：并行模式10次加钟（v3.13.4.2）
|
||
|
||
### 用户需求
|
||
|
||
用户要求：
|
||
1. 恢复使用**并行模式**（更快）
|
||
2. 增加加钟次数到**10次**（延长更多时间）
|
||
|
||
### 调整方案
|
||
|
||
**最终代码：**
|
||
|
||
```javascript
|
||
// ✅ 并行模式，发送10次加钟请求
|
||
const promises = []
|
||
for (let i = 0; i < 10; i++) {
|
||
const promise = new Promise((resolve) => {
|
||
setTimeout(() => {
|
||
client.sendWithPromise('system_mysharecallback', {
|
||
isSkipShareCard: true,
|
||
type: 2 // 使用 type: 2（分享/加钟）
|
||
}, 5000)
|
||
.then(result => {
|
||
console.log(`✅ 第${i+1}/10次加钟请求完成`)
|
||
resolve(result)
|
||
})
|
||
.catch(error => {
|
||
console.warn(`⚠️ 第${i+1}/10次加钟请求失败`)
|
||
resolve(null) // 即使失败也resolve，不影响其他请求
|
||
})
|
||
}, i * 300) // 每次间隔300ms启动
|
||
})
|
||
promises.push(promise)
|
||
}
|
||
|
||
const results = await Promise.all(promises)
|
||
const successCount = results.filter(r => r !== null).length
|
||
console.log(`✅ 加钟操作完成（发送10次，成功${successCount}次）`)
|
||
```
|
||
|
||
**执行时序：**
|
||
- **0ms:** 第1个请求发送
|
||
- **300ms:** 第2个请求发送
|
||
- **600ms:** 第3个请求发送
|
||
- **900ms:** 第4个请求发送
|
||
- **1200ms:** 第5个请求发送
|
||
- **1500ms:** 第6个请求发送
|
||
- **1800ms:** 第7个请求发送
|
||
- **2100ms:** 第8个请求发送
|
||
- **2400ms:** 第9个请求发送
|
||
- **2700ms:** 第10个请求发送
|
||
|
||
**优势：**
|
||
- ⚡ 并行执行，总耗时约3秒（而非串行的4.5秒）
|
||
- 🛡️ 间隔300ms启动，避免瞬间压力
|
||
- 🔄 单个失败不影响其他请求
|
||
- 📊 统计成功次数，便于调试
|
||
|
||
**预期效果：**
|
||
- 每次加钟30分钟 × 10次 = **延长5小时**（如果全部成功）
|
||
- 即使部分失败，也能延长对应时间
|
||
|
||
---
|
||
|
||
## ⚡ 最终优化：一次性同时发送（v3.13.4.3）
|
||
|
||
### 用户需求
|
||
|
||
用户要求：**去掉所有延迟，一次性同时发送10个请求**
|
||
|
||
### 最终代码
|
||
|
||
```javascript
|
||
// ⚡ 一次性同时发送10次加钟请求（无延迟）
|
||
const promises = []
|
||
for (let i = 0; i < 10; i++) {
|
||
console.log(`🕐 发送第${i+1}/10次加钟请求`)
|
||
const promise = client.sendWithPromise('system_mysharecallback', {
|
||
isSkipShareCard: true,
|
||
type: 2 // 使用 type: 2（分享/加钟）
|
||
}, 5000)
|
||
.then(result => {
|
||
console.log(`✅ 第${i+1}/10次加钟请求完成`)
|
||
return result
|
||
})
|
||
.catch(error => {
|
||
console.warn(`⚠️ 第${i+1}/10次加钟请求失败`)
|
||
return null
|
||
})
|
||
|
||
promises.push(promise)
|
||
}
|
||
|
||
const results = await Promise.all(promises)
|
||
const successCount = results.filter(r => r !== null).length
|
||
console.log(`✅ 加钟操作完成（一次性发送10次，成功${successCount}次）`)
|
||
```
|
||
|
||
**特点：**
|
||
- ⚡ **极速执行** - 10个请求在0ms时刻同时发送
|
||
- 🔄 **完全并发** - 无任何延迟，最快速度
|
||
- 🛡️ **容错机制** - 单个失败不影响其他请求
|
||
- 📊 **成功统计** - 显示实际成功次数
|
||
|
||
---
|
||
|
||
## 版本信息
|
||
|
||
**最终版本：** v3.13.4.3
|
||
|
||
**修复日期：** 2025-01-09
|
||
|
||
**修改历程：**
|
||
1. ✅ v3.13.4：参数修复 `type: 3` → `type: 2`，4次请求
|
||
2. ✅ v3.13.4.1：改为串行执行，避免并发问题
|
||
3. ✅ v3.13.4.2：恢复并行模式，增加到10次，300ms间隔
|
||
4. ✅ v3.13.4.3：**去掉延迟，一次性同时发送10次（最终版）**
|
||
|
||
**影响范围：**
|
||
- ✅ 批量任务 - 加钟功能
|
||
- ✅ 完整套餐
|
||
- ✅ 快速套餐
|
||
|
||
**兼容性：**
|
||
- ✅ 传统模式
|
||
- ✅ 连接池模式（v3.13.0+）
|
||
- ✅ 100并发优化（v3.11.0+）
|
||
|
||
## 附录：完整修改记录
|
||
|
||
### 修改前（错误代码）
|
||
```javascript
|
||
const result = await client.sendWithPromise('system_mysharecallback', {
|
||
type: 3, // ❌ 错误参数
|
||
isSkipShareCard: true
|
||
}, 5000)
|
||
```
|
||
|
||
### 修改后（正确代码）
|
||
```javascript
|
||
const promises = []
|
||
for (let i = 0; i < 4; i++) {
|
||
const promise = (async () => {
|
||
if (i > 0) {
|
||
await new Promise(resolve => setTimeout(resolve, 300))
|
||
}
|
||
|
||
const result = await client.sendWithPromise('system_mysharecallback', {
|
||
isSkipShareCard: true,
|
||
type: 2 // ✅ 正确参数
|
||
}, 5000)
|
||
|
||
return result
|
||
})()
|
||
promises.push(promise)
|
||
}
|
||
|
||
const results = await Promise.all(promises)
|
||
```
|
||
|
||
## 总结
|
||
|
||
本次修复通过对比游戏功能模块和批量任务模块的加钟实现，发现并修正了参数错误：
|
||
|
||
1. **核心问题：** 参数 `type: 3` 应改为 `type: 2`
|
||
2. **次要优化：** 从发送1次改为发送4次，与游戏模块保持一致
|
||
3. **稳定性提升：** 增加请求间隔（300ms）和详细日志
|
||
|
||
修复后，批量加钟任务应能正常工作，与游戏内手动加钟效果一致。
|
||
|
||
---
|
||
|
||
**相关文档：**
|
||
- [连接池模式 v3.13.0](./架构优化-100并发稳定运行方案v3.13.0.md)
|
||
- [问题修复-加钟超时和发车错误码v3.11.20](./问题修复-加钟超时和发车错误码v3.11.20.md)
|
||
- [批量自动化-超时延迟配置表v3.11](./批量自动化-超时延迟配置表v3.11.md)
|
||
|