sqlite3_prepare_v2必须返回SQLITE_OK才能安全绑定，否则stmt可能为空或无效；需检查返回值、确保stmt有效、占位符规范、内存生命周期可控，并调用sqlite3_step执行。
sqlite3_prepare_v2 必须返回 SQLITE_OK 才能继续绑定
很多人在调用 sqlite3_prepare_v2 后直接进 sqlite3_bind_text，结果程序崩溃或返回随机值。根本原因是没检查返回值——如果 SQL 语法错误、表不存在、列名拼错，sqlite3_prepare_v2 会返回 SQLITE_ERROR 或 SQLITE_MISUSE，此时 sqlite3_stmt* 可能为 nullptr 或无效句柄，后续绑定必然失败。
必须做这三件事：
- 检查
rc == SQLITE_OK，否则用sqlite3_errmsg(db)看具体哪错了 - 确保传入的
sqlite3_stmt**指针非空且未被提前finalize - 占位符只能用
?（位置参数）或@name/:name（命名参数），不能混用，也不能写成${user}或%s
绑定时内存生命周期必须可控
常见崩溃点：用局部 std::string 的 c_str() 绑定后，字符串对象提前析构，导致 sqlite3_step 读到野指针。SQLite 不会自动拷贝你传入的字符串内容，除非你明确告诉它。
关键参数是 sqlite3_bind_text 的第四个参数（n）和第五个参数（destructor）：
-
n = -1表示按\0截断，SQLite 内部会做一次strlen + memcpy -
destructor = SQLITE_TRANSIENT（推荐）：SQLite 自行管理内存副本，最安全 -
destructor = SQLITE_STATIC：仅当你保证原始内存在整个语句生命周期内有效时才可用（比如全局 C 字符串字面量） - 对
sqlite3_bind_int/sqlite3_bind_double这类值类型，无内存生命周期问题，但要注意类型误用（如把时间戳字符串误用bind_int，结果变成 0）
参数绑定后必须调用 sqlite3_step 才真正执行
绑定只是“填空”，不触发任何数据库操作。很多新手以为绑完就查完了，其实还差最关键一步：sqlite3_step(stmt)。它才是真正让 SQLite 走执行计划、读磁盘、返回结果的函数。
注意几个典型返回值：
-
SQLITE_ROW：有数据行，可配合sqlite3_column_*()取值 -
SQLITE_DONE：语句执行完毕（如 INSERT/UPDATE 成功，或 SELECT 无结果） -
SQLITE_BUSY：数据库被锁，需重试或加超时逻辑 - 永远别忽略返回值——直接跳过
sqlite3_step或只检查是否为SQLITE_OK是常见疏漏
事务内批量绑定要复用同一个 sqlite3_stmt*
单条 INSERT 绑定一次就 finalize，性能极差。高频写入场景下，必须在一个事务里复用预编译语句：
- 事务开始前调一次
sqlite3_prepare_v2 - 循环中每次调
sqlite3_bind_*→sqlite3_step→sqlite3_reset（清空绑定值，准备下一轮） - 最后
sqlite3_finalize释放语句 -
sqlite3_reset比finalize + prepare快一个数量级，因为它跳过了 SQL 解析和编译阶段 - 别忘了事务外层用
BEGIN IMMEDIATE避免 WAL 模式下写冲突
绑定本身不难，难的是每一步都得对资源状态、内存边界和返回码保持警觉。尤其在 VC++ MFC 工程里，Unicode 字符串转换、局部变量作用域、异常路径遗漏，任何一个环节松懈，sqlite3_step 就可能静默失败或崩在奇怪的位置。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
