“database is locked”错误根本不是Navicat导致，而是SQLite文件锁机制触发：其他进程（如Python脚本、Electron应用、杀毒软件）正占用.db文件，或WAL模式残留.db-wal/.db-shm文件未清理。
Navicat报“database is locked”时，根本不是Navicat锁的
这个错误几乎从不源于Navicat本身，而是SQLite底层的文件锁机制在起作用。SQLite用操作系统级文件锁（flock on Linux/macOS、LockFileEx on Windows）来串行化写操作——只要另一个进程正持有写锁（哪怕只是执行了一条未提交的INSERT），Navicat尝试CREATE TABLE或UPDATE就会立刻失败，报database is locked。
常见触发场景包括：
- Python脚本调用
sqlite3.connect()后忘了conn.close()，或用了with但提前退出了上下文 - Electron应用、VS Code SQLite插件、DBeaver等工具正在后台连接同一.db文件
- 杀毒软件扫描过程中临时加锁（尤其Windows Defender实时防护）
- macOS上iCloud同步目录里的.db文件被同步进程占用
怎么快速确认是不是真被锁住了？别猜，直接查
绕过Navicat，用命令行验证最可靠。打开终端（macOS/Linux）或CMD/PowerShell（Windows），运行：
sqlite3 /full/path/to/your.db ".tables"
如果返回表名，说明文件可读——那Navicat的“locked”大概率是其他进程写锁导致；如果卡住几秒后报错database is locked，就坐实了锁冲突。
进一步排查建议：
- Windows：用
Process Explorer搜索.db文件名，看哪些进程句柄打开了它 - macOS/Linux：运行
lsof +D /path/to/dir，检查是否有python、node、Code Helper等进程在占用 - 关掉所有可能连数据库的IDE、编辑器、后台脚本，再试Navicat
WAL模式会让锁问题更隐蔽
SQLite启用WAL（PRAGMA journal_mode=WAL）后，写操作不阻塞读，但会生成.db-wal和.db-shm两个辅助文件。如果之前程序异常退出，这两个文件可能残留且处于不一致状态，Navicat连接时会认为“数据库正在被其他进程使用”，直接报锁错，哪怕实际没进程在跑。
解决方法很直接：
- 确保所有连接已关闭（包括Python里
conn.close()、Node.js里db.close()） - 手动删除同目录下的
your.db-wal和your.db-shm - 用命令行强制切回默认模式：
sqlite3 /full/path/to/your.db "PRAGMA journal_mode=delete;"
Navicat自己也会悄悄“锁住”文件
很多人忽略一点：Navicat连接SQLite后，只要连接窗口开着，它就一直持有读锁（甚至写锁）。如果你在连接状态下，用Python脚本再去connect()并执行写操作，脚本会卡住或报错——反过来也一样。
这不是Bug，是SQLite设计使然。应对策略很简单：
- 执行DDL（如
CREATE、ALTER）前，先在Navicat里右键连接 → “断开连接” - 避免Navicat和代码同时连同一个.db文件；开发时用两份副本，一份给Navicat，一份给程序
- 在Navicat中执行写操作后，及时关闭查询窗口（不要长期挂着未提交的事务）
真正难处理的永远不是“怎么解锁”，而是“谁在用、为什么没释放”。盯着.db-wal文件是否存在、用lsof或Process Explorer扫一遍，比反复重启Navicat有效得多。
