基于discord.js实现Discord机器人推送Twitter动态实时更新

嘿，我完全懂你想要实现类似IFTTT的实时推送功能，但Twitter API确实没有提供原生的webhook来触发新推文的实时通知——目前最可行的方案就是定期轮询Twitter API，这也是大多数第三方工具背后的核心逻辑。下面结合你现有的代码片段，一步步拆解实现方法：

核心思路 #

我们会定时调用Twitter的用户时间线API，对比上次记录的最新推文ID（Twitter的推文ID是递增的，新推文ID更大），如果检测到新推文，就推送到指定的Discord频道。

具体实现步骤 #

1. 存储上次的推文ID #

首先需要一个持久化的地方记录最后一次推送的推文ID，避免重复推送。这里用简单的本地JSON文件演示，你也可以用数据库（比如SQLite）来替代：

const fs = require('fs');
const LAST_TWEET_ID_FILE = './lastTweetId.json';

// 读取上次保存的推文ID
function getLastTweetId() {
  try {
    const data = fs.readFileSync(LAST_TWEET_ID_FILE, 'utf8');
    return JSON.parse(data).id;
  } catch (err) {
    // 文件不存在时返回0，表示第一次获取所有最新推文
    return 0;
  }
}

// 保存最新的推文ID
function saveLastTweetId(id) {
  fs.writeFileSync(LAST_TWEET_ID_FILE, JSON.stringify({ id }));
}

2. 封装推文检查与推送逻辑 #

把你现有的API调用逻辑封装成函数，加上新推文的判断逻辑：

function checkForNewTweets(client, discordChannelId) {
  const lastTweetId = getLastTweetId();
  client.get('statuses/user_timeline', {
    screen_name: 'PulkitSinghss',
    count: 5, // 一次获取5条，避免漏掉轮询间隔内的多条推文
    include_rts: false,
    exclude_replies: true,
    since_id: lastTweetId // 只获取比上次ID更新的推文
  }, function(error, tweets, response) {
    if (error) {
      console.error('获取推文失败:', error);
      return;
    }

    // 按时间正序遍历（确保先推最早的新推文）
    tweets.reverse().forEach(tweet => {
      // 推送到Discord指定频道
      const channel = client.channels.cache.get(discordChannelId);
      if (channel) {
        channel.send(`**PulkitSinghss 发布新推文啦！**\n${tweet.text}\nhttps://twitter.com/PulkitSinghss/status/${tweet.id_str}`);
      }
      // 更新最新推文ID
      saveLastTweetId(tweet.id_str);
    });
  });
}

3. 设置定时任务 #

用setInterval定期执行检查，比如每5分钟一次（注意不要太频繁，避免触发Twitter API的速率限制）：

// 替换成你的目标Discord频道ID
const TARGET_CHANNEL_ID = '123456789012345678';

// 机器人启动后立即检查一次，之后每5分钟轮询一次
checkForNewTweets(client, TARGET_CHANNEL_ID);
setInterval(() => {
  checkForNewTweets(client, TARGET_CHANNEL_ID);
}, 5 * 60 * 1000); // 5分钟，单位为毫秒

关键注意事项 #

• API速率限制：Twitter API v1.1的statuses/user_timeline端点每15分钟允许调用900次，5分钟一次的频率完全在限制内；如果迁移到API v2的/2/users/:id/tweets端点，限制是每15分钟100次，同样足够。
• 持久化可靠性：如果机器人部署在云服务器上，本地文件可能因为重启丢失，建议用数据库或者云存储来保存推文ID。
• 错误重试：可以给API调用加上简单的重试逻辑，比如失败后隔2分钟再试一次，避免网络波动导致漏推。
• API版本迁移：Twitter官方现在推荐使用v2版本的API，响应结构更清晰，过滤参数更灵活，你可以考虑后续迁移过去。

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