SQLAlchemy Session提交异常回滚写法差异与事务管理咨询

1. 两种写法的核心差异 #

核心差在异常捕获的覆盖范围，以及回滚逻辑的兜底依赖不一样：

• 第一种把commit()放在else块的写法：try只包住了add、数据修改这类业务操作，commit()本身根本不在当前try的捕获范围内。要是提交阶段出问题——比如唯一键冲突、数据库死锁、连接闪断、flush时字段校验失败——当前写的这个except块根本碰不到，自然也不会触发回滚。别看着是官方给的代码就直接抄，这玩意儿是官方用来拆解with Session(engine)上下文内部运行逻辑的演示样例，它的回滚全靠外层with Session的__exit__方法兜底：等commit()抛的异常往外逃的时候，with块退出时检测到有未处理异常，才会自动执行回滚。你要是脱离了with上下文直接抄这个结构，百分百会出事务泄漏的问题。
• 第二种把commit()放在try块里的写法：try包住了从事务开起来到提交完成的全流程，不管是改数据的时候报错，还是最后commit的时候报错，都会进except块触发回滚，不依赖外层的上下文兜底，是手动管事务时逻辑完整的写法。

2. 生产环境优先推荐写法 #

按容错性从高到低排：

• 首选用官方提供的事务上下文管理器全托管，别自己手写try/except/rollback/commit这套重复逻辑，从根上避免漏写回滚、捕获范围没覆盖全这类人为失误。最简写法如下：

Session = sessionmaker(bind=engine)
# 上下文自动管Session生命周期、开事务、提交、回滚，不用自己写对应逻辑
with Session.begin() as session:
    # 所有数据库读写操作全放这个块里就行
    item1 = session.get(Item, 1)
    item2 = session.get(Item, 2)
    item1.foo = 'bar'
    item2.bar = 'foo'
    session.add(some_object)

• 要是碰到特殊场景必须手动管事务，一定把commit()放在try块内部，保证提交阶段出问题也能触发回滚，别学演示样例把commit放else里，不然哪天漏了外层兜底，直接出线上故障。

3. session.begin()上下文管理器的异常处理能力 #

完全可以自动处理commit()阶段抛出的异常，不用额外加捕获逻辑。
这个上下文的逻辑写死了：

• 进with块的时候自动开新事务
• 块里代码全跑通没抛异常，退出的时候自动执行commit()
• 只要块里任何位置抛异常——不管是操作数据的时候抛的，还是最后自动执行commit的时候抛的——上下文都会先自动回滚，再把异常往外抛，全流程的异常场景都覆盖到了。

补一句：网上有些回答把commit放try外面，要么是特别老的SQLAlchemy版本遗留的写法，要么是默认外层有Session上下文做回滚兜底，这类写法容错性极差，只要外层兜底漏写就会出问题，别用。

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