Python sqlite3 事务控制怎样避免隐式提交

我在把一段批量写入逻辑接到 SQLite 时，最容易误判的不是 commit() 怎么调用，而是“到底是谁打开了事务”。要避免 Python sqlite3 的隐式提交，先把事务策略写进连接配置，再让成功路径只在最后提交，异常路径统一回滚。Python 3.12 以后，优先考虑显式设置 autocommit=False；不要把 isolation_level 当成所有模式下都有效的总开关。

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

先固定事务控制模型，别让默认值替你做决定

现在的 sqlite3.connect() 同时提供 autocommit 和旧式 isolation_level。我更愿意把前者直接写出来，让读代码的人知道提交责任在哪里。autocommit=False 会保持 PEP 249 风格的事务控制：写入后显式 commit()，失败时显式 rollback()。如果设置为 True，SQLite 处于自动提交模式，此时 commit() 和 rollback() 都不会替你完成业务补救。

只有需要兼容旧代码时，才使用 sqlite3.LEGACY_TRANSACTION_CONTROL，然后再讨论 isolation_level：

import sqlite3

con = sqlite3.connect("app.db", autocommit=False)

try:
    # 参数绑定把数据和 SQL 分开，事务只围绕本次业务写入展开。
    con.execute("INSERT INTO audit(event, detail) VALUES (?, ?)", ("import", "batch-17"))
    con.commit()  # 只有全部写入成功才提交。
except Exception:
    con.rollback()  # 任一步失败都撤销当前事务中的改动。
    raise
finally:
    con.close()  # 关闭前已完成提交或回滚，避免留下未决责任。

把提交点放进成功路径

隐式行为最难排查的地方，是一条看似无关的语句改变了提交时机。普通 execute() 或 executemany() 的 DML 写入，在 legacy 模式和合适的 isolation_level 下可能隐式打开事务；这不等于已经提交。真正稳妥的做法，是把“准备数据、执行写入、确认无异常、提交”放在同一个可读的成功路径。

事务中的读取也要有边界意识：SELECT 不会因为读取结果就自动替你提交写入。需要诊断时，con.in_transaction 可以帮助判断底层 SQLite 是否仍有未提交变化，但它不是替代业务状态机的万能信号。

参数边界：legacy 模式才看 isolation_level

一个经常被忽略的坑是 executescript()。在 legacy 模式有待处理事务时，它会先隐式执行 COMMIT，之后脚本里的事务控制才开始生效。若脚本必须原子执行，就不要依赖函数外部残留的事务，而要在脚本文本中明确写出 BEGIN、写入语句和 COMMIT；异常时由调用方捕获并回滚尚未完成的部分。

失败处理与关闭动作要形成复盘回路

我通常会给每次批量写入保留三类记录：入口采用的 autocommit 模式、成功提交或异常回滚的结果、关闭前的 in_transaction 状态。这样看到“数据提前出现”时，先查连接配置和是否调用过 executescript()，而不是直接增加更多 commit()。

关闭连接时也不能赌默认行为：新式 autocommit=False 下，仍有待处理变化时关闭会隐式回滚。因此，业务完成要明确提交，业务失败要明确回滚；把 close() 当资源清理，而不是事务确认按钮。

常见问题

设置了 isolation_level=None，为什么数据还是能写入？

它禁止的是隐式开启事务，不是禁止写入。每条语句可能在 SQLite 自动提交语义下独立生效；需要原子批处理时，请显式执行 BEGIN，并在成功与异常路径分别处理。

autocommit=False 还需要手写 BEGIN 吗？

通常不需要。官方文档说明该模式会保持事务打开并使用 BEGIN DEFERRED；除非你确实需要 SQLite 的其他锁定时机，才考虑显式事务语句。

executescript() 能不能放在已经写入但未提交的连接上？

不建议这样做。legacy 模式下它可能先提交待处理事务；要保证边界，就先结束前一笔事务，或把完整的 BEGIN/COMMIT 直接放进脚本。