C++直接调用SQLite C接口需包含sqlite3.h、链接lib、检查返回值；用sqlite3_prepare_v2+bind防注入；设busy_timeout防卡死；批量操作用事务包裹；确保UTF-8字符串安全传递；每次错误后立即调用sqlite3_errmsg。
如何用 C++ 调用 SQLite 的 C 接口（不是 ORM）
SQLite 本身是 C 写的，官方只提供 C API；C++ 没有原生绑定，必须直接调用 sqlite3.h 中的函数。别找“C++ 封装库”——除非你明确需要 sqlite_modern_cpp 或 nanodbc 这类第三方，否则直接用 C 接口最轻、最稳、依赖最少。
关键步骤：包含头文件 + 链接 lib + 检查返回值。Windows 下需手动链接 sqlite3.lib（或用动态加载），Linux/macOS 用 -lsqlite3 即可。
-
sqlite3_open()返回非零值表示失败，务必检查，不要只看指针是否为nullptr - 所有 SQL 字符串建议用
sqlite3_exec()执行 DDL/DML（如CREATE TABLE），但注意它不支持参数绑定，仅适合固定语句 - 带用户输入的查询必须用
sqlite3_prepare_v2()+sqlite3_bind_*，否则必然 SQL 注入
为什么 sqlite3_step() 总卡在 SQLITE_BUSY？
这不是 bug，是 SQLite 默认的“阻塞式锁行为”。当另一个连接正在写事务时，读操作可能被挂起（尤其在 WAL 模式关闭时）。常见于多线程场景下未正确隔离连接或未设 busy timeout。
- 调用
sqlite3_busy_timeout(db, 5000)设置 5 秒重试上限（单位毫秒），这是最简单有效的缓解方式 - 避免在多个线程间共享同一个
sqlite3*句柄；每个线程应持有独立连接（sqlite3_open各开一个） - 确认是否启用了 WAL 模式：
PRAGMA journal_mode = WAL;—— 它能显著降低读写冲突，但要求数据库文件所在文件系统支持原子 rename
插入大量数据时性能骤降，怎么优化？
逐条执行 INSERT 是最慢的方式——每条语句都触发一次事务、日志刷盘和索引更新。瓶颈不在 C++ 代码，而在 SQLite 的默认事务粒度。
立即学习“C++免费学习笔记（深入）”；
- 用
BEGIN TRANSACTION;和COMMIT;包裹批量操作，把 N 次插入压缩为 1 次事务 - 关闭同步写入（仅限可信环境）：
PRAGMA synchronous = OFF;，可提升数倍速度，但断电可能丢数据 - 预编译语句复用：对重复结构的插入，只调用一次
sqlite3_prepare_v2()，循环中反复bind→step→reset - 每 500–1000 行提交一次事务，平衡速度与崩溃恢复能力
如何安全地传递 UTF-8 字符串给 SQLite？
SQLite 内部全用 UTF-8，但 C++ std::string 本身不声明编码。如果你从 Windows GUI（ANSI 编码）、Qt QString 或用户输入中拿到字符串，直接传给 sqlite3_bind_text() 可能乱码或截断。
- 确保传入
sqlite3_bind_text()的const char*确实是合法 UTF-8；可用std::is_utf8()（C++20）或轻量校验函数预检 - Windows 下若来源是
MultiByteToWideChar(CP_ACP, ...)，记得转成 UTF-8 再传，别用CP_UTF8直接转——某些旧系统 locale 下会出错 -
sqlite3_bind_text()第四个参数建议传-1（自动计算长度），避免手动strlen遇到嵌入 \0 的二进制文本出错
SQLite 的 C 接口看着原始，但只要守住几个关键点：连接隔离、事务控制、绑定代替拼接、UTF-8 严格守界——它比多数 ORM 更可控，也更容易定位问题根源。真正容易被忽略的，是 sqlite3_errmsg() 的调用时机：不是只在 open 失败时看，每次 step 或 prepare 返回异常码后都该立刻取错误信息，否则下一个调用可能覆盖它。
