rollback() 仅在显式调用或上下文管理器因未捕获异常退出时执行；事务须处于“已开始、未提交/回滚”状态，否则报错；异步驱动需 await，ORM 中 session.rollback() 与 conn.rollback() 不等价。
什么情况下 rollback() 会被实际执行
Python 本身没有内置的“回滚”机制，所谓回滚策略全靠你写的代码决定——它只在你显式调用 rollback() 时发生，或者在上下文管理器（如 with 块）中因异常退出而自动触发。数据库驱动（如 psycopg2、sqlite3）的 rollback() 不会自己判断“该不该回”，它只响应你的指令。
常见错误现象：commit() 成功了但业务逻辑出错了，却没调用 rollback()，导致脏数据残留；或在多层函数里忘了把异常抛上去，结果 with 块提前静默结束，回滚没触发。
- 只有事务处于“已开始、未提交/回滚”状态时，
rollback()才有作用；已commit()或连接已关闭后再调，直接抛ProgrammingError -
sqlite3默认开启隐式事务，执行 DML 前自动BEGIN；但psycopg2需要显式conn.cursor()后才进入事务，空连接不自动启事务 - 异步驱动（如
asyncpg）的rollback()是协程，必须await conn.rollback()，写成同步调用会报RuntimeWarning: coroutine 'rollback' was never awaited
try/except 里漏掉 rollback() 的典型场景
很多人以为只要写了 try...except 就安全了，其实关键在“谁负责清理”。如果异常被局部吞掉、或 except 块里没做任何恢复动作，事务就卡在 pending 状态。
使用场景：Web 请求处理中，DB 操作 + 外部 API 调用混合，API 失败后必须撤回 DB 变更。
立即学习“Python免费学习笔记（深入）”；
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
- 别在
except里只打日志就 return，必须加conn.rollback()（或让外层with捕获到异常） - 避免在
finally里无条件rollback()—— 正常流程也会把它干掉，等于白干活还可能报错 - 如果用了 ORM（如 SQLAlchemy），注意
session.rollback()和底层连接conn.rollback()不是同一层，混用容易失效
try:
cursor.execute("INSERT INTO orders ...")
call_external_api()
conn.commit()
except Exception:
conn.rollback() # 这行不能少
raise
上下文管理器（with）为什么有时不自动回滚
with conn: 或 with conn.cursor(): 确实会在异常时自动 rollback()，但前提是异常真的“穿透”到了上下文边界。一旦你在内部用 except 把异常截住又没重新抛出，__exit__ 收到的是 None，就当什么事都没发生。
性能影响：自动回滚本身开销极小，但如果你依赖它来兜底，反而会掩盖逻辑缺陷——比如本该校验失败的输入，却靠回滚硬扛过去。
-
sqlite3.Connection的__exit__只在exc_type is not None时调rollback()；捕获后不raise，它就认为“一切正常” -
psycopg2的with conn:行为一致，但它的cursor上下文不管理事务，仅负责关闭游标 - 自定义上下文管理器若没在
__exit__里判exc_type并调rollback()，那就完全没回滚逻辑
事务隔离级别和自动回滚的关系
隔离级别（如 READ COMMITTED、REPEATABLE READ）影响的是“能看到什么数据”，和“会不会自动回滚”无关。回滚触发只取决于你是否调用它或是否发生未捕获异常。
容易踩的坑：以为设置了高隔离级别就能避免并发写冲突，结果遇到 SerializationFailure（PostgreSQL）或死锁时，光靠隔离级别不管用，必须主动捕获异常并重试+回滚。
- PostgreSQL 在可序列化事务中检测到冲突，会抛
TransactionRollbackError，此时必须rollback()后重试，不能忽略 - MySQL 的
SELECT ... FOR UPDATE在READ COMMITTED下可能触发Deadlock found when trying to get lock，同样需要捕获并回滚 - SQLite 的 WAL 模式下，并发写仍可能抛
DatabaseIsLockedError，但它不是事务级错误，rollback()无效，得重试整个操作
事务真正的复杂点不在怎么写 rollback()，而在于你得清楚每一处异常路径是否都覆盖到了回滚责任——它从来不是“开关一开就自动兜底”的功能，而是你对数据一致性的显式承诺。
