RAII管理数据库连接的核心原则是构造时获取资源且失败可感知、析构时无条件无异常释放、移动语义正确转移所有权；需用自定义删除器（如判空调用sqlite3_close）替代默认delete，且删除器必须noexcept，避免跨线程析构。
RAII 管理数据库连接句柄的核心原则
RAII 不是“给句柄套个类就行”，而是必须确保：构造函数成功获取资源（且失败可感知），析构函数无条件、无异常地释放资源，且移动语义正确处理所有权转移。数据库句柄（如 SQLite 的 sqlite3*、MySQL 的 MYSQL*）本质是裸指针，直接用 std::unique_ptr 默认删除器会出错——因为它们的释放函数不是 delete，比如 sqlite3_close() 或 mysql_close()。
如何为 sqlite3* 正确实现 RAII 封装
关键在自定义删除器，且要处理空指针和多次 close 的安全问题（SQLite 允许对 nullptr 调用 sqlite3_close()，但某些驱动不保证）。推荐用 lambda 或函数对象作为删除器：
struct sqlite3_deleter {
void operator()(sqlite3* db) const noexcept {
if (db) sqlite3_close(db);
}
};
using sqlite3_ptr = std::unique_ptr<sqlite3, sqlite3_deleter>;
<p>// 使用
sqlite3_ptr db;
int rc = sqlite3_open("test.db", &db);
if (rc != SQLITE_OK) {
// 处理错误，db 仍为空，析构安全
}
-
sqlite3_open()第二个参数是sqlite3**，需传入&db（unique_ptr的地址）才能写入原始指针 - 删除器必须标记为
noexcept，否则unique_ptr在栈展开时可能调用std::terminate - 不要在构造函数里直接调用
sqlite3_open并抛异常——异常发生在构造中会导致对象未完全构建，析构不被调用，资源泄漏
为什么不能直接用 std::shared_ptr 管理连接
共享所有权对数据库连接几乎总是错误选择：
- 多个
shared_ptr持有同一连接时，任意一个析构都会关闭句柄，其余指针变成悬空，后续操作触发未定义行为 - 连接通常有状态（事务、绑定参数、游标位置），共享后无法确定谁该负责 commit/rollback 或重置状态
- 若真需“共享访问”，应封装成线程安全的连接池，由池统一管理生命周期，对外只提供临时会话对象（非共享句柄）
MySQL C API 的 mysql_* 句柄怎么封
模式一致，但注意初始化函数 mysql_init() 返回值可能为 nullptr，且 mysql_close() 不接受 nullptr（会 crash）。所以删除器必须判空，且初始化逻辑不能塞进构造函数：
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
立即学习“C++免费学习笔记（深入）”；
struct mysql_deleter {
void operator()(MYSQL* conn) const noexcept {
if (conn) mysql_close(conn);
}
};
using mysql_ptr = std::unique_ptr<MYSQL, mysql_deleter>;
<p>mysql_ptr conn{mysql_init(nullptr)};
if (!conn) { /<em> 初始化失败 </em>/ }
if (!mysql_real_connect(conn.get(), ...)) { /<em> 连接失败 </em>/ }
// conn 在作用域结束时自动调用 mysql_close
这里 mysql_init(nullptr) 返回新分配的结构体指针，mysql_close() 是唯一合法释放方式；若用 mysql_library_init()，那是全局初始化，不属于单个连接的 RAII 范畴。
最易忽略的一点：所有数据库 C API 的句柄关闭函数，都要求在同一线程调用（尤其是 MySQL 的线程安全版本），跨线程析构 unique_ptr 会导致崩溃——RAII 封装本身不解决线程约束，你得确保对象在创建它的线程销毁。
