grammY 机器人开发中 setMyCommands 的常见问题与解决方案

在基于 grammY 框架开发即时通讯机器人时，setMyCommands API 的调用是一个常见但容易出错的环节。本文将深入分析该问题的技术背景，并提供多种解决方案。

问题现象

开发者在单元测试中调用 setMyCommands 时遇到 404 错误，具体表现为：

• 测试运行时抛出 GrammyError: Call to 'setMyCommands' failed! (404: Not Found)
• 错误发生在模块加载阶段而非测试执行阶段

根本原因分析

这个问题主要由两个技术因素导致：

1. 模块加载顺序问题
   在代码结构中，setMyCommands 调用直接写在模块顶层，会在模块导入时立即执行。而此时测试环境的请求转换器（transformer）尚未安装，导致实际向服务器发送了无效请求。

2. 测试环境特殊性
   测试环境下通常使用模拟数据，而直接调用 API 会尝试连接真实服务器，这与测试隔离原则相违背。

解决方案

方案一：代码结构调整（推荐）

将命令设置逻辑封装为函数，在适当的时机调用：

// bot.ts
export async function setupCommands(bot: Bot) {
  await bot.api.setMyCommands([
    // 命令列表
  ])
}

// 测试文件中
beforeAll(async () => {
  // 先安装转换器
  bot.api.config.use(/* ... */)
  // 再设置命令
  await setupCommands(bot)
})

方案二：生产环境最佳实践

对于生产环境，建议采用以下模式：

1. 通过管理工具直接配置
   最简单可靠的方式是直接使用管理工具设置全局命令。

2. 部署脚本控制
   将命令设置逻辑放在部署脚本中执行，而不是放在业务代码里：

# deploy.sh
npx ts-node src/deploy-commands.ts

3. 动态命令设置
   只有在需要设置特定作用域命令（如群组专属命令）时，才在业务代码中使用 setMyCommands：

bot.on('chat_member', async (ctx) => {
  if (ctx.chatMember.new_chat_member.status === 'member') {
    await ctx.api.setMyCommands(/* ... */, {
      scope: { type: 'chat', chat_id: ctx.chat.id }
    })
  }
})

测试环境特殊处理

在测试环境中，需要特别注意：

1. 请求拦截
   确保所有 API 调用都被正确拦截和模拟：

beforeAll(() => {
  bot.api.config.use((prev, method, payload) => {
    if (method === 'setMyCommands') {
      return { ok: true, result: true } // 模拟成功响应
    }
    return prev(method, payload)
  })
})

2. 异步控制
   所有异步操作都应在测试生命周期钩子中正确处理：

describe('Bot测试', () => {
  beforeAll(async () => {
    await bot.init()
    await setupTestCommands()
  }, 10000) // 适当延长超时
})

总结

在 grammY 框架中处理机器人命令设置时，开发者应当：

• 区分生产环境和测试环境的不同需求
• 遵循模块化原则，将配置逻辑与业务逻辑分离
• 在测试中确保完全的请求隔离
• 根据实际场景选择最合适的命令设置方式

通过合理的架构设计和环境隔离，可以有效避免 setMyCommands 相关的各种问题，构建更健壮的即时通讯机器人应用。