sqlite3中sqlite_master字段顺序易错，因vacuum或attach导致隐藏字段或编译差异；正确做法是显式指定列名（如select type, name, tbl_name, rootpage, sql），并用sqlite3_prepare_v2配合sqlite3_column_name动态校验列名，避免硬编码索引越界。
sqlite3\_exec 查询 sqlite_master 时为什么字段顺序总出错？
直接用 sqlite3_exec 执行 SELECT * FROM sqlite_master 拿到的列顺序不是文档写的 type, name, tbl_name, rootpage, sql ——这是 SQLite 的「元数据缓存行为」导致的：如果数据库被 VACUUM 过、或有 ATTACH 多个库，sqlite_master 实际返回的列可能含隐藏字段（如 sql 被拆成 sql 和 sql1），或者字段顺序受编译选项影响。
正确做法永远是显式指定字段名：
SELECT type, name, tbl_name, rootpage, sql FROM sqlite_master
而不是依赖 *。否则回调函数里靠索引取值（比如 argv[4] 取 sql）极易越界或错位。
用 sqlite3_prepare_v2 + sqlite3_column_count 安全读取结构
相比 sqlite3_exec 的字符串回调，预编译方式能严格绑定列定义，避免字符串解析歧义，尤其当 sql 字段含换行、单引号、注释时。
- 调用
sqlite3_prepare_v2编译语句后，立即用sqlite3_column_count校验是否为 5 列 - 用
sqlite3_column_name(stmt, i)动态获取第i列名，确认是"type"、"sql"等，而非硬编码索引 -
sqlite3_column_text返回的是 UTF-8，且指针生命周期仅在sqlite3_step当次有效，不能长期保存
示例关键片段：
const char* sql = "SELECT type, name, tbl_name, rootpage, sql FROM sqlite_master";
sqlite3_stmt* stmt;
if (sqlite3_prepare_v2(db, sql, -1, &stmt, nullptr) == SQLITE_OK) {
if (sqlite3_column_count(stmt) != 5) { /* 拒绝非标准结构 */ }
while (sqlite3_step(stmt) == SQLITE_ROW) {
const char* type = reinterpret_cast<const char>(sqlite3_column_text(stmt, 0));
const char* sql_text = reinterpret_cast<const char>(sqlite3_column_text(stmt, 4));
// 注意：sql_text 在下次 sqlite3_step 或 sqlite3_finalize 后失效
}
sqlite3_finalize(stmt);
}</const></const>
sql 字段内容里为什么有 CREATE TABLE IF NOT EXISTS 却没有实际建表语句？
这通常是因为该表是 TEMP 表、或来自 ATTACH 的数据库，而当前连接未启用对应 schema —— sqlite_master 默认只返回主 schema（main）的条目；TEMP 表存在 sqlite_temp_master，其他 ATTACH 库名（如 aux）对应 aux.sqlite_master。
- 查所有 schema 的系统表，需分别查：
main.sqlite_master、temp.sqlite_temp_master、aux.sqlite_master - 用
PRAGMA database_list先枚举已加载的 schema 名，再拼接查询 -
sql字段为空字符串表示该对象是自动生成的（如 virtual table 的 shadow tables），不可直接执行
解析 sql 字段时绕不开的转义和编码陷阱
sqlite_master.sql 是 SQLite 内部存储的原始建表/索引语句，但并非总是可直接复用：它可能含内部标识符（如 "main"."my_table"）、保留字转义（"order"）、或未展开的 WITHOUT ROWID 等隐式语法。
- 不要用
std::string::find直接搜"CREATE TABLE"——开头可能有注释、空格、或/*+ INDEXED BY ... */提示 -
sql字段值是严格 UTF-8，但若数据库用 legacy encoding（如 UTF-16），需先确认PRAGMA encoding，否则sqlite3_column_text返回乱码 - 对
sql做语法分析前，建议先过一遍sqlite3_complete验证其是否为完整语句，避免截断风险
真正难的不是读出字段，而是理解哪些 sql 字符串能安全重建表——比如 FTS5 的 sql 包含虚拟模块参数，直接执行会报错 no such module: fts5。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
