# 问题修复 - 批量加钟任务失败修复 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)
batchTaskStore.js (分享游戏)
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)