Navicat连接SQLite报错14或“database is locked”，主因是文件被其他进程占用或WAL模式不兼容；应关掉所有可能访问该.db文件的程序，用绝对路径重试，并通过handle.exe（Windows）或lsof（macOS/Linux）定位锁持有者。
navicat 同步或连接 sqlite 时提示“锁库无法操作”“database is locked”或直接报错 14（unable to open database file），基本不是 navicat 的 bug，而是 sqlite 文件被其他进程独占占用，或 wal 模式下 checkpoint 卡住导致的——关掉所有可能碰过那个 .db 文件的程序，再用绝对路径重试，90% 能立刻解决。
怎么快速定位是谁在锁你的 SQLite 文件
SQLite 的“锁”本质是操作系统级文件句柄占用，不是数据库内部事务锁。只要另一个进程打开了这个文件（哪怕只是只读打开），Navicat 就无法获得写权限。
- Windows：下载 Sysinternals 的
handle.exe，运行handle.exe your.db，它会列出所有持有该文件句柄的进程名和 PID - macOS/Linux：终端执行
lsof | grep your.db，输出里COMMAND列就是占用者（常见有Code（VS Code）、python、WeChatDevTools、甚至另一个navicat标签页） - 别信“我没写它”——VS Code 打开
.db文件预览、Python 脚本中sqlite3.connect()后没调.close()、Electron 应用加载过该文件，都会长期持锁
WAL 模式下同步失败的典型表现和绕过方法
启用 PRAGMA journal_mode = WAL; 的 SQLite 数据库，会生成 your.db-wal 和 your.db-shm 两个辅助文件。Navicat 16 自带的 SQLite 驱动不完全兼容 WAL 模式，尤其当 -wal 文件未完成 checkpoint 时，它连打开都失败，报错常为 14 - unable to open database file，而非明确提示 WAL 不支持。
在 Windows 上执行终端命令，或对比 Windows 与 Linux 的 Shell 语法时使用。建议先检测当前 Shell 是 PowerShell 还是 cmd.exe，再给出相应命令……
- 临时关闭 WAL：用命令行工具（如官网 sqlite-tools）执行
sqlite3 your.db "PRAGMA journal_mode = DELETE;"，强制切回传统日志模式 - 手动触发 checkpoint：先确保无其他连接，再运行
sqlite3 your.db "PRAGMA wal_checkpoint;"，返回0,0,0表示成功 - 绝对避免在 Navicat 中直接执行
PRAGMA——它自身连接就可能因 WAL 兼容问题卡死，导致后续所有操作不可用
路径和权限这两个“隐形雷”怎么排
Navicat 报锁错误，有时根本不是锁，而是压根没找到文件或没权限写入。错误信息模糊，但现象高度一致：反复超时、连接图标转圈、同步进度条不动。
- 路径必须用绝对路径：
/Users/you/project/data.db或C:\project\data.db；填./data.db或~/data.db会导致 Navicat 在它自己的工作目录下找，找不到就不断重试，看起来像卡死 - 检查文件是否真可写：
ls -l your.db（macOS/Linux）或右键属性看“只读”是否勾选（Windows）；即使权限是rw-rw-rw-，若父目录无写权限，SQLite 也无法创建-wal文件 - 杀毒软件或 OneDrive/Google Drive 同步服务也会拦截 SQLite 文件写入，临时禁用它们再试一次，能快速验证
真正麻烦的不是 WAL 模式本身，而是多工具混用时没人主动释放文件句柄。VS Code 关了文件标签、Python 脚本加了 conn.close()、Navicat 只开一个连接页——这些细节不处理，换再新的 Navicat 版本也一样报锁。
