Python sqlite3 事务异常后为什么还需要 rollback

Python sqlite3 执行一条写入语句抛出异常后，事务通常并没有因为异常自动结束。异常只表示这次操作失败；如果前面已经写入了同一事务的内容，Connection 仍可能握着一个未提交的 pending transaction。手动管理事务时，应在异常分支调用 rollback()，撤销本次事务的全部未提交修改，再把原异常继续抛出。

异常为什么会留下 pending transaction

事务关注的是一组写入的整体结果，而 Python 异常关注的是某次调用是否成功。比如第一条 INSERT 已经执行，第二条因为唯一键冲突失败，第一条并不会仅因为第二条抛出 sqlite3.IntegrityError 就自动消失。此时如果直接复用连接，后续代码可能把一个半完成的业务批次继续当成正常状态。

回滚的意义是把连接从“这次事务还没有决定提交或撤销”的状态带回事务起点。官方文档把 rollback() 定义为回滚当前 pending transaction；如果没有打开的事务，调用通常没有可撤销的内容。图1把异常、连接和未提交事务放在同一张静态关系图中，重点是看清它们不是同一个状态。

手动 try/except 如何正确回滚并继续使用连接

手动事务的最小结构是“成功提交，任何失败都回滚并继续抛错”。不要在 except 里只打印错误，也不要用 commit() 试图“保存能保存的部分”，否则第一条写入可能被意外保留下来。

import sqlite3

def create_order(conn, order_id, user_id):
    try:
        # 两条写入必须作为一个业务批次处理。
        conn.execute(
            "INSERT INTO orders(id, user_id) VALUES(?, ?)",
            (order_id, user_id),
        )
        conn.execute(
            "INSERT INTO order_events(order_id, name) VALUES(?, ?)",
            (order_id, "created"),
        )
        # 只有整批成功后才让其他连接看见结果。
        conn.commit()
    except Exception:
        # 撤销本次事务内已完成但尚未提交的写入。
        conn.rollback()
        # 保留原始异常，让上层决定重试或返回错误。
        raise

这里捕获 Exception 是因为业务校验也可能发生在两次写入之间；如果只捕获 sqlite3.Error，业务异常可能让事务继续悬挂。回滚以后可以继续使用同一个连接，但必须先修复真正原因，例如重复主键、参数类型或业务状态错误。

with conn 什么时候可以代替显式 rollback

Connection 支持上下文管理器。代码块正常离开时提交；代码块抛出未捕获异常时回滚。这样可以把事务边界写得更集中：

def create_order_with_context(conn, order_id, user_id):
    with conn:
        # 代码块中的异常会触发 rollback，成功离开会触发 commit。
        conn.execute(
            "INSERT INTO orders(id, user_id) VALUES(?, ?)",
            (order_id, user_id),
        )
        conn.execute(
            "INSERT INTO order_events(order_id, name) VALUES(?, ?)",
            (order_id, "created"),
        )
    # with 只管理事务，不负责关闭连接。
    return order_id

如果在 with 内部把异常吞掉，代码块会正常离开，上下文管理器就可能按成功路径提交。因此需要记录错误并让异常离开上下文，或者在确认要转成业务返回值之前显式调用 rollback()。连接本身也不会因为离开 with 自动关闭，生命周期仍由调用方负责。

autocommit 和 in_transaction 怎么辅助判断

Python 3.12 起，sqlite3.connect() 可以通过 autocommit 明确选择事务控制方式；官方文档推荐用它表达新代码的意图。autocommit=False 会保持符合 DB-API 习惯的显式提交与回滚，autocommit=True 则使用 SQLite 的自动提交模式，此时 commit() 和 rollback() 不会产生通常的事务控制效果。没有明确设置时，还可能处于由 isolation_level 控制的 legacy 模式。

conn.in_transaction 反映的是 SQLite 底层是否存在活动事务，适合在排查时确认连接状态，但不要把它当成“本次业务一定成功”的标记。更稳妥的规则是：每个业务批次明确成功出口和失败出口；失败出口统一回滚；连接关闭前确认应该提交的内容已经提交。

常见问题

rollback 会撤销整个数据库吗？

不会。它只作用于当前连接当前事务中尚未提交的修改，已经提交的内容不受影响。

为什么 rollback 后还要 raise？

回滚只负责恢复事务状态，不代表业务已经成功。继续抛出原异常，调用方才能记录、重试或返回合适的错误。

没有写入时调用 rollback 安全吗？

通常安全，但它不能替代问题定位。若连接处于自动提交模式，调用可能没有效果；最终仍应以明确的事务控制方式组织代码。

参考：Python sqlite3 官方文档。