navicat 16 不支持 sqlite 真正热备份，其“备份”实为文件复制，不调用 sqlite3backup* api，无法保证一致性；唯一可靠方式是冷备份：确保无进程访问后导出 sql 脚本，再通过运行 sql 恢复。
SQLite 没有服务端进程，不支持传统意义上的“热备份”——即在数据库被其他进程（如应用）持续读写时，由 Navicat 直接发起一致性快照备份。Navicat 16 对 SQLite 数据库**不提供真正的热备份能力**，所有所谓“在线备份”实际都依赖于文件系统层面的复制，风险极高。
如果你看到某些教程声称“Navicat 可以热备 SQLite”，那大概率混淆了概念：它只是把正在被使用的 .db 文件直接拷贝出来，而 SQLite 官方明确警告——这种操作**不保证一致性**，恢复后极可能遇到 database disk image is malformed 错误。
为什么 Navicat 16 无法对 SQLite 做可靠热备份
SQLite 的 WAL 模式或 journaling 机制要求备份必须满足原子性条件：
- 要么数据库完全空闲（无连接、无未提交事务），此时可安全复制文件；
- 要么使用
VACUUM INTO或sqlite3_backup_*C API 接口做逻辑备份——但 Navicat 16 的 GUI 和备份向导**不调用这些 API**，也不识别 WAL 检查点状态； - Navicat 的“备份”功能对 SQLite 实际等价于“复制当前 .db 文件”，它不会执行
PRAGMA wal_checkpoint(FULL)，也不会等待 writer 退出；
Navicat 16 中 SQLite 备份的唯一可行方式
你只能接受“冷备份”前提，并手动控制访问状态：
- 确保没有其他进程（包括你的应用、另一个 Navicat 连接、甚至系统搜索索引服务）正在打开该
.db文件； - 在 Navicat 中右键数据库 →
转储SQL文件→ 选择仅结构或结构和数据； - 或者，使用菜单
工具 → 导出向导→ 选中表 → 导出为SQL格式（注意：这不是二进制备份，而是重建脚本）； - 避免使用
备份向导（对应.nb3文件）——它对 SQLite 仅保存连接信息和简单元数据，**不包含实际数据内容**；
如何从 SQL 脚本恢复 SQLite 数据库
恢复本质是执行建表 + 插入语句，不是“还原 nb3”：
- 新建一个空的
.db文件（可通过 Navicat 新建连接时指定新路径，或用命令行sqlite3 new.db ""）； - 右键该新数据库 →
运行SQL文件→ 选择之前导出的.sql脚本； - 确认脚本中不含
CREATE DATABASE（SQLite 不支持）、且没有跨库引用（如ATTACH）； - 如果原库启用了
WAL，恢复后建议执行PRAGMA journal_mode = DELETE;避免残留 -wal/-shm 文件干扰；
真正关键的一点常被忽略：Navicat 对 SQLite 的所有“备份”操作，都不涉及锁协调或事务快照。它不替代 sqlite3 CLI 的 .backup 命令，也不等价于 Python 的 sqlite3.backup() 方法。如果你的应用要求高可用或并发写入，必须在应用层实现备份逻辑，而不是依赖 Navicat 界面。
