sqlite c++绑定首选原生c接口sqlite3.h，因其最稳定可靠；第三方封装库多为薄包装，易隐藏错误、引发资源泄漏或abi问题，且不受官方支持。
SQLite C++绑定选哪个：sqlite3.h原生API最稳
直接用C接口sqlite3.h是C++项目接入SQLite最可靠的方式。别被各种C++封装库（如SQLiteCpp、nanodbc）劝退——它们本质只是对sqlite3_prepare_v2、sqlite3_step这些C函数的薄包装，反而可能隐藏错误码处理细节或引入ABI兼容问题。
常见错误现象：sqlite3_exec返回SQLITE_OK但实际没写入数据，往往是因为没检查sqlite3_changes()；或者用std::string传参给sqlite3_bind_text时忘了用.c_str()和.length()，导致空指针或乱码。
- 必须包含头文件：
#include <sqlite3.h></sqlite3.h>，链接时加-lsqlite3 - 打开数据库后立即检查返回值：
int rc = sqlite3_open("db.db", &db); if (rc != SQLITE_OK) { /* 处理错误 */ } - 所有SQL执行前优先用
sqlite3_prepare_v2预编译，避免SQL注入；不用sqlite3_exec拼接字符串
参数绑定怎么写才不出错：用sqlite3_bind_*系列函数
手动拼接SQL字符串（比如"INSERT INTO users VALUES (" + name + ")"）在C++里极其危险，既容易SQL注入，又难处理单引号、NULL字节等边界字符。正确做法是用占位符+绑定。
使用场景：插入用户信息、查询带条件的记录、批量更新数值字段。
- 占位符写法只认
?、?1、:name、@name四种，不要混用；推荐统一用?序号绑定 - 绑定文本时用
sqlite3_bind_text(stmt, 1, str.c_str(), -1, SQLITE_TRANSIENT)，注意第四个参数传-1让SQLite自动测长度 - 绑定整数用
sqlite3_bind_int(stmt, 2, age)，不要转成字符串再bind - 执行完
sqlite3_step后必须调用sqlite3_reset才能复用stmt，否则下次step会失败
事务控制的关键点：BEGIN IMMEDIATE比BEGIN更实用
默认的BEGIN是DEFERRED模式，真正执行第一条语句时才加锁，高并发下容易触发SQLITE_BUSY。多数业务需要的是立即排他锁，防止其他连接同时修改同一张表。
性能影响：用BEGIN IMMEDIATE能提前暴露冲突，避免长事务回滚；但也会略微增加首次执行延迟。
- 显式开启事务：
sqlite3_exec(db, "BEGIN IMMEDIATE", nullptr, nullptr, &err_msg) - 成功后执行多条
sqlite3_step，全部完成再sqlite3_exec(db, "COMMIT", ...) - 出错时必须
sqlite3_exec(db, "ROLLBACK", ...)，否则连接处于不可用状态 - 不要依赖RAII自动提交——SQLite不管理C++对象生命周期，
std::unique_ptr无法感知SQL级事务状态
内存管理和错误检查不能省：每步都查rc
SQLite的C API几乎每个函数都返回int错误码，SQLITE_OK以外的值（比如SQLITE_BUSY、SQLITE_LOCKED、SQLITE_SCHEMA）必须明确处理，否则程序看似运行但数据已损坏。
容易踩的坑：把sqlite3_column_text返回的指针存为std::string成员变量，结果stmt重置后指针失效；或者忽略sqlite3_finalize导致内存泄漏（尤其在循环中反复prepare时）。
- 读取结果列时，先用
sqlite3_column_type判断类型，再用对应取值函数，避免sqlite3_column_text对NULL字段返回空指针却未判空 - 每次
sqlite3_prepare_v2后，无论成功失败，都要配对调用sqlite3_finalize - 数据库连接关闭前确保所有stmt已finalize，否则
sqlite3_close可能返回SQLITE_BUSY
SQLite的C接口看着低-level，但正因如此，每一步控制权都在你手里。最麻烦的不是语法，而是那些不报错却悄悄失效的操作——比如忘记reset就复用stmt，或者bind时传了临时字符串的c_str()却没用SQLITE_TRANSIENT标记。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
