Discord机器人短时间内连接超1000次被重置token及报错排查

代码存在多处会触发进程崩溃的低级错误，配合托管环境默认开启的进程自动重启策略，会形成「崩溃→自动拉起→重新连Discord→再次崩溃」的死循环，短时间内触发上千次连接请求，最终被Discord风控拦截重置token。

• 事件绑定写法错误：所有client.on()调用的末尾，都多余附加了, (err, data)参数。Node.js的事件监听接口仅接收「事件名称、回调函数」两个入参，这部分多余参数没有任何实际作用，反而会误导你以为已经配置了错误捕获逻辑。
• 消息逻辑存在未定义变量问题：消息事件的回调入参定义为message，但函数内部判断命令触发条件时，却使用了从未定义的msg变量。只要收到任意符合事件触发条件的消息，就会抛出引用错误。
• 异步错误完全脱离管控范围：fs.readFile的回调是异步执行的，外层的try-catch根本捕获不到这个回调内部抛出的错误。一旦出现文件路径错误、权限不足、文件为空等问题，回调内的if(err) throw err会直接冒泡为全局未捕获异常，直接打崩整个Node进程。
• 依赖版本兼容失效：日志里记录的TypeError: Cannot read property 'id' of undefined，是因为当前安装的discord.js版本过老，无法正常解析Discord最新网关返回的GUILD_CREATE数据包结构，读取空值属性时直接触发崩溃，进一步加快崩溃循环的频率。

• 删掉所有client.on()末尾附带的, (err, data)片段，修正事件绑定的调用方式
• 统一消息回调的变量命名，将命令判断逻辑里的msg替换为实际入参message
• 移除fs.readFile回调内的throw err逻辑，改为在回调内部捕获并打印具体错误栈，避免异步错误直接导致进程崩溃
• 升级discord.js到当前稳定版本，消除网关协议不兼容带来的解析崩溃
• 暂时关闭托管环境的进程自动重启策略，手动启动机器人观察运行状态，确认无随机崩溃问题后，再重新开启守护机制

你当前推测托管商连接方式存在问题的方向可以交叉验证，但从现有代码缺陷来看，哪怕托管商本身连接逻辑没有问题，只要代码bug导致进程反复崩溃重启，同样会触发Discord的重连风控阈值。

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