RAII封装数据库连接需构造时调用mysql_real_connect或sqlite3_open并失败抛异常，析构时无异常调用close、显式回滚活跃事务，禁用拷贝，避免多线程复用，并用专用类而非std::unique_ptr管理以处理语句、事务等状态耦合。
用 RAII 封装 mysql_real_connect 或 sqlite3_open 调用
裸调数据库连接函数（比如 mysql_real_connect 返回 MYSQL*，sqlite3_open 返回 sqlite3*）极易导致忘记关闭、异常跳过清理、或提前释放后继续使用。C++ 正确做法是把连接句柄包装进一个类，构造时连接，析构时自动断开。
关键点：
- 构造函数里调用底层 API，失败则抛异常（不要返回
nullptr让调用方自己判） - 析构函数必须无异常地调用
mysql_close或sqlite3_close；若底层 close 可能失败（如 MySQL 的mysql_close不检查连接状态），至少要assert或记录日志，但绝不能让异常逃出析构函数 - 禁用拷贝（
= delete拷贝构造和赋值），移动语义可选支持——多数场景下连接不共享，移动反而增加复杂度
避免在多线程中复用同一个 MYSQL* 实例
MySQL C API 的 MYSQL* 连接对象不是线程安全的：它内部缓存了命令缓冲区、结果集指针等状态。多个线程并发调用 mysql_query 或 mysql_store_result 会导致内存越界或静默数据错乱。
常见错误现象：
立即学习“C++免费学习笔记（深入）”；
- 偶发
Segmentation fault在mysql_store_result内部 - 查询返回空结果，但
mysql_errno是 0（说明状态被别的线程污染） - 同一连接上连续两个
mysql_query，第二个返回 “Commands out of sync” 错误
正确做法是每个线程持有一个独立的 DatabaseConnection 对象，或用连接池按需分配/归还——别试图“省开销”而复用。
事务未提交就析构连接？sqlite3_close 不会帮你回滚
SQLite 的 sqlite3_close 仅释放句柄和内存，**不会隐式提交或回滚当前事务**。如果连接对象在事务中途被销毁（比如函数提前 return、异常抛出），且没显式调用 sqlite3_exec(db, "ROLLBACK", ...)，事务将处于悬挂状态，下次打开数据库时可能看到不一致数据（尤其 WAL 模式下更隐蔽）。
实操建议：
- 在连接类析构前，检查
sqlite3_get_autocommit(db)返回 0（表示事务活跃），若是，则强制执行sqlite3_exec(db, "ROLLBACK", nullptr, nullptr, nullptr) - 更稳妥的是：把事务控制单独封装成
TransactionGuard类，作用域结束时自动 commit/rollback，而不是依赖连接析构 - MySQL 同理：
mysql_close也不回滚，但 MySQL 默认 autocommit=1，所以风险略低；若手动SET autocommit=0，同样需防护
std::unique_ptr 管理连接不够用，得重载删除器
有人想图省事用 std::unique_ptr<mysql void></mysql>，但这是危险的捷径。问题在于：
- MySQL 的
mysql_close接受MYSQL*，但要求该指针必须由mysql_init或mysql_real_connect创建；若传入 null 或已 close 过的指针，行为未定义 - SQLite 的
sqlite3_close要求先调用sqlite3_finalize所有未完成的语句，否则可能泄漏或崩溃 - 删除器无法感知连接是否已失效、是否有未释放的 statement、是否在事务中
结论：简单 wrapper 比通用智能指针更可控。删除器只适合资源释放逻辑完全正交、无状态依赖的场景（如 FILE*），数据库连接不符合这个条件。
真正容易被忽略的，是连接对象生命周期与事务边界、语句对象、结果集对象之间的耦合关系——它们不是独立资源，而是一组协作状态。只管“连接”本身，不管其他，迟早掉坑里。
