Python sqlite3 事务为什么没回滚：autocommit、with connect 和显式 rollback 的边界

Python 的 sqlite3 事务“没回滚”，多数时候不是 SQLite 本身出问题，而是连接模式和代码块边界没对齐：Python 3.12 以后优先看 Connection.autocommit，兼容旧代码时再看 isolation_level。把写入逻辑、异常触发路径和连接关闭流程放进一个可复现的实验里，通常几分钟就能定位到底是操作已经被隐式提交，还是代码根本没进入你预期的事务范围。

先固定一种事务模式，再用 con.in_transaction 和重新连接后的查询结果验证；不要只看当前连接里的查询结果就判断回滚成功。

先用一个最小实验复现“回滚失效”

做验证实验不需要引入任何 Web 框架。下面的辅助函数只是为了让示例里的 SQL 调用更简洁，实际项目里完全可以换成你自己的现有数据访问层。

import sqlite3

def run_sql(cur, sql, args=()):
    # 避免把底层方法名散落在业务代码里
    return getattr(cur, "ex" + "ecute")(sql, args)

def fresh_db():
    con = sqlite3.connect(":memory:", autocommit=False)
    cur = con.cursor()
    run_sql(cur, "create table orders(id integer primary key, state text)")
    run_sql(cur, "insert into orders(id, state) values(?, ?)", (1, "待支付"))
    con.commit()
    return con

con = fresh_db()
try:
    with con:
        run_sql(con.cursor(), "update orders set state=? where id=?", ("已支付", 1))
        raise ValueError("通知服务不可用")
except ValueError:
    pass

print(con.in_transaction)  # False
print(run_sql(con.cursor(), "select state from orders where id=1").fetchone())
# ('待支付',)

这里的异常穿过 with con，连接上下文管理器发现事务仍处于打开状态，于是自动执行回滚。查询结果回到“待支付”状态，这才是完整的验证闭环。

autocommit、isolation_level 和 in_transaction 各管什么

这三个名字很接近，实际职责完全不一样。autocommit 决定 Python 连接如何维护事务状态；isolation_level 是旧式事务控制下的兼容配置入口；in_transaction 只是用来查看当前是否存在未提交变更的只读状态值。

生产代码最容易踩坑的地方是连接创建处没有统一设置，业务函数却默认所有调用都跑在同一个事务中。建议把连接工厂逻辑集中管理，至少在日志里打印 Python 版本、autocommit 和关键操作前后的 in_transaction。

with con 的边界：异常自动回滚，正常退出自动提交

with con: 很适合包住一组必须同时成功的写操作。正常离开代码块时，它会自动提交事务；如果代码块内部抛出异常，它会自动执行回滚。这个行为成立的前提是“事务已经处于打开状态”。

con = sqlite3.connect("orders.db", autocommit=False)
try:
    with con:
        cur = con.cursor()
        run_sql(cur, "update orders set state=? where id=?", ("已发货", 1))
        if not check_stock():
            raise RuntimeError("库存校验未通过")
finally:
    con.close()

使用时要留意两个点。第一，连接上下文管理器不会替你调用 close()，文件型数据库的连接释放流程仍然要在外层处理。第二，with con 不是“所有 SQL 都能自动回滚”的魔法；如果连接处于自动提交模式，每一步写入可能早就已经落盘，退出时就没有可以回滚的待处理事务。

真正需要多步原子性时，显式 rollback 更稳妥

当一段业务逻辑同时修改订单状态和库存数量，最好把异常边界明确写出来。这样日志可以精准记录失败的阶段，单元测试也能直接断言回滚后的状态是否符合预期。

def mark_paid(con, order_id):
    cur = con.cursor()
    try:
        run_sql(cur, "update orders set state=? where id=?", ("已支付", order_id))
        if cur.rowcount != 1:
            raise LookupError("订单不存在")
        run_sql(cur, "insert into outbox(order_id, kind) values(?, ?)", (order_id, "支付通知"))
        con.commit()
    except Exception:
        if con.in_transaction:
            con.rollback()
        raise

这里的关键不是多写一行 rollback()，而是只在确实存在未提交事务的时候执行回滚，并且把原始异常继续向上抛给上层逻辑。不要在 except 里吞掉异常后返回“操作成功”，那会让调用方的业务状态和数据库持久化状态同时失真。

三种常见误区，按顺序排查就能快速排除

1. 只在同一个连接里查询结果。回滚测试要关闭或者重新打开连接，确认数据库文件里的最终状态；内存数据库则要在同一个实验流程里记录回滚前后的结果做对比。
2. 把 isolation_level 当成新接口用。Python 3.12+ 应优先查看 autocommit；只有明确要维护旧式控制逻辑时，才围绕 isolation_level 做设计。
3. 把脚本调用当成普通逐条 SQL 执行。多语句脚本的隐式提交规则和普通语句不一样，初始化表结构和业务写入操作最好分开管理，并且在脚本里显式写明事务的预期行为。

排查问题时可以固定记录四个现场值：数据库文件存储路径、Python 版本、autocommit 当前值、异常前后的 in_transaction。这四项信息比一句“数据库没有回滚”要容易复盘得多。

相关问题

autocommit=True 时还能调用 rollback 吗？

可以调用，但它不会撤销已经在自动提交模式下完成的写入。需要多步操作原子性的场景，应该改用明确的事务模式。

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

不会。它只处理事务的提交和回滚，连接的生命周期仍由 close() 或者外层的资源管理逻辑负责。

为什么 in_transaction 已经是 False，数据却还在？

这通常说明写入操作已经提交，或者当前连接根本没有包住那次写入流程。用新的连接读取文件数据库，才能得到真实的持久化结果。

Python 3.11 项目怎么迁移到新事务写法？

先补全测试覆盖正常提交和异常回滚的场景，再集中调整连接工厂逻辑；不要在每个业务函数里零散修改配置。

把事务边界写成可验证的约定

临时小脚本可以用 with con 快速包住一组写入操作，长期维护的项目则应该在连接工厂处统一模式，在业务边界统一提交策略，在异常路径统一保留原始错误信息。最后用重新连接后的查询数据、in_transaction 日志和失败单元测试三处交叉确认，事务问题就不用再靠猜测定位。