连接池不能直接用std::queue<unique_ptr<Connection>>，因无法预检连接有效性且不支持条件出队；应改用deque/vector配合ping检查、shared_ptr+自定义deleter、带超时的wait_for、线程内闭环使用、非阻塞关闭及RAII防护。
connection pool 为什么不能直接用 std::queue<std::unique_ptr<Connection>>
因为连接在归还时可能已失效（网络断开、超时、服务端 kill），而 std::queue 不支持带条件的出队；更关键的是，你无法在 pop 前检查连接是否可用，导致线程拿到坏连接后才报错，掩盖真实问题点。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 用
std::deque或std::vector存储连接指针，配合自定义获取逻辑（比如遍历 +ping()检查） - 归还连接前必须调用
Connection::is_alive()或执行轻量PING查询，失败则丢弃不入池 - 避免把
std::unique_ptr直接塞进容器——归还时需转移所有权，但池要能复用对象内存，推荐用std::shared_ptr<Connection>+ 自定义 deleter 触发回收逻辑
如何避免多线程下 get_connection() 阻塞死等
阻塞等待池空是常见错误，尤其在突发流量下所有线程卡在 wait_for() 上，最终拖垮整个服务。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- get_connection() 必须带超时参数，例如
std::chrono::milliseconds(500)，超时后抛出std::runtime_error("connection timeout") - 不要用
std::condition_variable::wait()无条件等待，改用wait_for()并检查pool_size > 0和available_count > 0两个状态 - 考虑实现“快速失败”分支：当当前空闲数为 0 且活跃连接数已达上限，直接返回错误，不进等待队列
MySQL / PostgreSQL 的 connection 对象能否跨线程复用
不能。libmysqlclient 和 libpq 的 Connection 对象内部含非线程安全的缓冲区和状态机，跨线程使用会触发未定义行为，典型表现是 segfault 或查询返回乱码。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 每个线程从池中获取的
Connection*只能在该线程内调用execute()、query()等方法 - 禁止在线程间传递裸指针或
shared_ptr后在另一线程调用其方法 - 若需异步查询，应在获取连接的同一线程启动 async task，并在回调中完成归还（即“获取-使用-归还”闭环在线程内完成）
析构时如何安全关闭所有连接而不卡住
析构函数里逐个调用 close() 可能因网络延迟阻塞数秒，尤其当池中还有未归还连接时，~ConnectionPool() 变成不可控耗时点。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 在析构前先调用
shutdown()方法：置标志位、唤醒所有等待线程、拒绝新请求 - 对池中剩余连接，用非阻塞方式 close（如 MySQL 的
mysql_close()是同步的，但可提前设SO_LINGER缩短 FIN_WAIT） - 记录日志警告“仍有 X 个连接未归还”，这说明业务代码漏了
return_connection()，比静默关闭更利于定位问题
最麻烦的其实是连接泄漏 —— 它不会立刻报错，但会让池慢慢变僵，直到某次 get_connection() 超时。别依赖析构兜底，得靠 RAII wrapper（比如 ConnectionGuard）强制归还。
