Diagnoses database connection …

# Cloudflare Workers + Supabase 连接报错排查指南

一、先判断：大概率不是“池耗尽”，而是这两个根因

Workers 与传统服务器不同，请先确认架构特点：

• Workers 无法维持长连接：每次请求结束时，连接可能被终止，长连接复用并不可靠
• Supabase 直连（端口 5432）用的是 Postgres 协议，与 Workers 的无状态模型天然冲突，偶发断连正符合此症状
• 每200次出现3次（约1.5%失败率）的“随机性断连”，典型指向 连接数超限或直连模式不匹配

二、排查步骤

1. 检查是否直连了数据库

• 查看代码连接串：如果是 db.xxx.supabase.co:5432（直连），这就是高概率原因
• Workers 高并发下直连会迅速占满 Supabase 连接上限（免费版上限较小，具体数值以你的套餐后台显示为准）

2. 确认 Supabase 连接数占用

• 进入 Supabase Dashboard → Database → 查看当前活跃连接数
• 若活跃连接数接近上限，说明池/配额耗尽
• 用 SQL 查询：SELECT count(*) FROM pg_stat_activity; 确认各状态连接分布

3. 检查连接是否正确关闭

• Workers 中若每次请求都 new Client() 而不 close，连接会累积泄漏
• 排查代码：确保 finally 块中有 await client.end()

三、解决方案（按优先级）

方案1：改用 Supabase 连接池（首选）

• 使用 Supavisor Pooler 连接串（端口 6543，Transaction mode）
• 连接串形如：xxx.pooler.supabase.com:6543
• Transaction 模式专为 Serverless 设计，可大幅缓解连接数问题

方案2：使用专门适配 Workers 的驱动

• 推荐用 Postgres.js（postgres npm 包）或 Supabase 官方 JS 客户端，它们对 Serverless 环境支持更好
• 避免使用 pg（node-postgres）裸 TCP 连接

方案3：增加容错

• 对数据库操作加重试逻辑（针对该错误码重试1-2次，指数退避）
• 设置合理超时，避免悬挂连接占用配额

四、验证修复

• 部署后压测观察：若失败率降至接近0，说明是连接模式问题
• 持续监控 Supabase Dashboard 的连接数曲线，确认无泄漏

总结：1.5%的随机断连 + Workers 环境组合，最大嫌疑是直连5432端口导致连接数超限或连接被中途回收，改用 6543 端口的连接池模式 + Postgres.js 是最直接的解法。