连接池的核心是连接生命周期管理，而非简单容器；必须实现超时回收、空闲驱逐、健康检查与异常剔除，通过RAII+智能指针+定时/懒检查组合保障安全复用。
连接池的核心不是“池”，是连接的生命周期管理
直接用 std::vector 存一堆已创建的 std::shared_ptr 不算真正连接池——它没解决超时回收、空闲驱逐、异常连接自动剔除这些关键问题。真正的难点在：谁负责释放？什么时候释放？释放前要不要做健康检查？
推荐以 RAII + 智能指针 + 定时任务（或懒检查）组合实现，避免裸指针和手动 delete。
- 连接对象必须自己知道是否还可用（比如提供
isValid()或ping()） - 池本身不持有连接所有权，只管理“可复用连接”的引用；实际所有权交给
std::shared_ptr，由使用者作用域决定何时归还 - 不要在
returnConnection()里直接 close()，而应标记为 idle 并延迟清理——否则高并发下可能刚归还就被其他线程取走，造成 double-close
怎么让获取连接不阻塞又不无限创建
典型错误是写成「没空闲就 new 一个」，结果突发流量打垮后端。必须设硬上限 + 等待策略。
关键参数只有三个：maxIdle（池中最多缓存几个空闲连接）、maxTotal（整个池最多存在几个连接）、maxWaitMs（获取超时）。
- 用
std::condition_variable+std::mutex实现带超时的等待：当空闲队列为空且当前总数已达maxTotal，调用wait_for() - 返回
std::unique_ptr而非裸指针——确保使用者离开作用域时自动触发归还逻辑（通过自定义 deleter 调用池的returnConnection()） - 别用
std::queue存空闲连接：它不支持 O(1) 随机剔除最老连接；改用std::list+ 迭代器维护 LRU，或加时间戳字段配合std::set排序
MySQL / PostgreSQL 客户端库怎么适配进连接池
不同驱动对连接复用的支持差异极大。libpq（PostgreSQL）默认允许复用，但 MySQL Connector/C++ 8.0+ 的 sql::Connection 对象不是线程安全的，不能跨线程共享。
- 确认底层连接对象是否可重入：比如
mysql_real_connect()后的MYSQL*可以复用，但必须保证同一时刻只有一个线程使用它 - 不要把连接池做成单例全局暴露——而是每个数据库实例（host:port + db）配一个独立池，避免混用导致认证上下文错乱
- 归还连接前务必执行
rollback()和resetSession()（如支持），否则事务状态或变量设置会污染下一个使用者 - 若用
boost::asio异步连接，池里存的得是boost::asio::ip::tcp::socket+ 自定义状态机，不能直接扔裸 socket
为什么不用现成的连接池库反而要自己写
因为大多数开源 C++ 连接池（如 ctre、soci 自带的）只覆盖基础场景，一旦涉及 TLS 双向认证、连接级负载均衡、SQL 注入级连接隔离（比如按 tenant_id 分桶），就必须侵入修改。
自己写的轻量池（200 行内）反而可控：
- 可以 hook 每次 checkout 前的
ping()，失败则静默丢弃并新建，不影响上层逻辑 - 归还时记录耗时，自动统计 P95 连接获取延迟，方便定位慢 SQL 是否卡在连接层
- 支持热更新配置：运行时调整
maxIdle，老连接自然淘汰，新请求按新规则分配
真正麻烦的从来不是“怎么建池”，而是连接失效的边界情况——比如网络闪断后 TCP 连接处于 CLOSE_WAIT 状态，isValid() 返回 true，但第一次 query 就报 Broken pipe。这种必须靠首次 query 失败后主动从池中移除该连接，不能依赖定时扫描。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
