Jest调用node-postgres的pool.query报TLSWRAP句柄未关，为何前置setTimeout可修复

问题根因 #

这个反直觉的现象本质是数据库连接池的懒初始化逻辑和Jest的生命周期执行时机不匹配导致的，具体逻辑如下：

• 你用到的queries模块内部的数据库连接池是懒加载模式：不会在模块导入时就完成初始化，而是第一次调用查询方法时才会触发连接池创建、TCP连接建立、内部句柄绑定等一系列异步后台操作。
• 无前置延迟时，测试执行速度远快于连接池初始化速度：查询返回结果、断言完成、afterAll中调用pool.end()的时候，连接池的初始化流程还没完全跑完，很多后台异步创建的连接、套接字句柄还没挂载到pool实例上，此时的pool.end()无法遍历关闭这些未注册的资源，就会残留未释放的句柄，被Jest检测到警告。
• 前置延迟刚好等完了连接池的所有初始化逻辑：你延迟2秒后再调用查询，此时连接池已经完全就绪，所有后续创建的连接都会被pool实例托管，afterAll执行pool.end()时就能完整关闭所有资源，不会残留句柄。
• 后置延迟/afterAll内加延迟无效的原因：第一次查询触发懒初始化后，部分数据库驱动的连接池扩容、句柄绑定逻辑是和查询请求异步解耦的——哪怕查询结果已经返回，后台初始化逻辑还在执行，此时不管是在查询后加延迟还是在afterAll里加延迟，调用pool.end()时依然会漏掉还没完成注册的资源，自然无法解决问题。

更稳定的替代方案 #

硬编码延迟属于不可靠的hack方案，你可以用以下方法彻底解决问题：

• 在beforeAll钩子中主动触发一次无副作用的查询（比如SELECT 1），等返回结果后再启动测试，保证跑业务测试前连接池已经完成初始化
• 关闭连接池的懒加载配置，在导入queries模块时就显式等待连接池初始化完成
• 如果确认生产环境连接释放逻辑无问题，也可以在Jest配置中添加detectOpenHandles: false临时屏蔽该类警告（不推荐，可能漏掉真实的资源泄漏问题）

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