xyzw_web_helper/MD说明文件夹/问题修复-批量加钟失败修复v3.13.4.md

问题修复 - 批量加钟任务失败修复 v3.13.4

问题描述

现象：

• 批量自动化里的加钟任务失败
• 错误信息：请求超时: system_mysharecallback (5000ms)
• 实际游戏并没有加钟成功

影响范围：

• 批量任务中的 addClock（加钟）任务
• 用户在批量自动化中无法成功加钟，影响挂机奖励的获取

问题分析

原因定位

通过对比游戏功能模块和批量任务模块的加钟实现，发现了关键差异：

1. 批量任务的加钟实现（修复前）

// 位置：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. 游戏功能模块的加钟实现（正确的）

// 位置：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超时（避免连接池模式下的网络拥堵）

修复后的代码

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	未明确	旧的加钟实现	❌ 导致加钟失败

一键补差中的分享任务

// 位置：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次钟。

问题分析

原代码使用了并发执行：

// ❌ 错误的并发执行
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个。

修复方案

改为串行执行：

// ✅ 正确的串行执行
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次（延长更多时间）

调整方案

最终代码：

// ✅ 并行模式，发送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个请求

最终代码

// ⚡ 一次性同时发送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+）

附录：完整修改记录

修改前（错误代码）

const result = await client.sendWithPromise('system_mysharecallback', { 
  type: 3,  // ❌ 错误参数
  isSkipShareCard: true 
}, 5000)

修改后（正确代码）

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
• 问题修复-加钟超时和发车错误码v3.11.20
• 批量自动化-超时延迟配置表v3.11