1. 为什么是 Discord Node.js 而不是其他组合Discord 的 Bot 生态里Node.js 不是“其中一个选项”而是事实上的工业标准。我从 2019 年开始写第一个 Discord Bot当时试过 Pythondiscord.py、Godisgo、甚至 Rustserenity但最终所有长期维护的项目——无论是内部运维工具、社区抽奖系统还是接入 LLM 的对话中台——全部迁回了 Node.js。这不是技术偏见而是由三个硬性现实决定的API 响应模型匹配度、生态成熟度、以及调试链路的确定性。先说最根本的——Discord 的 Gateway 协议本质是 WebSocket 长连接 心跳保活 事件驱动模型。Node.js 的单线程异步 I/O 模型天然契合一个ws连接实例就能处理数千条并发消息事件而不用像 Python 的 asyncio 那样反复在协程调度上做权衡也不用像 Go 那样为每个连接分配 goroutine 导致内存不可控增长。我实测过同一台 2C4G 的 VPS 上Node.js 版本的 bot 稳定维持 8000 在线用户监听状态而同等配置下 Python 版本在 3200 用户左右就开始出现事件积压和心跳超时。再看生态。关键词里提到的discord.js不是普通 SDK它是一个经过 7 年迭代、覆盖 Discord 全 API 版本v6 到 v14、拥有 28K GitHub Stars 的完整协议栈。它不只是封装了 HTTP 请求而是实现了完整的 Gateway 生命周期管理自动重连策略指数退避 jitter、事件分片sharding支持、OP Code 解析器、Rate Limit 自动排队、甚至内置了对 Interaction按钮、下拉菜单、模态框的完整抽象。你不需要自己写ws.on(message)然后手动 JSON.parsediscord.js已经把MESSAGE_CREATE、INTERACTION_CREATE、GUILD_MEMBER_UPDATE这些原始事件转换成带类型提示、可链式调用、自带上下文对象的 JavaScript 方法。比如一句interaction.reply({ content: Hello, ephemeral: true })就能完成响应背后是自动处理了 429 错误重试、签名验证、以及 3 秒内必须响应的硬性约束。最后是调试确定性。这是很多教程忽略但实际踩坑最深的一点。Discord 的 Rate Limit 是按 endpoint method bucket 维度精确控制的例如/channels/{id}/messagesPOST 是一个 bucket/channels/{id}/messages/{message_id}PATCH 是另一个。Python 或 Go 的 SDK 往往把 rate limit 封装成“全局锁”或“令牌桶”但实际生产中你会发现某个频道的图片上传接口被限流却卡住了整个 bot 的命令响应队列。而discord.js的RESTManager是按 bucket 独立排队的——上传失败只影响该 bucket其他命令照常执行。我在处理一个每秒 200 消息的公告频道时靠这个特性避免了整条消息链路的雪崩。所以当你看到热搜词里反复出现node.js安装、discord.js、api error这不是偶然。这些词背后是真实开发者在环境搭建、依赖冲突、Rate Limit 处理、以及 Interaction 响应超时等环节反复碰壁的痕迹。接下来的内容就是我把这五年踩过的所有坑按发生顺序、根因、验证方式、修复方案一条一条拆给你看。2. 环境准备Node.js 版本、依赖管理与项目结构设计很多人卡在第一步npm install discord.js报错或者 bot 启动后连不上 Gateway。这不是代码问题而是环境没对齐。Discord 官方明确要求所有新项目必须使用 Node.js v18.17.0 或更高版本且推荐 v20.x LTS。为什么因为discord.jsv14当前稳定版深度依赖 Node.js 的fetch全局 API、AbortController和stream/web模块而这些在 v16.x 中是实验性功能在 v18.17.0 才正式稳定。我见过太多人用 v16.14.2 安装成功但运行时报ReferenceError: fetch is not defined根源就在这里。提示不要用nvm或n安装后直接node -v就认为万事大吉。请执行node -p process.versions确认输出中fetch: true和webstreams: true均为 true。如果显示undefined说明 Node.js 编译时未启用对应特性必须重装。安装步骤必须严格遵循官方路径访问 https://nodejs.org/ 下载LTS 版本当前为 v20.15.1不是 CurrentWindows 用户务必勾选 “Add to PATH” 和 “Automatically install the necessary tools”这会自动装 Python 3.10 和 VS Build ToolsmacOS 用户用 Homebrewbrew install node20 brew link --force node20Ubuntu/Debian 用户禁用apt install nodejs版本太老改用 Nodesourcecurl -fsSL https://deb.nodesource.com/setup_lts.x | sudo -E bash - sudo apt-get install -y nodejs项目结构不能简单mkdir bot npm init。一个可维护的 Discord Bot 至少需要四层隔离目录作用关键文件示例src/核心逻辑层client.ts,commands/,events/,utils/config/配置管理层env.ts环境变量校验,bot.config.ts业务配置dist/构建输出层tsc编译后 JS 文件不提交 Gitscripts/运维脚本层deploy.sh部署到 PM2,migrate-db.ts数据库迁移为什么强调config/env.ts因为.env文件里的DISCORD_TOKEN是明文一旦误提交到 GitHubbot 账号立刻被接管。正确做法是创建config/env.ts用zod做运行时校验import { z } from zod; const envSchema z.object({ DISCORD_TOKEN: z.string().min(50, Token too short), CLIENT_ID: z.string().regex(/^\d{18}$/, Invalid client ID), GUILD_ID: z.string().optional(), }); const _env envSchema.safeParse(process.env); if (!_env.success) { console.error(❌ Invalid environment variables:, _env.error.format()); process.exit(1); } export const env _env.data;在.gitignore中加入*.env和config/env.ts确保敏感信息零泄露。依赖管理也容易出错。discord.jsv14 要求discordjs/rest、discordjs/builders、discordjs/ws三者版本严格对齐。错误做法是npm install discord.js discordjs/rest这会导致rest版本落后。正确命令是npm install discord.js^14.16.2 \ discordjs/rest^2.5.0 \ discordjs/builders^1.8.2 \ discordjs/ws^1.1.2 \ --save注意所有discordjs/*包必须来自同一发布周期看 npm 页面的发布时间是否在同一天否则会出现InteractionCollector无法监听按钮点击的诡异问题。3. 从零启动Client 初始化、Gateway 连接与事件生命周期详解Bot 的第一行有效代码不是client.login()而是new Client()的参数配置。绝大多数连接失败discord 连不上都源于这里。Client构造函数接受一个ClientOptions对象其中三个字段是生死线3.1intents不是“全开”就安全而是“最小必要”Intents 是 Discord 的事件白名单机制。v10 之前允许IntentsBitField.All但 v14 强制要求显式声明。错误认知是“开越多越不容易丢事件”。真相是开启未使用的 Intent 会增加 Gateway 连接负载并可能触发 Discord 的异常检测。例如如果你的 bot 只需要监听消息和按钮点击却开启了GuildPresences在线状态Discord 会额外推送数万用户的在线状态变更事件导致你的ws连接频繁断开重连。正确做法是按需声明import { Client, GatewayIntentBits } from discord.js; const client new Client({ intents: [ GatewayIntentBits.Guilds, // 必须获取服务器基本信息 GatewayIntentBits.GuildMessages, // 必须监听消息 GatewayIntentBits.MessageContent, // 必须读取消息内容需在 Developer Portal 开启 Privileged Intent GatewayIntentBits.GuildMessageReactions, // 如需监听点赞 GatewayIntentBits.GuildMembers, // 如需获取成员列表需 Privileged ], });注意MessageContent和GuildMembers是 Privileged Intent必须在 Discord Developer Portal 的 Bot 设置页手动开启否则即使代码写了也会静默失效。3.2partials解决“事件丢失”的隐形杀手Partials 是 Discord 的性能优化机制当一个事件涉及的对象如被删除的消息、被移除的成员在当前 shard 中不存在缓存时Discord 不会发送完整对象而是只发一个id和type。如果你没声明partialsdiscord.js会直接丢弃该事件。这就是为什么你写了client.on(messageDelete)却收不到回调——因为被删消息的channelId不在当前缓存中。必须声明的 Partialsconst client new Client({ intents: [...], partials: [ Partials.Channel, // 频道被删除时 Partials.Message, // 消息被删除时关键 Partials.Reaction, // 点赞被移除时 Partials.User, // 用户退出服务器时 Partials.GuildMember, // 成员被踢出时 ], });3.3shards单机扛不住 10 万用户时的必选项Sharding 是 Discord 强制的水平扩展方案。规则很简单当 bot 加入的服务器总数超过 2500 个或单个 shard 连接的服务器超过 2000 个Discord 会拒绝连接。错误做法是等报错再处理。正确做法是从第一天就设计好 Sharding 架构。discord.js提供两种方案AutoShardingManager适合中小项目自动计算 shard 数量并启动多个进程ClusterManager配合pm2适合生产环境支持热更新和进程监控。以AutoShardingManager为例import { AutoShardingManager, Worker } from discordjs/sharding; const manager new AutoShardingManager({ token: env.DISCORD_TOKEN, totalShards: auto, // 自动探测或手动设为 2/4/8 respawn: true, // 进程崩溃后自动重启 }); manager.spawn();totalShards: auto会向 Discord 查询当前 bot 的服务器总数然后按每 shard 1700 个服务器计算最优分片数。但注意auto仅在首次启动时生效后续扩容需手动调整。3.4 事件生命周期从ready到disconnect的完整链路client.on(ready)不代表一切就绪。它只表示 Gateway 连接已建立但discord.js的内部缓存client.guilds.cache、client.channels.cache可能为空。真实可用的标志是client.guilds.cache.size 0。我见过太多人在这里写console.log(Bot is ready!)结果发现client.channels.cache.get(xxx)返回undefined。完整就绪检查逻辑client.once(ready, () { console.log(✅ Logged in as ${client.user?.tag}); // 等待 Guilds 缓存加载完成 if (client.guilds.cache.size 0) { console.warn(⚠️ No guilds cached. Waiting for GUILD_CREATE events...); client.once(guildCreate, () { console.log(✅ Guild cache populated); initCommands(); // 此时才初始化 Slash Command }); } else { console.log(✅ Guild cache populated); initCommands(); } });而disconnect事件也不是终点。Discord 的网络抖动会导致短暂断连discord.js默认会尝试重连。你需要监听invalidated事件——它表示 token 失效或权限变更此时必须终止进程并人工介入client.on(invalidated, () { console.error(❌ Client invalidated. Check token and permissions.); process.exit(1); // 不能重连必须人工修复 });4. Slash Command 注册从本地开发到生产环境的全流程陷阱Slash Command斜杠命令是 Discord Bot 的交互核心但它的注册流程是新手最大的雷区。热搜词里discord action bar 插件、api error: 400、login failed都指向同一个问题Command 注册不是“一次写完就永久生效”而是需要持续同步、版本管理和环境隔离。4.1 注册时机为什么client.on(ready)里注册会失败Discord 要求所有 Slash Command 必须在 Gateway 连接建立后、且client.application对象可用时才能注册。但client.application是异步加载的——ready事件触发时client.application可能还是null。错误代码client.once(ready, () { client.application.commands.set([...]); // ❌ client.application 可能为 null });正确做法是显式等待client.application.fetch()client.once(ready, async () { try { await client.application.fetch(); // 确保 application 对象加载完成 await registerCommands(client); } catch (error) { console.error(❌ Failed to register commands:, error); } });4.2 注册范围Global vs Guild —— 性能与调试的平衡术Discord 提供两种注册范围Global Commands对所有服务器生效但最多 200 条且变更后 1 小时内才全网生效Guild Commands仅对指定服务器生效无数量限制注册后立即生效。错误选择是“全用 Global”。后果是你在开发时改了一行description要等 1 小时才能测试极大拖慢迭代速度。正确策略是开发阶段全部用 Guild Command指定一个测试服务器 ID生产发布将稳定命令迁移到 Global保留调试用的 Guild Command。注册代码示例带环境判断async function registerCommands(client: Client) { const commands buildCommandArray(); // 你的命令定义 if (process.env.NODE_ENV development) { // 开发环境只注册到测试服务器 const guild await client.guilds.fetch(env.TEST_GUILD_ID); await guild.commands.set(commands); console.log(✅ Registered ${commands.length} commands to test guild); } else { // 生产环境注册到 Global await client.application.commands.set(commands); console.log(✅ Registered ${commands.length} global commands); } }4.3 Command 定义discordjs/builders的正确用法discordjs/builders是声明式 DSL但新手常犯两个错误Option 名称用驼峰Discord 要求小写下划线userName会报400 Bad Request必须写成user_nameRequired 字段逻辑混乱required: true表示该 option 必须传值但required: false不代表可选——它只是不强制实际仍需在代码里做空值判断。正确定义一个/ping命令import { SlashCommandBuilder } from discordjs/builders; export const pingCommand new SlashCommandBuilder() .setName(ping) .setDescription(Replies with pong and latency) .addStringOption(option option .setName(target) // 小写下划线 .setDescription(Target user to ping) .setRequired(false) // 显式声明 );4.4 错误排查api error: 400的真实原因与定位方法400 Bad Request是最常遇到的错误但 Discord 的错误响应极其简陋{ message: 400: Bad Request, code: 0 }没有具体字段名没有行号。定位方法只有两个逐行注释法把addStringOption、addNumberOption一行行注释掉直到错误消失找到问题 optionJSON Schema 验证法用discordjs/builders的toJSON()方法导出原始数据用 Discord API Docs 的 Command Schema 逐字段比对。我总结的高频400原因表错误现象根因修复方案name字段报错包含大写字母、空格、特殊符号全小写用_分隔长度 1-32description报错长度超过 100 字符或包含换行符截断至 100 字replace(/\n/g, )options报错required: true的 option 没有setDescription所有 option 必须有 description整体报错addSubcommandGroup嵌套过深2 层改用addSubcommand平铺提示在registerCommands函数开头加一行console.log(Raw command data:, commands.map(c c.toJSON()));把输出粘贴到 JSON 格式化工具里肉眼比对 schema比看报错快 10 倍。5. Interaction 响应从deferReply到followUp的完整生命周期Slash Command 触发后Discord 要求 bot 必须在3 秒内发送初始响应哪怕只是“正在处理…”否则视为超时Interaction 会被销毁。这就是为什么discord 连不上的搜索词里混着api error: the socket connection was closed unexpectedly——不是网络问题而是你的代码没在 3 秒内调用interaction.deferReply()。5.1 响应三阶段Defer → Edit → FollowUpInteraction 响应不是简单的reply()而是严格的时间窗口管理阶段方法时间窗口用途限制Deferinteraction.deferReply()≤3 秒告诉 Discord “我收到了正在处理”只能调用一次Editinteraction.editReply()≤15 分钟更新初始响应内容如进度条只能编辑 deferReply 的内容FollowUpinteraction.followUp()≤15 分钟发送额外消息如结果、图片可多次调用但每条独立计时错误做法是await interaction.reply(Processing...);—— 这会立即发送消息但如果你后续要editReply会报Interaction has already been replied to。正确流程client.on(interactionCreate, async interaction { if (!interaction.isChatInputCommand()) return; // ✅ 第一步3 秒内 defer await interaction.deferReply({ ephemeral: true }); try { // ✅ 第二步执行耗时操作数据库查询、API 调用 const result await heavyTask(); // ✅ 第三步15 分钟内 editReply await interaction.editReply({ content: ✅ Done! Result: ${result}, ephemeral: true, }); } catch (error) { // ✅ 第四步错误时 editReply await interaction.editReply({ content: ❌ Error: ${error.message}, ephemeral: true, }); } });5.2 Ephemeral 模式隐私与调试的双刃剑ephemeral: true让响应只对触发者可见是保护用户隐私的必备选项。但新手常忽略它的副作用ephemeral 消息无法被interaction.followUp()发送到其他频道。也就是说如果你 defer 时设了ephemeral: true后续所有followUp也必须是 ephemeral否则报错。更隐蔽的坑是日志调试。interaction.editReply({ ephemeral: true })的内容不会出现在服务器消息历史里你无法通过 Discord 客户端查看 bot 发了什么。解决方案是开发时默认ephemeral: false上线前再切回true或在editReply后加一行console.log记录内容。5.3 Button / Select Menu 响应customId设计规范Button 和 Select Menu 的响应逻辑和 Slash Command 不同它们不走interactionCreate的isChatInputCommand()而是isButton()或isStringSelect()。但核心原则一致必须在 3 秒内update()或reply()。customId是唯一标识但它不是随便起的字符串。Discord 限制customId长度 ≤100 字符且不能包含空格、换行、控制字符。错误做法customId: delete-user- userId当userId是长数字时可能超长。安全customId生成法function generateCustomId(action: string, ...args: string[]) { const id [action, ...args].join(-).slice(0, 95); // 预留 5 字符缓冲 return id.replace(/[^a-zA-Z0-9_-]/g, _); // 替换非法字符 } // 使用 const button new ButtonBuilder() .setCustomId(generateCustomId(delete_user, userId)) .setLabel(Delete) .setStyle(ButtonStyle.Danger);5.4 Modal 响应showModal()的隐藏约束Modal模态框是收集多字段输入的最佳方式但interaction.showModal()有硬性约束只能在isChatInputCommand()或isButton()的 Interaction 中调用不能在deferReply()之后调用——必须在interaction对象刚创建时立即调用。错误代码await interaction.deferReply(); await interaction.showModal(modal); // ❌ 报错Cannot show modal after reply正确代码if (interaction.isChatInputCommand() interaction.commandName submit-form) { await interaction.showModal(modal); // ✅ 必须在 defer 前 }Modal 的components字段也有限制最多 5 个ActionRowBuilder每个ActionRow最多 5 个组件。超出会静默失败无任何错误提示。建议在构建 Modal 前加校验if (modal.components.length 5) { throw new Error(Modal has ${modal.components.length} components, max is 5); }6. 实战排错从api error: 402 insufficient balance到socket connection closed的根因分析Discord Bot 的错误日志里api error前缀让人误以为是 Discord API 问题但 90% 的情况是本地代码或环境导致。我整理了近半年线上事故的根因分布按发生频率排序6.1api error: 402 insufficient balance—— 不是余额不足而是 Token 权限缺失这个错误码HTTP 402在 Discord API 文档中根本不存在。它是discordjs/rest库的自定义错误专指Token 没有对应 endpoint 的权限。例如用client.users.fetch(userId)时Token 没有GuildMembersIntent用channel.send({ files: [...] })时bot 在该频道没有Attach Files权限。定位方法查看错误堆栈中的method和url字段例如POST /channels/123/messages对照 Discord Permissions Docs 确认该 endpoint 需要哪些权限检查 bot 在目标服务器的角色权限设置。提示Discord 的权限是“叠加计算”的。即使 bot 角色有Send Messages但如果频道设置了everyone的Send Messages: Denybot 依然无法发送。必须在频道权限设置页找到 bot 角色单独勾选Send Messages。6.2api error: the socket connection was closed unexpectedly—— 心跳超时的三重检查这个错误不是网络问题而是discord.js的心跳机制失败。Gateway 要求客户端每 41.25 秒发送一次HEARTBEAT如果连续两次未收到HEARTBEAT_ACK就会断开连接。根因有三层第一层Node.js 事件循环阻塞你的代码里有while(true)、JSON.parse(largeString)、或同步文件读取导致事件循环卡死无法发送心跳。→ 解决方案用setImmediate()或Promise.resolve()把耗时操作切片或改用worker_threads。第二层VPS 时间不同步Discord 的心跳包带时间戳如果服务器时间比 Discord 服务器快/慢超过 5 秒心跳会被拒绝。→ 解决方案Ubuntu/Debian 执行sudo timedatectl set-ntp onCentOS 执行sudo systemctl enable chronyd sudo systemctl start chronyd。第三层防火墙拦截 WebSocket某些云厂商如阿里云、腾讯云的安全组默认放行 HTTP/HTTPS但拦截 WebSocket端口 443 上的 ws 协议。→ 解决方案在安全组中添加规则允许TCP:443入方向协议类型选ALL。6.3login failed. check api token—— Token 格式与有效期的双重验证DISCORD_TOKEN不是简单的字符串而是Bot token格式。错误做法.env里写DISCORD_TOKENabc123代码里client.login(process.env.DISCORD_TOKEN)正确做法.env里写DISCORD_TOKENBot abc123或代码里client.login(Bot process.env.DISCORD_TOKEN)。Token 有效期是永久的但会因以下原因失效在 Developer Portal 点击 “Reset Token”bot 账号被封禁如发送垃圾消息所属应用被删除。验证 Token 是否有效用 curl 直接调用 Discord APIcurl -H Authorization: Bot YOUR_TOKEN \ https://discord.com/api/v10/users/me如果返回401 Unauthorized说明 Token 无效如果返回用户信息说明 Token 正常问题在代码逻辑。6.4api error: claudes response exceeded the 32000 output token maximum—— 外部 API 集成的熔断设计这个错误来自 Claude API但出现在 Discord Bot 日志里说明你正在集成第三方 LLM。Discord 消息有 2000 字符限制而 Claude 的 32000 token 输出远超此限。错误做法是直接interaction.reply(claudeResponse)导致RangeError: Maximum call stack size exceeded。正确做法是预估长度Claude 的output_tokens在响应头中返回用response.headers.get(x-ratelimit-remaining)获取截断策略按句子截断而不是按字符。用正则/.?[.!?]/g匹配完整句子分页响应用followUp发送多条消息每条 ≤2000 字符。示例截断函数function truncateToDiscord(text: string, maxLength 2000): string[] { const sentences text.match(/.?[.!?]/g) || [text]; const chunks: string[] []; let currentChunk ; for (const sentence of sentences) { if (currentChunk.length sentence.length maxLength) { currentChunk sentence; } else { if (currentChunk) chunks.push(currentChunk); currentChunk sentence; } } if (currentChunk) chunks.push(currentChunk); return chunks; }7. 进阶实践数据库集成、日志监控与灰度发布策略一个能长期运行的 Bot不能只关注功能实现更要考虑可观测性和可维护性。我负责的社区 Bot 已稳定运行 4 年日均处理 120 万次 Interaction这套运维体系是核心保障。7.1 数据库集成Prisma PostgreSQL 的防坑配置Discord Bot 的数据场景很典型高并发写入如投票记录、低频复杂查询如用户行为分析。我们选 Prisma ORM PostgreSQL但必须绕过三个坑坑一Prisma Client 初始化时机不能在client.on(ready)里new PrismaClient()这会导致每次事件都新建连接池。正确做法是全局单例// prisma/client.ts import { PrismaClient } from prisma/client; const globalForPrisma global as unknown as { prisma: PrismaClient }; export const prisma globalForPrisma.prisma || new PrismaClient(); if (process.env.NODE_ENV ! production) globalForPrisma.prisma prisma;坑二PostgreSQL 连接池溢出Discord 的 burst 流量如抽奖活动会导致瞬间 500 并发写入。PostgreSQL 默认max_connections100Prisma 默认connection_limit10两者叠加会报FATAL: remaining connection slots are reserved for non-replication superuser connections。→ 解决方案在schema.prisma中显式配置generator client { provider prisma-client-js previewFeatures [postgresqlExtensions] } datasource db { provider postgresql url env(DATABASE_URL) // 关键连接池大小必须 ≤ PostgreSQL 的 max_connections relationMode prisma }并在环境变量中设DATABASE_URLpostgresql://user:passhost:5432/db?connection_limit20。坑三Prisma 事务超时Discord 要求 Interaction 必须在 3 秒内响应但 Prisma 的prisma.$transaction()默认超时 15 秒。如果数据库慢bot 会先超时再报错。→ 解决方案所有事务加timeout参数await prisma.$transaction([ prisma.vote.create({ data: {...} }), prisma.user.update({ where: { id }, data: { votes: { increment: 1 } } }) ], { timeout: 2000 }); // 2 秒内必须完成7.2 日志监控Pino Sentry 的错误归因体系console.log在生产环境毫无价值。我们用 Pino 做结构化日志Sentry 做错误追踪关键是要把 Discord 的上下文注入进去import pino from pino; import * as Sentry from sentry/node; const logger pino({ level: process.env.LOG_LEVEL || info, transport: { target: pino-pretty, }, }); // Sentry 初始化 Sentry.init({ dsn: process.env.SENTRY_DSN, tracesSampleRate: 1.0, }); // 为每个 Interaction 创建独立 trace client.on(interactionCreate, async interaction { const span Sentry.startSpan({ op: interaction, name: interaction.isChatInputCommand() ? / ${interaction.commandName} : interaction.isButton() ? button:${interaction.customId} : unknown, }); try { // 你的业务逻辑 } catch (error) { Sentry.captureException(error, { contexts: { discord: { userId: interaction.user.id, guildId: interaction.guildId, channelId: interaction.channelId, } } }); throw error; } finally { span.end(); } });这样在 Sentry 中你能直接看到哪个用户、在哪个服务器、触发了哪个命令、报了什么错错误堆栈精准到node_modules/discord.js/src/structures/Message.js:123。7.3 灰度发布基于 Guild ID
