Navicat连接SQLite必须使用绝对路径且用户名密码栏须留空；相对路径、tilde、环境变量均无效，填入会导致静默失败或数据丢失，WAL模式可能引发无表显示或修改不生效。
Navicat 连接 SQLite 时路径必须是绝对路径
navicat 的 sqlite 驱动不解析相对路径、~/、环境变量或任何路径缩写——它只认完整、可访问的绝对路径。填入 ./data.db 或 data/app.db 看似合理，但 navicat 会静默跳过，连接成功却显示空数据库，实际根本没加载到文件。
常见错误现象包括：
- 连接后“Tables”面板为空，无任何表（即使文件里已有表）
- 执行
SELECT * FROM sqlite_master返回空结果 - 新建表后关闭 Navicat，再打开发现表消失（其实是写到了另一个临时或默认位置）
正确做法是手动复制数据库文件的完整路径：
- macOS/Linux：打开终端，运行
realpath /path/to/your.db，粘贴输出结果 - Windows：在文件资源管理器中右键 → “属性” → “位置”栏全选复制，补上文件名，如
C:\Users\Alice\project\data.db - 务必确认该路径下文件真实存在且 Navicat 有读写权限（尤其注意 macOS 上 iCloud 同步目录或 Windows 上受保护的
Program Files路径）
避免 WAL 模式导致 Navicat 无法识别表结构
SQLite 默认使用 rollback journal，但启用 WAL（Write-Ahead Logging）后，Navicat 可能无法正确读取 sqlite_master 表，表现为连接成功但看不到已有表、无法执行 DDL 操作。
原因在于 Navicat 的旧版 SQLite 驱动对 WAL 文件（your.db-wal 和 your.db-shm）支持不完整，尤其当数据库由其他程序（如 Python 脚本）以 PRAGMA journal_mode=WAL 打开后未正常关闭，残留 WAL 文件会导致 Navicat 加载失败。
临时解决方法：
- 用命令行强制切回 delete 模式：
sqlite3 /full/path/to/your.db "PRAGMA journal_mode=delete;" - 确保所有连接已关闭（包括后台 Python 进程、Node.js 应用），再删除同目录下的
.db-wal和.db-shm文件 - 连接前先用
sqlite3 your.db ".tables"验证能否列出表，再决定是否在 Navicat 中尝试
Navicat 连接 SQLite 不需要用户名和密码
SQLite 是嵌入式数据库，没有服务端、用户权限系统或认证机制。Navicat 对应字段必须留空——填入任意字符串（如 root、admin 或空格）会导致连接失败或行为异常。
检查点：
- “Username” 栏保持完全空白（不要填
""或null） - “Password” 栏同样留空，不可点击“Generate”或误启加密选项
- “Database File” 是唯一必填项，其余如 “Initial Database”、“Port” 全部禁用或忽略
如果填了用户名却仍能连上，大概率是 Navicat 把它当成了文件名的一部分拼进路径，最终加载的是一个不存在的新文件（比如你填了 user123，它可能去打开 /abs/path/user123.db）。
连接后修改数据不生效或丢失的典型原因
Navicat 对 SQLite 的事务控制较弱，部分操作（如直接编辑单元格后按 Ctrl+S）不会自动提交，容易造成“看起来改了，重启后还原”的假象。
关键动作必须显式触发：
- 手动执行 SQL 时，每条
INSERT/UPDATE/DELETE后需点击工具栏的Commit按钮（或按 Ctrl+Enter），否则只是暂存在事务中 - 使用“数据”页编辑表格内容后，必须右键 → “Save Changes”，不能只关 Tab 或点 X 关闭
- 若数据库文件被其他进程独占（如 Python 脚本未调用
conn.close()、Node.js 未调用db.close()），Navicat 的写操作会被拒绝，但界面可能不报错
最稳妥的做法：所有变更完成后，断开 Navicat 连接，再用命令行 sqlite3 your.db "SELECT count(*) FROM your_table;" 验证数据是否真正落盘。
