Python sqlite3事务提交与异常回滚的上下文写法

Python 的 sqlite3.Connection 可以直接放进 with，离开代码块时自动提交或回滚，但它不会替你关闭连接。生产代码要把“事务边界”和“资源边界”分开管理：外层负责关闭，内层负责提交与回滚。这样一次写操作成功时只提交一次，异常时回滚，文件句柄也能在离开函数前释放。

官方地址：https://docs.python.org/3/library/sqlite3.html

先分清事务边界和连接生命周期

一条常见误区是把下面两件事当成同一件事：Connection 上下文管理器决定事务成功还是失败；连接对象本身仍然需要显式关闭。官方文档明确说明，正常离开连接上下文会提交，代码块抛出未处理异常会回滚，但该上下文不会隐式关闭连接。

可以先按职责做一个小检查表：

双层上下文如何同时管事务和连接

把连接创建交给外层 closing，把 SQL 写入交给内层 with con，职责就不会混在一起。内层代码块正常结束时提交；执行 SQL 或提交过程抛出异常时回滚；无论哪条路径离开外层，连接都会关闭。

from contextlib import closing
import sqlite3

def save_order(db_path, order_id, amount):
    # 外层只负责资源生命周期，离开函数时一定关闭连接。
    with closing(sqlite3.connect(db_path)) as con:
        # 内层负责事务；正常退出提交，未处理异常触发回滚。
        with con:
            con.execute(
                "INSERT INTO orders(id, amount) VALUES (?, ?)",
                (order_id, amount),
            )
            # 参数使用占位符，避免把业务值拼进 SQL 字符串。
            con.execute(
                "INSERT INTO order_events(order_id, event) VALUES (?, ?)",
                (order_id, "created"),
            )
    # closing 的退出逻辑在这里释放连接；事务已在内层完成收口。

异常必须穿过事务边界

回滚成立的前提不是“代码里出现了 except”，而是异常在连接上下文退出时仍然可见。若在事务内部捕获异常后只记录日志、不再抛出，外层会认为代码块正常结束，已经执行的写操作就可能被提交。需要把业务处理放在事务外，或者在事务内记录后用裸 raise 继续传播。

def create_member(db_path, name):
    # 连接关闭与事务处理分别放在两个上下文中。
    with closing(sqlite3.connect(db_path)) as con:
        try:
            with con:
                con.execute(
                    "INSERT INTO members(name) VALUES (?)",
                    (name,),
                )
        except sqlite3.IntegrityError:
            # 事务上下文已经回滚；继续抛出让调用方决定提示或重试。
            raise
    # 无论成功还是失败，外层 closing 都负责关闭连接。

生产使用的四项检查

第一，检查一个业务事务是否覆盖了应当原子完成的全部写入，不能第一条 SQL 用一个连接、第二条 SQL 又换连接。第二，检查占位参数是否保留，尤其不要把用户输入直接拼接进 SQL。第三，检查是否在事务内吞掉异常；确实要转换异常时，也要先回滚或继续抛出。第四，检查长连接复用策略：短任务可用上面的双层上下文，连接池则要遵循池实现的归还协议，不能把 close() 当成销毁整个池。

如果程序需要显式控制 BEGIN、隔离级别或自动提交模式，应先统一事务策略，再决定是否使用连接上下文；不要在同一段代码里混合隐式提交和手写事务边界。

相关问题

只写 with con: 后还需要 close 吗？

需要。连接上下文只管理提交或回滚，不负责关闭连接；可以显式调用 close()，也可以用外层 closing。

回滚后异常还会继续抛出吗？

如果异常没有在事务块内被吞掉，会继续向外传播。调用方可以在外层捕获并转成业务提示。

为什么异常被捕获后仍然写入了数据？

常见原因是在 with con 内捕获异常后没有重新抛出，导致上下文按正常退出处理。把捕获放到事务外，或在处理后使用裸 raise。