根本原因是SQLite文件被其他进程独占占用，Navicat因无法获取写锁而失败；常见占用者包括VS Code、Python脚本、Electron应用或另一Navicat标签页，且WAL模式下未完成checkpoint也会导致同步卡死。
navicat 16 同步到 sqlite 时提示“锁库无法操作”，根本原因不是 navicat 本身加了锁，而是它尝试写入一个已被其他进程独占打开的 sqlite 文件——sqlite 的文件锁机制会直接拒绝第二个写连接，且 navicat 不报具体错误，只显示模糊的失败或超时。
SQLite 文件被其他进程占用（最常见）
SQLite 是单文件嵌入式数据库，依赖操作系统级文件锁。只要另一个程序（哪怕只是只读打开）正持有该文件句柄，Navicat 就无法获得写锁，同步必然失败。
- 常见占用者包括：VS Code 打开过
.db文件、Python 脚本运行中未关闭sqlite3.connect()、Electron 应用（如微信开发者工具）、甚至另一个 Navicat 标签页已连上同一文件 - macOS/Linux 下快速检查：
lsof | grep your.db；Windows 下用handle.exe your.db（Sysinternals 工具） - 别信“我只读没写”——SQLite 的 WAL 模式下，只读连接也可能 hold 住
-wal或-shm文件，导致 Navicat 写入卡住
Navicat 自身连接配置触发隐式独占
Navicat 在执行同步前会先建立一个连接，而它的 SQLite 驱动默认以 SQLITE_OPEN_READWRITE | SQLITE_OPEN_CREATE 模式打开文件。如果此时文件处于 WAL 模式且未完成 checkpoint，或已有共享锁未释放，这个打开动作就会阻塞并最终超时，表现为“锁库”。
- 路径填的是相对路径（如
./data.db）或含~（如~/app.db）→ Navicat 实际找不到文件，内部重试多次后假性卡死，看起来像锁 - 误启用了 SSH 隧道或 HTTP 代理 → Navicat 尝试走网络协议，但 SQLite 不支持，等待超时后抛出不可靠错误
- 数据库文件权限不足（如只读）→ Navicat 打开失败，但错误提示不明确，容易误解为锁
WAL 模式下 checkpoint 未完成
SQLite 启用 WAL 后，写操作先写入 -wal 文件，再由后台线程或显式 PRAGMA wal_checkpoint 合并到主文件。若 Navicat 同步前该 checkpoint 卡住（比如被其他进程中断），它就无法安全写入，直接失败。
- 手动触发 checkpoint：
sqlite3 /path/to/your.db "PRAGMA wal_checkpoint(FULL);" - 临时切回 DELETE 模式（仅调试用）：
sqlite3 /path/to/your.db "PRAGMA journal_mode = DELETE;"，再试同步 - 注意：Navicat 不提供 WAL 状态切换界面，也无法在同步过程中自动处理 checkpoint
真正要绕过这个问题，得从源头控制文件访问权——关掉所有可能碰过那个 .db 的程序，用绝对路径直连，同步前确保无其他连接存活。WAL 模式虽好，但在多工具混用场景下，它和 Navicat 的兼容性就是个定时雷。
