连接获取失败时应在 think\db\Connection::connect() 中捕获 PDOException 并写入结构化日志（含 host、port、code、msg），通过继承重写类并在 database.php 中配置替换，避免全局异常处理器或业务层捕获，确保告警及时准确。
连接池获取失败时怎么触发告警
ThinkPHP 本身不内置数据库连接池，所谓“连接池”实际是 PDO 连接复用 + 连接管理器（ConnectionManager）在底层维护的连接缓存。真正出现“获取连接失败”，通常是 pdo::connect() 抛出异常，或连接数耗尽、超时、认证失败等导致 Connection::getPdo() 返回 null / 抛出 PDOException。
关键不是加个“池”，而是拦截连接建立环节的失败信号：
- 在
think\db\Connection的connect()方法中 catch 异常后，立刻调用告警逻辑（如发 HTTP 请求到运维接口、写本地日志并触发 logrotate 监控） - 不要依赖
Db::table()->select()报错再告警——那已是业务层，错过连接建立阶段的原始上下文 - 避免在中间件或全局异常处理器里统一捕获——PDO 异常可能被上层 try/catch 吞掉，或发生在模型初始化前，不可靠
如何在 connect() 失败时写入可监控日志
ThinkPHP 的 Connection 类在 connect() 方法中会调用 $this->createPdo()，这里就是埋点位置。直接修改 vendor 不推荐，应通过继承 + 配置替换实现：
- 新建类
App\Db\MonitoredConnection继承think\db\Connection - 重写
connect()：在父类调用前后加日志记录，尤其 catchPDOException时写入含host、port、errorInfo的结构化日志行 - 在
config/database.php中将'type' => 'mysql'改为'type' => \App\Db\MonitoredConnection::class - 日志格式建议包含字段：
[db_connect_fail] host=10.0.1.5 port=3306 code=1040 msg="Too many connections"，方便 ELK 或 Prometheus+Filebeat 提取指标
告警触发后要不要自动降级
连接获取失败 ≠ 全站不可用，但盲目降级（比如切到 Redis 缓存兜底）容易掩盖真实问题，甚至引发数据不一致。
立即学习“PHP免费学习笔记（深入）”；
更务实的做法是分场景控制：
- 读操作失败：可短暂返回 503 + Retry-After，不自动切缓存——缓存可能过期或未预热
- 写操作失败：必须中断，不能静默丢弃；记录完整 SQL 和绑定参数，供后续人工补偿
- 连续 3 次
connect()失败（10 秒内），才触发开关关闭该库写入口，并发通知；避免单次网络抖动误判 - 告警内容里必须带
connection_id（如果 PDO 支持）或当前请求request_id，否则运维无法关联链路追踪
为什么不用 Swoole 协程连接池就很难做可靠告警
ThinkPHP 默认是同步阻塞模型，connect() 超时由 PDO 的 PDO::ATTR_TIMEOUT 控制，一般设为 3–5 秒。这个时间窗口内，你只能等，无法主动探测连接池健康状态。
而 Swoole 的 Coroutine\MySQL 或 co\Pool 可以：
- 在
get()时检测连接是否 alive（发 ping 包） - 配置
minIdle/maxIdle，空闲连接自动回收，避免 stale connection 积压 - 配合
beforeGet回调，在每次取连接前执行轻量健康检查 - 但注意：Swoole 模式下
think-swoole扩展的连接管理与原生 TP 数据库类不完全兼容，Connection::getPdo()可能返回协程 MySQL 对象而非 PDO 实例，告警逻辑要适配类型判断
没上 Swoole 就老实用超时+重试+日志+人工响应，别硬套“连接池”概念给自己加戏。连接获取失败的本质，从来不是技术名词，而是数据库服务端是否可达、凭证是否有效、资源是否被占满——盯住这三件事，比堆代码重要得多。
