SQLite官方无C++接口，必须直接调用C API（sqlite3.h）；C++封装多为薄包装，易引发资源泄漏、异常处理及线程安全问题，且不受官方支持。
SQLite 本身没有官方 C++ 接口，所谓“C++ 连接 SQLite”，实际是调用其 C API（sqlite3.h）——这是唯一稳定、跨平台、无需额外依赖的方式。别被“C++ 封装库”误导，它们多数只是薄包装，底层仍走 C ABI，且容易引入生命周期/异常/线程安全等隐性问题。
为什么直接用 C API 比用 C++ 封装更可靠
SQLite 的 C API 设计简洁、状态明确、错误码清晰，且所有资源（sqlite3*、sqlite3_stmt*）都靠显式函数管理（sqlite3_open() / sqlite3_close() 等）。而很多 C++ 封装（如 sqlite_modern_cpp、nanodbc）会隐藏 sqlite3_prepare_v2() 失败的细节，或在析构时静默忽略 sqlite3_finalize() 错误，导致 prepare 缓存泄漏或语句未释放。
- SQLite 官方不维护任何 C++ 绑定，所有第三方封装都不受 SQLite 团队支持
-
std::string直接传给sqlite3_exec()可能因内部 \0 提前截断；必须用c_str()+length()配合SQLITE_TRANSIENT - C++ RAII 封装若没正确处理
SQLITE_BUSY重试逻辑，会在高并发写入时静默失败
最简可运行连接与查询示例（无第三方依赖）
以下代码仅依赖系统已安装的 libsqlite3（Linux/macOS 自带，Windows 需下载预编译 DLL 或用 vcpkg）。编译命令：g++ -o demo demo.cpp -lsqlite3。
Linux Security Scanner
下载
Linux 安全审计工具，检查 SSH 配置、开放/监听端口、防火墙规则（ufw/iptables/nftables）、失败登录尝试、sudoers 权限...
#include <sqlite3.h>
#include <iostream>
#include <string><p>int callback(void* data, int argc, char<strong> argv, char</strong> azColName) {
for (int i = 0; i </p>
<p>int main() {
sqlite3<em> db;
char</em> errMsg = nullptr;
int rc = sqlite3_open("test.db", &db);
if (rc != SQLITE_OK) {
std::cerr </p>
<pre class="brush:php;toolbar:false;">// 创建表
const char* sql = "CREATE TABLE IF NOT EXISTS users(id INTEGER PRIMARY KEY, name TEXT);";
rc = sqlite3_exec(db, sql, nullptr, nullptr, &errMsg);
if (rc != SQLITE_OK) {
std::cerr <p>}
</p>
stream>
关键操作必须注意的坑
SQLite C API 表面简单，但几个点不留意就会崩溃或数据错乱：
-
sqlite3_bind_*后必须调用sqlite3_step()，否则绑定值不会生效；只调sqlite3_step()不调sqlite3_finalize()会导致内存泄漏 - 多线程访问同一
sqlite3*实例时，必须确保开启线程模式：sqlite3_config(SQLITE_CONFIG_MULTITHREAD)，或在打开数据库时指定SQLITE_OPEN_FULLMUTEX -
sqlite3_exec()的回调函数里不能调用任何可能触发重新进入 SQLite 的操作（如再执行另一条 SQL），否则死锁 - Windows 下若用 MinGW 编译，需链接
-lsqlite3而非-lsqlite3dll；VS 用户需确认头文件路径和sqlite3.lib位置一致
真正麻烦的从来不是“连上”，而是事务边界、busy handler 设置、BLOB 字段读写、以及 WAL 模式下如何安全备份——这些在 C API 里每一步都要自己判错、重试、清理，没法靠“封装”自动解决。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
