Discord.js v13如何按数组顺序轮播机器人状态

问题核心原因 #

你遇到的状态始终卡在第一个数组元素的问题，是Discord.js v13中ready事件会在WebSocket重连、分片加载完成等场景下重复触发，原代码没有做定时器去重，每次触发ready都会新建一个带独立闭包的setInterval定时器，多个定时器同时运行、互相覆盖状态，最终表现为一直显示第一个状态。
另外v13版本的setActivityAPI对参数校验更严格，省略活动类型配置时偶发静默调用失败的问题。

修复后可直接运行的代码 #

const activities = ['t', 'te', 'tes', 'test'];
// 全局存储定时器ID，避免重复注册
let activityTimer = null;

client.on('ready', () => {
  // 每次触发ready先清除已存在的定时器，防止多定时器冲突
  if (activityTimer) clearInterval(activityTimer);
  
  const updateDelay = 5; // 单位：秒
  let currentIndex = 0;

  // 机器人上线先设置第一个状态，无需等待第一个轮询周期
  client.user.setActivity(activities[currentIndex], { type: 'PLAYING' });
  currentIndex = (currentIndex + 1) % activities.length;

  activityTimer = setInterval(() => {
    // 明确传入活动类型配置，符合v13 API规范
    client.user.setActivity(activities[currentIndex], { type: 'PLAYING' })
      .catch(console.error); // 捕获API调用错误，方便排查问题
    // 用取模运算简化索引循环逻辑，和原判断逻辑效果完全一致
    currentIndex = (currentIndex + 1) % activities.length;
  }, updateDelay * 1000);
});

关键修改点说明 #

• 新增全局定时器ID变量，每次触发ready事件时先清除已有定时器，从根源避免多实例定时器互相覆盖状态
• 给setActivity传入明确的第二个配置参数，指定活动类型（可选值为PLAYING/STREAMING/LISTENING/WATCHING/COMPETING，可按需替换），避免v13版本API参数校验不通过导致的静默失败
• 给setActivity加错误捕获，遇到权限、限流等问题时会在控制台打印错误，不会无提示失败
• 用取模运算(currentIndex + 1) % activities.length替换原有的三目判断，逻辑更简洁，循环顺序完全符合预期

注意：Discord客户端本身对用户状态有10-30秒的缓存，刚启动机器人时如果看到状态没立刻刷新是正常现象，等一个轮询周期就能看到稳定的切换效果。

内容的提问来源于stack exchange，提问作者BloodyR