桌面应用共享单个SQLite连接是否安全？单连接与逐次建连接对比

你担忧的风险是真实存在的，这是全局共享单个SQLite连接时的典型事务污染问题。

核心原因 #

1. SQLite单连接本身无事务隔离能力：只要连接上存在手动开启的未结束事务（执行过BEGIN还没执行COMMIT/ROLLBACK），后续所有发送到这个连接上的写操作都会被纳入当前事务，不存在隐式事务自动隔离中间操作的情况。隐式事务的自动开启、自动提交逻辑，仅在连接上没有活跃显式事务时生效。
2. 你使用的sqlite3库的db.serialize()仅能保证回调内部的SQL按添加顺序排队执行，无法阻止回调外的其他db.run操作插入到整个连接的执行队列中。你示例中的两个操作只要触发时机重合，操作2的SQL完全可能出现在操作1的BEGIN和事务结束语句之间，被纳入操作1的事务。
3. 额外提示：你示例中用同步try/catch捕获异步SQL执行错误的写法是无效的，sqlite3的异步API错误需要通过回调参数捕获，一旦SQL执行出错，ROLLBACK逻辑根本不会触发，连接上会长期挂载未结束的活跃事务，后续所有写操作都会被塞入这个事务，风险更高。

可行的解决方案 #

• 仍使用单连接的话，需要新增全局事务锁：所有涉及显式事务的操作必须先拿到锁才能执行，事务提交/回滚完成后再释放锁，避免其他操作插入到事务执行过程中。
• 放弃全局共享单连接：仅给普通的单语句查询复用连接，需要独立事务的操作单独创建临时连接，使用完成后关闭即可。SQLite的连接创建开销极低，普通桌面Electron场景下基本感知不到性能损耗。
• 统一封装所有数据库操作入口：所有SQL执行都经过统一的调度层，自动识别当前连接是否存在活跃事务，存在时就将新的写操作调度到新连接执行，避免事务污染。

内容的提问来源于stack exchange，提问作者hdw3