用途：审计数据库连接管理，定位连接耗尽风险，属于性能与扩展性（performance）维度，对应关系型 Pooling w10 及 NoSQL 的 Conexión 类别。
主要能力：检查三类问题。一是无服务器直连 Postgres——函数或边缘运行时（Vercel/Lambda/Cloudflare/Netlify）不经连接池直连，每次冷启动开一条连接，并发峰值会突破 max_connections，建议改用事务模式连接池或无服务器驱动（Neon/@neondatabase/serverless、Supabase pooler、PlanetScale HTTP）。二是事务模式连接池误用——使用事务池端点（PgBouncer transaction 模式、Supabase 6543 端口）却依赖其会破坏的会话特性：服务端预处理语句、SET/会话 GUC、LISTEN/NOTIFY、会话级咨询锁。三是池容量——应用池上限乘以实例数超过后端 max_connections，或池过小导致请求串行化。
容量建议：服务端连接上限约为 vCPU 的小倍数，而非峰值并发；以 (cores*2) + effective_spindles 作为服务端有效繁忙连接上限，客户端池按此上限而非峰值并发设置，多余连接只会增加上下文切换与锁竞争，应在池层排队。需在 max_connections 下预留余量（含 superuser_reserved_connections 及其他应用/复制空间）。PgBouncer 事务模式可将大量客户端连接复用到少量后端连接，但会破坏上述会话级特性。
使用方式：Tier-0 静态检测运行时标记与客户端驱动（pg、postgres、@neondatabase/serverless、@prisma/client、连接 URL 主机/端口），标记无服务器直连、6543 端口或 pgbouncer=true 与预处理语句并用、池配置问题；后端 max_connections 与实时连接数属运行时，Tier-0 需 needs_api。Tier-1 验证查询：SELECT current_setting('max_connections') AS max_conn, count() AS open_conns, count() FILTER (WHERE state = 'idle') AS idle FROM pg_stat_activity; 方法为 connection_introspect。
发现项示例：M15.app.serverless_direct_pg（severity 4，warn，directional，fixable: proposed）、M15.app.prepared_stmt_on_txn_pooler（severity 3）、M15.app.pool_exceeds_max_connections（severity 3）。每条发现需在 evidence.observed 中原样引用连接配置或驱动导入并脱敏凭据，verification.reproduce 引用 $DATABASE_URL，expected_impact 按区间并标注置信度。
限制：长生命周期服务器（单个 Node/Rails 进程）配合理池直连没有问题，无服务器直连发现仅适用于按调用启动的运行时；不可引用无法观测的连接数或故障概率，耗尽结论需 Tier-1/2 才成立；所有修复均为配置/架构建议，不自动执行。