企业官网建设流程全解析

简介：面向VC开发者的SQLite集成示例包，包含完整可运行工程与配套说明，解决Visual C++项目中接入SQLite、批量插入大量数据、查询结果绑定ListCtrl展示等典型需求。包内共61个文件，以sqlite3.h头文件、sqlite3.dll/lib库文件、cpp源文件、sln/vcxproj工程文件为主，另含pdb、obj、tlog等调试辅助文件，压缩包约32MB，结构清晰便于直接打开编译与对照学习。已有303人学习下载。示例演示sqlite3_open、sqlite3_exec、sqlite3_prepare_v2等API用法，包括多条INSERT语句一次性执行的批量写入优化，以及通过sqlite3_step与sqlite3_column_text遍历结果集并填充列表控件的实现逻辑；随包附带多份db数据库文件，可直接用于测试查询与界面展示。适合正在用VC开发桌面工具、MFC界面应用，或需要快速集成轻量级本地数据库的开发者参考借鉴。

1. VC 里跑 SQLite：为什么不用 Access 而选嵌入式数据库

先说一个反直觉的结论：VC 6.0 这种老掉牙的开发环境，配 SQLite 反而比配 Access 舒服。Access 需要 ODBC 驱动、需要注册表配置，Release 到客户机器上动不动就报"未发现数据源"，而 SQLite 只有一个 sqlite3.dll（或者干脆把源码编译进工程），连安装程序都不用写，拷过去就能跑。如果你正在维护一个用 VC 写的桌面工具、上位机程序或者内部管理系统，需要本地存放配置、日志、历史数据，又不想背一个几百兆的数据库引擎，SQLite 就是那个"零运维"的选择。这篇笔记把我在 VC 里集成 SQLite 的完整过程、参数细节和踩过的坑都过一遍，适合从没用过 SQLite 的 VC 开发者直接照着做。

2. 拿到 SQLite 源码头文件：下载、编译与工程配置

SQLite 官方发布的是 amalgamation 版本，也就是把解析器、虚拟机、B-Tree 层和 API 全部揉进一个 sqlite3.c，加上配套的 sqlite3.h。在 VC 里用，最稳的做法不是去抓预编译 DLL，而是从源码开始，把 sqlite3.c 直接拖进工程参与编译。这样生成的库和你自己的程序没有任何 AB 兼容的坑。

2.1 文件清单和编译选项

去官网下载页找 sqlite-amalgamation 压缩包，解开后有四个文件：shell.c（命令行外壳）、sqlite3.c、sqlite3.h、sqlite3ext.h。项目里只需要 sqlite3.c 和 sqlite3.h，shell.c 只是给你本地调试用的。把这两个文件放进一个 sqlite 源文件目录，然后在 VC 工程里添加现有文件，把 sqlite3.c 加进去。

编译前需要确认工程的语言环境。SQLite 的 C 文件内部自带 SQLITE_THREADSAFE 等宏定义，默认条件下是线程安全模式。VC 6.0 的工程默认是 "Use Mixed Mode" 的 C/C++，直接编译 sqlite3.c 一般能过，但为了后续 C++ 文件调用方便，建议把调用 sqlite 的头文件包一层：

// sqlite3_wrapper.h #pragma once extern "C" { #include "sqlite3.h" }

逻辑说明：sqlite3.h 是纯 C 接口头文件，C++ 工程直接 include 会报链接错误（函数名被 C++ name mangling 改了），用 extern "C" 包住之后，链接器按 C 符号解析，调用 sqlite3_open、sqlite3_exec 就不会找不到函数了。

参数说明：sqlite3.c 的默认配置里，SQLITE_THREADSAFE=1，也就是串行线程安全模式；SQLITE_TEMP_STORE=2，临时表落到临时文件；SQLITE_DEFAULT_PAGE_SIZE=4096（SQLite 3.12 以上默认 4096，老版本 1024）。这些默认值在桌面应用场景下都不用改，直接编。

2.2 动态库 vs 静态编译，选哪个

VC 项目有两种接法：把 sqlite3.c 编进自己的 exe/dll（静态编译），或者单独编一个 sqlite3.dll，然后在工程里链接 sqlite3.lib。

我一般在内部工具里直接用静态编译，理由有三个：一是发布时少带一个 DLL，省去"忘了拷 DLL"这种低级事故；二是调试时可以直接进 sqlite3.c 看源码，遇到锁冲突、数据库损坏的问题能追到 C 层；三是 VC 6.0 的运行时是 msvcrt.dll 老版本，动态库如果用的是新 VS 编译的，运行时库不同，容易出"内存分配释放跨越模块边界"的问题。

静态编译要在工程设置里注意一个点：C/C++ 选项卡 -> 代码生成 -> 运行时库，整个工程统一用 Multithreaded DLL（/MD）或者 Multithreaded（/MT），不要混。如果 sqlite3.c 用 /MT，其他文件用 /MD，链接阶段大概率报 LIBCMT 冲突，那可不是 sqlite 本身的错，是 CRT 混用的老毛病。

2.3 工程组织：一个 sqlite 目录管所有

我通常把 sqlite 相关文件单独放在工程下的 sqlite/ 目录，然后 include 路径指向那里。这样做的原因是后续如果要升级 SQLite 版本，只需要替换 sqlite3.c 和 sqlite3.h，不需要翻整个工程找引用。升级 SQLite 有个额外收益：新版本对损坏数据库的恢复能力、WAL 模式的稳定性都比老版本强很多，尤其是你遇到"数据库 disk I/O error"这种错误时，升级往往比改代码更有效。

3. 核心 API 的 C 语言骨架：打开、关闭与错误处理

VC 里操作 SQLite 的完整套路就三件套：sqlite3_open / sqlite3_close / sqlite3_errmsg。这三件套配合 sqlite3_exec 和 sqlite3_prepare_v2，能覆盖 95% 的日常需求。这一章先把骨架搭好，下一章再往里填增删改查的具体写法。

3.1 打开与关闭：注意数据库路径的编码问题

sqlite3_open 接受 UTF-8 字符串路径。VC 6.0 的 CString 默认是 ANSI（GBK 编码），如果你直接把 CString 传给 sqlite3_open，路径里有中文（比如 C:\项目数据\data.db），SQLite 按 UTF-8 解析就会找不到文件，然后自动创建一个新文件，结果你明明写的是"打开"，实际变成了"新建空白库"。

// sqlite_db.h #pragma once #include <windows.h> #include <string> #include "sqlite3_wrapper.h" class SqliteDb { public: SqliteDb() : db_(NULL) {} ~SqliteDb() { Close(); } int Open(const char* utf8_path) { return sqlite3_open(utf8_path, &db_); } // 用 ANSI 路径打开：内部转 UTF-8 int OpenUtf8Path(const std::string& ansi_path) { // 先用 MultiByteToWideChar 把 ANSI 转 UTF-16 // 再 WideCharToMultiByte 转 UTF-8 // 简化起见，直接调 sqlite3_open 传入已转好的 UTF-8 return sqlite3_open(ansi_path.c_str(), &db_); } void Close() { if (db_) { sqlite3_close(db_); db_ = NULL; } } const char* LastError() { return db_ ? sqlite3_errmsg(db_) : "db is null"; } private: sqlite3* db_; };

逻辑说明：构造函数把 db_ 初始化为空指针，析构时自动关闭，这是防止中途 return 忘记 Close 的兜底。Open 系列函数直接透传 sqlite3_open 的返回值，返回 SQLITE_OK（0）就是成功。LastError 在出错后取 sqlite3_errmsg 的指针，这个指针指向 SQLite 内部静态缓冲区，下一次调用其他 API 后可能失效，所以用完立即拷贝或者直接输出。

参数说明：sqlite3_open 第二个参数是 sqlite3** 输出参数，函数内部会分配 sqlite3 结构体。注意如果打开失败，db_ 不一定是 NULL，可能是部分初始化的句柄，此时仍然需要调用 sqlite3_close 释放，再处理错误。VC 程序里常见的错误是只判断返回值不等于 SQLITE_OK 就直接退出，结果句柄泄漏，程序反复开关数据库时会越来越慢。

3.2 错误码与错误处理：不要只打印一个数字

sqlite3_open 的返回值可能很多种：SQLITE_OK（0）、SQLITE_CANTOPEN（14，打不开文件）、SQLITE_NOTADB（26，文件不是 SQLite 格式）、SQLITE_BUSY（5，数据库被锁定）。只看错误码数字不利于排查，我一般写一个 ErrorCodeToString 辅助函数，把常见错误码映射为人类能读懂的描述串。

const char* SqliteErrText(int code) { switch (code) { case SQLITE_OK: return "ok"; case SQLITE_ERROR: return "sql error or missing database"; case SQLITE_PERM: return "permission denied"; case SQLITE_BUSY: return "database is locked"; case SQLITE_LOCKED: return "table is locked"; case SQLITE_READONLY: return "attempt to write a readonly database"; case SQLITE_CANTOPEN: return "unable to open database file"; case SQLITE_NOTADB: return "file is not a database"; default: return "unknown"; } }

这个函数配合 sqlite3_errmsg 使用，能在日志里同时记录错误码和文字描述。实际开发中我发现大部分"数据库打不开"其实是路径写错、权限不够、或者根本不是 SQLite 文件，有了这张对照表，排查速度快很多。

3.3 回调风格的 sqlite3_exec：什么时候用它

sqlite3_exec 是"Sugar API"，一句话执行多条 SQL（用分号隔开），每查出一条记录会回调你传进去的函数指针。很多 VC 新手一上来就只用 exec，遇到查询结果全部往回调里塞，结果回调函数一复杂，代码立刻乱成一锅粥。

我的经验是：sqlite3_exec 只用来执行无返回结果的 DDL/DML（CREATE TABLE、INSERT、UPDATE、DELETE），查询一律走 sqlite3_prepare_v2 + sqlite3_step（下一章详述）。这样回调代码量最小，也更容易统一错误处理。

char* errmsg = NULL; int rc = sqlite3_exec(db, "CREATE TABLE IF NOT EXISTS t_log(id INTEGER PRIMARY KEY, msg TEXT, ts INTEGER);", NULL, NULL, &errmsg); if (rc != SQLITE_OK && errmsg) { // 这里 errmsg 是 sqlite 分配的，用完必须 sqlite3_free OutputDebugStringA(errmsg); sqlite3_free(errmsg); }

注意 errmsg 的释放方式：必须用 sqlite3_free，不能用 free 或 delete，否则在 debug 模式下 CRT 会报堆校验错误。这个错很隐蔽，表现可能是"程序运行半天后突然崩溃"，因为堆已经被写坏了。

4. 增删改查的完整写法：prepare_v2 绑定参数，杜绝拼接 SQL

这一章是全文核心。VC 里操作 SQLite 做增删改查，最关键的技巧就一句话：动态 SQL 用 sqlite3_prepare_v2 + bind 参数，不要用 sprintf 拼字符串。原因有三：拼 SQL 容易因转义不严导致 SQL 注入或执行失败（比如值里有单引号 ' 时直接断 SQL）；拼 SQL 导致 sqlite 每次都要重新解析语句，性能差；绑定参数让类型（整数、文本、NULL）由 API 统一处理，C++ 端不用自己转字符串。

4.1 插入与更新：绑定参数的完整流程

// db_demo.cpp #include <stdio.h> #include <string> #include "sqlite_db.h" int InsertLog(SqliteDb& db, const char* msg, int level) { sqlite3* handle = NULL; // 实际应从 SqliteDb 里拿，这里示意 // 伪代码省略获取 handle 的过程，直接看 SQL 与 bind 流程 const char* sql = "INSERT INTO t_log(msg, level, ts) VALUES(?, ?, ?);"; sqlite3_stmt* stmt = NULL; int rc = sqlite3_prepare_v2(db_handle, sql, -1, &stmt, NULL); if (rc != SQLITE_OK) { printf("prepare failed: %s\n", sqlite3_errmsg(db_handle)); return rc; } // bind 参数从 1 开始计数 sqlite3_bind_text(stmt, 1, msg, -1, SQLITE_TRANSIENT); sqlite3_bind_int(stmt, 2, level); sqlite3_bind_int64(stmt, 3, (sqlite3_int64)time(NULL)); rc = sqlite3_step(stmt); if (rc != SQLITE_DONE) { printf("step failed: %s\n", sqlite3_errmsg(db_handle)); } sqlite3_finalize(stmt); return rc == SQLITE_DONE ? SQLITE_OK : rc; }

逻辑说明：sqlite3_prepare_v2 将 SQL 语句编译为 stmt（statement 对象），SQL 文本中的问号 ? 是占位符。sqlite3_bind_text 将第一个 ? 绑定为 C 字符串，SQLITE_TRANSIENT 告诉 SQLite：这个字符串可能在语句执行完之前就被释放，SQLite 内部必须立刻复制一份副本。如果字符串生命周期能保证（比如静态常量），可以传 SQLITE_STATIC 省一次拷贝，但必须有把握才用，我一般不赌这个。sqlite3_step 执行插入，返回 SQLITE_DONE 表示执行完毕。最后必须 sqlite3_finalize 释放 stmt，否则每插入 1000 条左右就泄漏，程序内存持续上涨。

参数说明：prepare 的第二个参数是 SQL 语句文本，第三个参数 -1 表示让 SQLite 自己读取到字符串结束符 \0。第四个参数是输出 stmt，第五个参数指向 SQL 语句中第一个未处理的字符位置，一般传 NULL 就行。bind 函数的第二个参数是占位符索引，必须从 1 开始，不是 0，这是新手最容易犯的错，绑定到 0 会返回 SQLITE_RANGE。

4.2 查询：prepare + step + column 三件套

查询的套路是 prepare 一次，step 循环取每一行，用 sqlite3_column_xxx 按列取数值。这里有个性能细节：sqlite3_column_text 返回的指针指向内部缓冲，当你调用下一个 step 后它就失效了，所以要把值拷贝进 C++ 对象或者 std::string。

struct LogRow { int64_t id; std::string msg; int level; int64_t ts; }; int QueryLogs(SqliteDb& db, int level_filter, std::vector<LogRow>& out) { sqlite3* h = db.GetHandle(); // 实际封装里要暴露 const char* sql = "SELECT id, msg, level, ts FROM t_log WHERE level = ? ORDER BY ts DESC LIMIT 100;"; sqlite3_stmt* stmt = NULL; int rc = sqlite3_prepare_v2(h, sql, -1, &stmt, NULL); if (rc != SQLITE_OK) return rc; sqlite3_bind_int(stmt, 1, level_filter); while ((rc = sqlite3_step(stmt)) == SQLITE_ROW) { LogRow r; r.id = sqlite3_column_int64(stmt, 0); const unsigned char* txt = sqlite3_column_text(stmt, 1); if (txt == NULL) { r.msg = ""; } else { r.msg = (const char*)txt; } r.level = sqlite3_column_int(stmt, 2); r.ts = sqlite3_column_int64(stmt, 3); out.push_back(r); } sqlite3_finalize(stmt); if (rc != SQLITE_DONE) { // 不是 DONE 就是中途出错 return sqlite3_errcode(h); } return SQLITE_OK; }

逻辑说明：sqlite3_step 第一次返回 SQLITE_ROW 表示取到第一行，继续调返回 SQLITE_ROW 取下一行，取完返回 SQLITE_DONE 结束。所以在 while 循环里反复调 step，每次拿到一行就立刻把整行数据拷进 LogRow。注意 msg 字段可能为 NULL，即 sqlite3_column_text 返回 NULL，此时需要处理为空字符串。查询结束必须 finalize，即使只查了一部分结果，也要先把 stmt 收掉再处理其他逻辑。

4.3 删除与批量操作：事务让速度提升 100 倍

单个 INSERT 在自动提交模式下，每条记录都要写一次事务日志，1000 条插完大概要几百毫秒到几秒不等。显式开启事务后，1000 条插入通常几十毫秒就结束。VC 程序里经常有"启动时初始化一批数据"的场景，务必用事务包住。

int BatchInsert(SqliteDb& db, const std::vector<std::string>& items) { sqlite3* h = db.GetHandle(); sqlite3_exec(h, "BEGIN TRANSACTION;", NULL, NULL, NULL); int rc = SQLITE_OK; const char* sql = "INSERT INTO t_log(msg) VALUES(?);"; sqlite3_stmt* stmt = NULL; rc = sqlite3_prepare_v2(h, sql, -1, &stmt, NULL); if (rc != SQLITE_OK) { sqlite3_exec(h, "ROLLBACK;", NULL, NULL, NULL); return rc; } for (size_t i = 0; i < items.size(); i++) { sqlite3_bind_text(stmt, 1, items[i].c_str(), -1, SQLITE_TRANSIENT); rc = sqlite3_step(stmt); if (rc != SQLITE_DONE) break; sqlite3_reset(stmt); // 重要：reset 之后才能重新 bind 和 step } sqlite3_finalize(stmt); if (rc == SQLITE_DONE) { sqlite3_exec(h, "COMMIT;", NULL, NULL, NULL); } else { sqlite3_exec(h, "ROLLBACK;", NULL, NULL, NULL); } return rc; }

逻辑说明：BEGIN TRANSACTION 之后，所有写操作进入同一个事务，直到 COMMIT 或 ROLLBACK。sqlite3_prepare_v2 在事务外只做一次，循环里重复 bind + step，每次 step 之后调用 sqlite3_reset 清空绑定的参数和状态，让 stmt 可以复用。这个模式比每一步重新 prepare 快一个数量级。循环中任何一步失败就 ROLLBACK，保证数据要么全部写入，要么全部不写。

参数说明：sqlite3_reset 只重置语句状态，不会重新解析 SQL，也不会改变绑定的参数索引。如果你要改绑定的值，直接在 reset 之后重新调用 sqlite3_bind_xxx 即可，旧值会被覆盖。

5. 避坑与常见问题排查：我踩过的 5 个 VC + SQLite 大坑

这一章是血泪经验合集。VC 6.0 环境老、问题怪，很多坑在 VS2015+ 上根本不会出现，但在老工程里每一件都可能让你加班到深夜。下面每条按「现象 → 原因 → 解决」顺序写清楚。

5.1 一百年不变的"路径含中文打不开数据库"

现象：程序在开发机上跑得好好的，放到客户电脑上（或者换一个中文目录）就报 unable to open database file。实际上数据库文件根本没被打开，而是 sqlite 自动新建了一个空的同名文件，导致所有表格都提示 no such table。

原因：sqlite3_open 接收的是 UTF-8 编码路径。VC6 的 CString 默认 ANSI（GBK），中文字符在 GBK 和 UTF-8 之间字节不同，SQLite 对不上就认为文件不存在，于是"成功"创建了一个新库。解决：写一个 ANSI 转 UTF-8 的辅助函数，打开前转换路径编码。

std::string AnsiToUtf8(const char* ansi) { // 先转 UTF-16，再转 UTF-8 int wlen = MultiByteToWideChar(CP_ACP, 0, ansi, -1, NULL, 0); wchar_t* wbuf = new wchar_t[wlen]; MultiByteToWideChar(CP_ACP, 0, ansi, -1, wbuf, wlen); int ulen = WideCharToMultiByte(CP_UTF8, 0, wbuf, -1, NULL, 0, NULL, NULL); std::string out; out.resize(ulen); WideCharToMultiByte(CP_UTF8, 0, wbuf, -1, &out[0], ulen, NULL, NULL); delete[] wbuf; return out; }

参数说明：MultiByteToWideChar 第一个参数 CP_ACP 表示当前系统的 ANSI 代码页（中文系统即 GBK）。第一次调用传 NULL 输出缓冲，得到所需缓冲区大小；第二次真正转换。转 UTF-8 时同理，CP_UTF8 是 UTF-8 代码页。注意 std::string::resize(ulen) 之后，&out[0] 不一定可写（老版本 STL 里如果字符串为空，&out[0] 是未定义行为），更稳妥的写法是先用 resize(ulen - 1) 再逐个字符拷贝，或者干脆用 vector< char > 中转。VC6 的 STL 对空 string 取地址是历史知名坑，谨慎为上。

5.2 修改一行数据永远提示 database table is locked

现象：程序里开了好几个线程，每个线程各自打开数据库（同一个文件路径），偶尔做 UPDATE 时返回 SQLITE_BUSY：database is locked。有时用 DB Browser 打开同一个库文件，程序就完全动不了。

原因：SQLite 在默认 journal mode（DELETE 模式）下，写事务会对数据库文件加排他锁。另一个连接如果已经持有读锁（比如正在执行 SELECT），写操作就得等；如果两个连接同时写，一个等另一个，超过 busy_timeout 就报错。DB Browser for SQLite 这类 GUI 工具打开数据库后默认持有连接，有时还有未关闭的事务，程序自然被堵。解决：统一使用同一个数据库连接（推荐），或者把 busy_timeout 调大，并改用 WAL 模式。

// 设置 busy_timeout 为 5 秒，同时开启 WAL sqlite3_busy_timeout(db, 5000); sqlite3_exec(db, "PRAGMA journal_mode=WAL;", NULL, NULL, NULL);

说明：WAL 模式允许读操作和写操作并发，写不阻塞读，读不阻塞写，只是写时会有 10%~20% 的性能开销。桌面应用场景，数据量不大，这个开销完全可接受。设置后 journal_mode 返回的结果如果是 "wal"，说明正式生效了。

5.3 数据库文件越用越大，DELETE 之后空间不归还

现象：删了一大批数据，文件大小几乎没变。如果频繁删改，文件甚至涨到几 GB。

原因：SQLite 删除数据只是标记页为"空闲"，不会把空间交还给操作系统。同时 SQLite 还有一个 freelist（空闲页链表）机制，大量删除会产生碎片，后续插入会优先复用这些页，但不保证立刻压缩文件。解决：显式执行 VACUUM 命令重建数据库文件。

sqlite3_exec(db, "VACUUM;", NULL, NULL, NULL);

注意：VACUUM 会重写整个数据库文件，在文件很大的时候会耗时很久，而且需要临时双倍磁盘空间。所以我的习惯是：深夜维护任务里做一次 VACUUM，或者删除操作集中在操作完成后统一做一次，不在每次 DELETE 后都跑。

5.4 sqlite3_column_text 返回的指针，一 step 就失效

现象：查询结果里取出的字符串，打印出来前几个字符是对的，后面变成乱码；或者第一次访问正常，存到 vector 里再读就崩溃。

原因：sqlite3_column_text 返回的指针指向 sqlite3_stmt 内部存储区，只有当前这一行有效。下一次 sqlite3_step 会修改内部缓冲区，之前拿到的指针就悬空了。解决：每行都立刻拷贝为 std::string，不要保留指针。另外注意如果字段类型是 BLOB，sqlite3_column_blob 返回的是二进制指针，拷贝时要用 sqlite3_column_bytes 拿到字节长度，不能用 strlen。

5.5 在 VC6 下链接时报 LNK2001: unresolved external symbol sqlite3_open

现象：编译通过，链接失败，报找不到 sqlite3_open 等符号。

原因：头文件被当作 C++ 语法解析，函数名被 name mangling，链接器找的是 ?sqlite3_open@@YAH... 这种符号，但 sqlite3.c 编出来的是 C 符号。解决：按第 2 章的写法，用 extern "C" 包住 sqlite3.h，确保链接器按 C 符号解析。同时检查有没有把 sqlite3.c 漏加进工程。这两个事分开验证：先确认文件加进去了，再确认 extern "C"。

6. 进阶技巧：用回调函数把查询结果喂给界面 + 用 DB Browser 验证全链路

最后一章讲两个收尾技巧：一是 sqlite3_exec 的回调机制（这是热搜词里出现频次很高的点），二是用 DB Browser for SQLite 验证你的库结构、SQL 语句和数据正确性。这两个技巧能在调试阶段省下大量时间。

6.1 sqlite3_exec 回调机制详解：什么时候触发，怎么用

sqlite3_exec 内部其实是 prepare_v2 + step + column 的封装。当你执行 SELECT 语句时，每查到一行，SQLite 就调用你传给 exec 的第三个参数（回调函数指针），并把列数、列值数组、列名数组传进去。回调返回 0 表示继续查下一行，返回非 0 则中断查询。

// 回调函数：接收一行查询结果 static int RowCallback(void* user_data, int col_count, char** col_values, char** col_names) { std::vector<std::string>* rows = static_cast<std::vector<std::string>*>(user_data); std::string line; for (int i = 0; i < col_count; i++) { line += col_names[i]; line += "="; line += (col_values[i] ? col_values[i] : "NULL"); line += "; "; } rows->push_back(line); return 0; // 返回 0 继续，返回非 0 停止查询 } // 调用方式 std::vector<std::string> result; char* errmsg = NULL; int rc = sqlite3_exec(db, "SELECT * FROM t_log LIMIT 10;", RowCallback, &result, &errmsg);

逻辑说明：user_data 是你在 exec 第四个参数里传的自定义指针，回调里能拿到它，这是把"查询到的行收集到 C++ 容器里"的标准通道。col_values 是每个列的文本表示（SQLite 把所有值转成字符串），如果某列为 NULL，对应指针为 NULL，必须判空再使用。col_names 是列名的字符串数组。callback 返回 0 继续迭代，返回 1 立即终止。对于只关心"有没有查到数据"、不关心具体列值的场景，回调里直接 return 1，也能通过 rc == SQLITE_OK 判断查询是否成功，但这种写法我一般不用，因为不取结果没意义。

这个回调适合什么场景呢？我的判断是：查询结果很简单、不需要精细控制类型时，用它一行搞定。但如果涉及 WHERE 参数、类型转换、大量数据分页，还是 prepare_v2 + bind + column 三件套更可控。回调会在 sqlite3_exec 的调用线程中同步执行，不会自动跑到其他线程，VC 界面代码要小心：不要在回调里直接操作窗口控件，因为回调执行期间可能阻塞 UI 线程的消息循环。正确做法是回调里只收集数据到缓冲区，等 exec 返回后再统一更新界面。

6.2 用 DB Browser 验证库结构和 SQL 的正确性

DB Browser for SQLite 是免费的跨平台 SQLite 图形管理工具。我们在 VC 里写 SQL 常范的错有三个：表格名打错、列名不匹配、SQL 语法和 sqlite 方言不兼容（比如用了 MySQL 的 AUTO_INCREMENT，SQLite 里对应的是 INTEGER PRIMARY KEY AUTOINCREMENT）。与其在 C++ 里反复编译调试，不如先用 DB Browser 把库结构和 SQL 过一遍。

具体做法是：程序跑第一遍之后，用 DB Browser 打开生成的 .db 文件，在"数据库结构"页签里看表格、索引、列类型是否和预期一致；在"执行 SQL"页签里手动跑一遍你准备在代码里执行的语句，确认语法正确、结果集符合预期。还有一招是直接把你代码里的 SQL 字符串复制到 DB Browser 的 SQL 控制台跑一遍，变更后在"写入变更"里保存。这样能隔离"SQL 本身有问题"和"C++ 调用方式有问题"两种故障源。

另外我习惯在 VC 工程里加一个模块自检函数，每次程序启动（或按 F5 调试时）查询 sqlite_master 表，打印所有用户表名，确认数据库确实建好了：

void DebugDumpTables(sqlite3* db) { const char* sql = "SELECT name FROM sqlite_master WHERE type='table' ORDER BY name;"; sqlite3_stmt* stmt = NULL; if (sqlite3_prepare_v2(db, sql, -1, &stmt, NULL) == SQLITE_OK) { while (sqlite3_step(stmt) == SQLITE_ROW) { const char* name = (const char*)sqlite3_column_text(stmt, 0); OutputDebugStringA(name); OutputDebugStringA("\n"); } } sqlite3_finalize(stmt); }

这段代码在调试期很有用，能从侧边验证数据库文件路径、表格创建是否成功。从那以后我每次在 VC 里集成 sqlite，都强制走一遍这个流程：写好建表 SQL 先在 DB Browser 里跑通，再把 SQL 复制进 C++ 代码，最后用 sqlite_master 查询做启动自检。这一套下来，90% 的 SQLite 接入问题都填平了。希望帮到你。

本文还有配套的精品资源，点击获取