Navicat 17 不支持 SQLite 的“转储SQL文件”功能，需用导出向导逐表导出为 SQL，手动选 UTF-8 编码、勾选结构/数据、修正类型映射（如 INTEGER→AUTO_INCREMENT、TEXT→VARCHAR），并验证中文与语法正确性。
Navicat 17 导出 SQLite 为 SQL 文件时，转储SQL文件 功能不适用
navicat 17 对 sqlite 的支持与 mysql/postgresql 不同：它**没有“转储sql文件”右键菜单项**。你右键点击 sqlite 数据库或表，只会看到“导出向导”“备份数据库”等选项，但不会出现 转储sql文件 —— 这个功能在 sqlite 连接下被完全隐藏。强行尝试会找不到入口，不是操作遗漏，而是设计如此。
必须改用 导出向导（Export Wizard），且需手动指定格式为 SQL，否则默认导出的是 CSV 或 Excel。
用 导出向导 导出 SQLite 表为 SQL，关键在“导出为”和“格式设置”
选中某张 SQLite 表 → 右键 → 导出向导 → 下一步 → 在“导出为”下拉框中**必须手动选择 SQL 文件**（不是默认的 CSV）→ 下一步 → 进入“格式设置”页：
-
导出结构：勾选后生成CREATE TABLE语句；不勾选则只导出数据 -
导出数据：勾选后生成INSERT INTO语句；可单独使用，适合迁移已有数据 -
使用引号包围字段名：SQLite 中字段含空格或关键字（如order、group）时必须勾选，否则生成的 SQL 会语法错误 -
生成 DROP TABLE 语句：勾选后会在CREATE TABLE前加DROP TABLE IF EXISTS，适合覆盖重建场景
注意：导出向导 不支持一次导出整个 SQLite 数据库（含多张表、索引、触发器），只能单表操作。要导出全部，得逐个表执行。
SQLite 到标准 SQL 的数据类型映射容易出错
SQLite 是动态类型系统，没有严格的数据类型约束，而 Navicat 导出时会按“最接近语义”硬映射为 SQL 标准类型，常见坑点：
-
INTEGER PRIMARY KEY在 SQLite 中自动是 rowid，但导出后可能变成INT NOT NULL，丢失自增语义；需手动补上AUTO_INCREMENT（MySQL）或SERIAL（PostgreSQL） -
TEXT字段导出为VARCHAR(255)是默认行为，但 SQLite 实际无长度限制；若原数据超长，导入到其他数据库可能被截断 -
REAL通常映射为FLOAT，但某些版本 Navicat 会写成DOUBLE，在目标库不兼容时需统一替换 -
BLOB字段导出为十六进制字符串（如X'48656C6C6F'），这是正确的，但部分旧版 MySQL 客户端不识别该格式，需确认目标环境支持
导出后务必打开生成的 .sql 文件，搜索 CREATE TABLE 块，核对字段类型是否符合目标数据库要求，不能直接信任导出结果。
导出含中文或特殊字符的 SQLite 数据时，编码必须设为 UTF-8
Navicat 17 默认导出编码是系统本地编码（如 Windows 上是 GBK），而 SQLite 数据库文件本身以 UTF-8 存储中文。若不手动调整，导出的 SQL 文件里中文会变成乱码，后续导入必然失败。
在 导出向导 的最后一步（“选项”页），找到 编码 下拉框，**必须选 UTF-8**，不可用“默认”或“系统”。导出后用 Notepad++ 或 VS Code 打开验证：文件顶部不应有  BOM 头，中文应正常显示。
另提醒：SQLite 的 datetime 类型在导出时不会自动转为标准 DATETIME，而是以字符串形式（如 '2023-01-01 12:00:00'）写入 INSERT 语句，只要目标库支持该字符串格式即可，无需额外处理。
sqlite3 your.db ".dump" > dump.sql，它更可靠、更标准。 
