Google Pub/Sub拉取模式致服务每分钟重启 移除监听器必要性咨询

一、Express服务每分钟重启的根因 #

• 直接触发进程崩溃的逻辑：代码里的错误处理器实现存在硬伤——捕获Pub/Sub运行错误后直接抛出未捕获异常。Node.js运行时会把事件监听器里抛出的未捕获异常直接作为致命错误，终止整个进程。如果你的Express服务是用PM2、Docker自动重启策略、热重载工具启动的，进程被打崩后就会被自动拉起，表现为周期性重启。
• 为什么重启周期刚好是1分钟：你观察到每分钟都会打印subscription ${subscriptionPub.name} found的日志，说明pubsub()函数正被以1分钟为周期重复执行。常见的错误调用场景包括：主入口代码误把pubsub()放在setInterval定时回调里、模块热重载配置将该模块按固定周期重复加载。每次执行这个函数都会新建Subscription实例、绑定全新的事件监听器，重复积累的监听器很快会触发grpc连接冲突、流控超限等运行错误，直接走到抛错逻辑打崩进程。
• 哪怕你已经注释了setTimeout相关逻辑，只要pubsub()函数仍在被每分钟重复调用，就会持续积累无效监听器，最终触发错误导致重启。

二、原代码中定时移除监听器的设计初衷 #

• 这个设计从根上就不是面向生产环境常驻服务的实现，本质是照搬了Google Cloud Pub/Sub拉取模式的临时调试示例的逻辑：原作者本来想做的是"启动监听60秒拉取消息，到点就断开释放资源"的短周期测试逻辑，根本没打算实现长期运行的常驻消费者。
• 他写removeListener的核心目的，是为了弥补自己"重复调用pubsub()绑定监听器"的设计缺陷：如果每次调用函数都给Subscription绑定新的message/error监听器，不做清理的话，几次调用后同一个订阅对象上会挂N个重复监听器，导致同一条消息被重复消费N次、grpc连接资源泄漏。他本来想靠60秒的定时任务清掉上一次的监听器，避免重复绑定的问题。
• 这个设计本身是冗余且错误的：常驻Pub/Sub消费者只需要在服务启动时绑定一次监听器，长期持有订阅连接即可，完全不需要定期移除、重绑监听器，这类操作反而会导致消息漏消费、连接抖动的问题。

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