应使用 std::shared_ptr，因连接池需共享所有权以支持多线程借用与归还；避免循环引用、裸指针传递和 unique_ptr 误用，并通过自定义删除器与 reset_state() 确保安全复用。
数据库连接池为什么不能直接用裸指针管理
裸指针（DBConnection*）本身不带生命周期语义，无法自动释放连接、无法防止重复释放、也无法表达“共享所有权”或“独占所有权”——而连接池恰恰需要精确控制连接的借用、归还与销毁。用 new / delete 手动管理，极大概率在并发归还、异常提前退出、连接超时回收等场景下导致崩溃或连接泄漏。
应该用什么智能指针？std::shared_ptr 还是 std::unique_ptr
连接池中单个连接对象通常需被多个线程临时持有（比如一个请求借出、处理中、再归还），且池本身要长期持有所有空闲连接，因此必须支持共享所有权：只能用 std::shared_ptr<dbconnection></dbconnection>。但注意：连接对象自身不应持有指向池的 shared_ptr（否则循环引用，池永远不析构）；归还连接时，只需调用池的 return_connection() 方法，让池把 shared_ptr 放回空闲队列即可。
常见错误：
- 用
std::unique_ptr—— 无法安全地将连接“借出”给业务逻辑，因为转移后池就失去控制权 - 在
DBConnection类里存一个std::weak_ptr<connectionpool></connectionpool>用于回调 —— 可以，但必须检查lock()是否成功，否则访问已销毁池会 crash - 把
shared_ptr存进std::queue后，又用get()提取裸指针传给业务层 —— 丢失 RAII 保证，等于退回裸指针陷阱
连接对象如何确保归还时自动重置状态
DBConnection 类必须定义明确的“可重用”契约：构造时初始化，析构时清理（如关闭 socket），但归还到池时不能析构——所以要在 shared_ptr 的自定义删除器或池的 return_connection() 中显式调用 reset_state()。
立即学习“C++免费学习笔记（深入）”；
实操建议：
- 不要依赖
shared_ptr的默认删除器来“关闭连接”，那意味着连接永久销毁；而是让删除器只做资源释放（如mysql_close()），池自己维护空闲连接列表 - 在
DBConnection构造函数里完成底层句柄创建（如mysql_init()），在reset_state()里执行mysql_ping()+ 清空结果集 + 重置字符集等轻量复位操作 - 如果使用 OpenSSL 或 TLS 连接，
reset_state()还需调用SSL_shutdown()并重置 SSL 对象，否则下次复用可能握手失败
多线程环境下获取连接的典型写法和坑
最简可行模式是池暴露一个线程安全的 acquire() 方法，返回 std::shared_ptr<dbconnection></dbconnection>；内部用 std::mutex + std::queue 管理空闲连接。但要注意：
- 避免在
acquire()中长时间持锁：先尝试 pop，失败则创建新连接（受最大连接数限制），创建过程必须在锁外进行 - 不要用
std::shared_ptr::operator bool()判断连接是否有效——它只判断指针是否为空；真正可用性需调用connection->is_alive()（内部做mysql_ping()） - 业务代码拿到
shared_ptr后，若发生异常未归还，连接会随作用域结束自动析构——但此时应触发池的“坏连接检测”逻辑，而非静默丢弃；建议在删除器中记录日志并标记连接为失效
一个最小化 acquire 示例：
auto conn = pool.acquire();
if (!conn || !conn->is_alive()) {
// 处理获取失败，不要继续用
return;
}
// 使用 conn->execute("SELECT ...")
// 无需手动归还：conn 离开作用域自动释放引用计数
// 池在引用数降为 0 且确认连接健康时，将其放回空闲队列
真正难的是连接健康检查的时机和粒度——太频繁影响性能，太懒惰导致业务拿到已断连。这个平衡点得结合具体驱动（MySQL C API / libpq / sqlite3）和网络环境调。
