Python sqlite3 with 代码块退出后为什么没有提交数据

如果 Python 的 sqlite3 写入在 with 代码块后仍然查不到，先不要把问题归咎于 SQLite“没有保存”。最常见的原因是：退出的并不是一个打开事务的连接上下文，或者你把“提交”误当成了“关闭连接”。正确做法是先确认事务模式，再决定是否显式调用 commit()；需要跨线程时，还要让连接归属和写入同步保持清楚。

with sqlite3.connect() 到底提交了什么

连接对象实现了上下文管理器，但它的职责很窄：只处理代码块结束时的事务提交或回滚。下面的写法可以提交插入结果，但连接仍然存在，真正关闭它仍要调用 close()。

import sqlite3

con = sqlite3.connect("notes.db")
try:
    con.execute("CREATE TABLE IF NOT EXISTS note(id INTEGER PRIMARY KEY, body TEXT)")
    with con:
        # 代码块正常结束，当前打开的事务会提交
        con.execute("INSERT INTO note(body) VALUES (?)", ("会议记录",))
finally:
    # with 不负责释放连接，关闭前保留显式的资源边界
    con.close()

这里有两个容易混淆的点。第一，with con: 不会凭空创建事务；它离开时只处理已经打开的事务。第二，若代码块中抛出未捕获异常，连接会回滚这次事务，异常本身仍会继续向外抛出。因此“代码块退出了”不等于“数据一定提交了”，还要看退出路径和连接当时是否处于事务中。

当你使用Python sqlite3模块的with语句包裹数据库连接操作，退出上下文后发现写入的数据没有落库，核心原因是sqlite3默认的事务提交行为和with上下文管理器的自动处理逻辑有冲突，只有在上下文块内没有抛出异常的前提下，改动才会被自动提交。

先区分事务模式，再决定 commit 写法

“要不要写 commit()”取决于连接的事务控制方式。现代 Python 文档推荐使用 autocommit 明确表达策略；如果项目仍使用默认的传统控制，则要继续看 isolation_level。

一个稳妥的批量写入函数应该把成功和失败路径写在一起，让调用方知道何时数据已经交给数据库：

def save_notes(path, rows):
    con = sqlite3.connect(path)
    try:
        # 一个函数调用对应一个事务，失败时整体回滚
        with con:
            con.executemany(
                "INSERT INTO note(body) VALUES (?)",
                ((row,) for row in rows),
            )
    except sqlite3.Error:
        # 让上层看到数据库错误，不把失败伪装成成功
        raise
    finally:
        # 提交/回滚与关闭是两个独立动作
        con.close()

如果设置了 isolation_level=None，不要只加一个 with con: 就期待它替你建立批量事务；应明确执行 BEGIN，并在异常时调用 rollback()。反过来，如果使用 autocommit=True，每次写入的边界已经不同，重复调用 commit() 只会让代码看起来更复杂。

多线程时别把提交问题误判成线程问题

当写入代码放到线程池后，常见现象是一个线程能查到，另一个线程却报错或看不到数据。默认情况下，连接只能由创建它的线程使用，跨线程会触发 ProgrammingError。把 check_same_thread=False 打开只能绕过这层检查，并不会自动替你串行化写操作。

更容易维护的方案是每个工作线程创建自己的连接，主线程只负责汇总结果；若业务必须共享连接，就要使用锁把写事务包住，并明确谁负责关闭连接。

import sqlite3
from concurrent.futures import ThreadPoolExecutor

def write_one(path, body):
    con = sqlite3.connect(path)
    try:
        with con:
            # 连接由当前工作线程创建和使用，避免跨线程复用
            con.execute("INSERT INTO note(body) VALUES (?)", (body,))
    finally:
        con.close()

with ThreadPoolExecutor(max_workers=2) as pool:
    # 每个任务独立拥有连接，提交边界也独立
    list(pool.map(lambda text: write_one("notes.db", text), ["甲", "乙"]))

把“写入但看不到”收敛成检查清单

最后可以用一个独立连接验证结果，避免把当前连接里的可见数据误认为已经落盘：

def count_notes(path):
    con = sqlite3.connect(path)
    try:
        # 独立连接读取，验证上一个连接是否真正提交
        return con.execute("SELECT COUNT(*) FROM note").fetchone()[0]
    finally:
        con.close()

排查时按这个顺序看，通常很快就能定位：

• 写入后检查 con.in_transaction，确认是否还有未提交事务。
• 确认是否真的进入了 with con:，以及代码块是否因异常走了回滚路径。
• 检查是否在查询前误用了另一个数据库路径，尤其是相对路径。
• 检查 autocommit、isolation_level 和 check_same_thread 的实际值。
• 多线程场景用独立连接查询，并让每个连接在所属线程完成关闭。

这几项中，最常被忽略的是“连接没有关闭”和“事务没有提交”是两件事。关闭连接前仍有待处理变更时，不能指望它替你保存；相反，已经提交的数据也不需要靠关闭动作才能被其他连接看到。

常见问题

with con 会自动关闭 sqlite3 连接吗？

不会。它只在离开代码块时提交或回滚事务，连接需要显式调用 close()，也可以把连接关闭放进自己的资源管理结构。

为什么 commit() 调用了却没有变化？

先看是否处于 autocommit=True，或当前根本没有打开事务；这两种情况下 commit() 都可能没有可见的额外动作。

check_same_thread=False 能解决多线程写入吗？

它只关闭线程归属检查，不能解决并发写入的同步、事务互相覆盖和连接关闭责任。除非有明确的锁策略，否则优先给每个线程创建连接。