Navicat提示“数据库被锁定”根本原因是SQLite文件级锁机制，即其他进程（含只读打开）占用.db文件导致Navicat无法获取写锁；常见占用者包括VS Code、未关闭连接的Python脚本、Electron应用及另一Navicat标签页，WAL模式下未完成checkpoint或-shm/-wal文件残留亦会引发假性锁定，需用lsof或handle.exe定位并终止占用进程，配合绝对路径直连与基础权限检查方可解决。
Navicat 提示“数据库被锁定”根本不是 Navicat 加的锁
这是 sqlite 文件级锁机制在起作用：只要另一个进程（哪怕只是只读打开）还持有 your.db 文件句柄，navicat 就无法获得写锁，同步或连接就会失败。它不报具体占用者，只显示模糊提示，容易误判为 navicat 自身问题。
- 最常见占用者：
VS Code打开过该.db文件、Python脚本中sqlite3.connect()未调用close()、微信开发者工具等Electron应用、甚至另一个Navicat标签页已连上同一文件 - macOS/Linux 下快速定位：
lsof | grep your.db；Windows 下用handle.exe your.db（Sysinternals 工具） - 别信“我只读没写”——WAL 模式下，只读连接也可能 hold 住
your.db-wal或your.db-shm，导致 Navicat 写入卡死
WAL 模式未完成 checkpoint 是静默卡死主因
SQLite 启用 WAL 后，写操作先写入 -wal 文件，需通过 PRAGMA wal_checkpoint 合并回主文件。若该过程被中断（如程序异常退出），Navicat 尝试连接时会因无法安全写入而直接失败，错误表现常是 14 - unable to open database file 或超时假死。
- 检查是否启用 WAL：
PRAGMA journal_mode;返回wal即确认 - 手动触发 checkpoint：
sqlite3 your.db "PRAGMA wal_checkpoint;"，返回0,0,0表示成功 - 临时规避：用命令行执行
PRAGMA journal_mode = DELETE;切回传统日志模式（但会丢失 WAL 的并发读优势）
路径、权限、代理配置也会伪装成“锁”
Navicat 报“锁库”，实际可能是它根本没找到文件，或没权限打开，或协议走歪了——这些都会表现为连接阻塞、超时、假性锁定。
提示词大师-python版
下载
图片提示词生成器？不止如此。 马甲系统 —— 把脑海中的画面，翻译成AI能理解的专业表达。 用得越多，它越懂你：首次需要多问几句确认方向，用久了几乎一说就懂。 用得越多，它越快：缓存机制让后续对话越来越省。 RAG进化：成功案例持续入库，越跑越聪明。 输入「新手指南」查看完整功能介绍
- 路径必须用绝对路径，避免
./data.db或~/app.db：Navicat 解析失败后会反复重试，看起来像卡死 - 文件和其所在目录都需有读写权限：
chmod 644 your.db不够，上级目录也得chmod 755（否则 open() 系统调用直接失败） - 关掉 SSH 隧道或 HTTP 代理：SQLite 不走网络协议，Navicat 若误启代理，会等待不可达地址，最终抛出不可靠错误
真正绕过锁定，只能靠“清场+直连”
没有万能开关或 Navicat 设置能绕过 SQLite 的文件锁。所谓“解决”，本质是确保那个 .db 文件此刻在系统里是干净的、独占的、可写的。
- 关掉所有可能碰过该文件的程序：编辑器、脚本、IDE、其他数据库工具，一个都不能漏
- 用绝对路径新建连接，不勾选任何高级选项（如加密、WAL 强制等），先测试能否基础连接
- 同步前加一步验证：
sqlite3 your.db "SELECT count(*) FROM sqlite_master;"成功返回才继续
WAL 模式本身没问题，但它和 Navicat 的兼容性很脆——checkpoint 卡住、-shm/-wal 文件残留、多工具混用，任何一个环节出岔，都会让“锁库”提示变得毫无头绪。最省事的办法，永远是先清空环境，再动手。
