sqlite连接池不能直接用std::shared_ptr，因为sqlite3句柄本身非线程安全，多线程并发调用sqlite3_exec等函数会引发未定义行为；连接池应管理独立连接实例而非共享句柄。
SQLite连接池为什么不能直接用 std::shared_ptr？
因为 sqlite3 句柄本身不是线程安全的——哪怕你用 std::shared_ptr 包一层，多个线程同时调用 sqlite3_exec 或 sqlite3_prepare_v2 仍会触发未定义行为。SQLite 的线程模式（SQLITE_THREADSAFE）默认是 1（serialized），但单个连接句柄仍不允许并发访问。所以“池”不是共享句柄，而是管理一组独立、可复用的连接实例。
如何避免 sqlite3_open 多次调用导致的性能瓶颈？
每次 sqlite3_open 都涉及磁盘 I/O 和锁协商，尤其在 WAL 模式下还会触发 journal 文件检查。连接池必须预热初始化一批连接，而不是按需创建：
- 启动时用
sqlite3_open_v2配合SQLITE_OPEN_FULLMUTEX标志打开连接，确保每个句柄可被安全地跨线程移交（但不并发使用） - 连接创建后立即执行
PRAGMA journal_mode = WAL和PRAGMA synchronous = NORMAL，避免后续每次查询都重复设置 - 用
std::queue<:unique_ptr>></:unique_ptr>存储空闲连接，配合std::mutex保护队列操作，不要用std::vector+ 索引轮询——后者在高并发下易造成锁争用
连接获取/归还时怎样防止泄漏和死锁？
典型错误是忘记归还连接，或在异常路径中提前 return 导致 sqlite3_close 被跳过。必须用 RAII 封装：
- 定义一个
ConnectionGuard类，构造时从池中pop连接，析构时自动push回池；它的移动构造函数要置空源对象的指针，避免 double-return - 禁止用户直接持有
sqlite3*：所有 API 只接受ConnectionGuard&&或通过 lambda 回调传入连接，例如pool.with_connection([](sqlite3* db) { ... }); - 归还连接前必须调用
sqlite3_reset和sqlite3_clear_bindings清理预编译语句状态，否则下次复用可能因残留绑定参数而失败
为什么 SQLite 连接池不适合高并发写场景？
SQLite 的写锁是数据库级的，哪怕你有 10 个连接，同一时刻也只有一个能执行 INSERT/UPDATE。连接池在此类场景下只能缓解连接建立开销，无法提升吞吐。真正需要的是：
- 读多写少时，用连接池 + WAL 模式 +
PRAGMA read_uncommitted = 1提升读并发 - 写密集场景，应考虑分库（如按用户 ID 哈希到多个 DB 文件）或切换到 MySQL/PostgreSQL
- 如果硬要用 SQLite 写，务必把多个 DML 合并在一个
BEGIN...COMMIT事务里，否则每个语句都触发一次锁协商
连接池本身不解决 SQLite 的底层限制，它只是让“等待连接”这个环节更可控——但别指望它把单机嵌入式数据库变成分布式服务。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
