Python sqlite3.Connection.autocommit 怎么区分事务模式：提交时机与迁移检查

把 Python 里的 SQLite 连接从旧写法迁到 Connection.autocommit 时，最容易误判的不是 SQL，而是“这一行数据什么时候真正落盘”。autocommit=False、autocommit=True 和 LEGACY_TRANSACTION_CONTROL 代表三套不同的事务入口；先把它们放进一个内存数据库里跑一遍，再改业务代码会稳得多。

需要显式事务时优先选 autocommit=False，每个业务单元明确调用 commit() 或 rollback()；只有确认每条写操作都可以独立提交时，才使用 True。旧代码依赖 isolation_level 的，先保留兼容模式并逐段迁移。

先把三种模式放进同一个实验

下面的实验不依赖磁盘文件，避免上一次运行留下的数据干扰结果。表名固定为 accounts，每次只插入一行，观察 in_transaction 和第二个连接能否读到它。

import sqlite3

def experiment(mode):
    first = sqlite3.connect(":memory:", autocommit=mode)
    first.execute("CREATE TABLE accounts (id INTEGER PRIMARY KEY, name TEXT)")
    first.execute("INSERT INTO accounts(name) VALUES (?)", ("Lin",))
    print(mode, "after INSERT:", first.in_transaction)
    first.commit()
    print(mode, "after commit:", first.in_transaction)
    first.close()

for mode in (False, True, sqlite3.LEGACY_TRANSACTION_CONTROL):
    experiment(mode)

这段代码先执行 connect，再执行 INSERT，随后调用 commit，最后 close。in_transaction 只用来观察状态，不能替代业务层的提交策略。

autocommit=False：把业务单元的边界写出来

在这个模式下，连接保持 PEP 249 风格的事务控制。一次写入之后，不要只看 Python 函数返回没有异常，就把它当成已经完成；成功路径调用 commit()，失败路径调用 rollback()，然后再决定是否关闭连接。

import sqlite3

con = sqlite3.connect(":memory:", autocommit=False)
con.execute("CREATE TABLE accounts (id INTEGER PRIMARY KEY, name TEXT NOT NULL)")
try:
    con.execute("INSERT INTO accounts(name) VALUES (?)", ("Ming",))
    # 其他校验也通过后，才确认这个业务单元
    con.commit()
except sqlite3.Error:
    con.rollback()
    raise
finally:
    con.close()

这里的关键顺序是 INSERT → commit，异常分支则是 INSERT → rollback。如果在 commit() 前关闭连接，待处理的变化会被回滚，因此不要把 close() 当成提交动作。

autocommit=True：每次写入都要独立成立

设为 True 后，连接使用 SQLite 的自动提交模式。适合单条写入本身就是完整业务动作的场景，例如写一条独立的审计记录；不适合“扣库存、写订单、写流水”必须同成同败的组合操作。

特别注意：Python 文档把 Connection.autocommit 作为推荐的事务控制入口，但 True 并不意味着可以省略业务边界设计。它只是让每条语句更快结束事务，不能把多条写入自动合并成一个原子操作。

旧代码迁移时，先检查 isolation_level

历史代码经常只写 sqlite3.connect(path, isolation_level="DEFERRED")，然后依赖 INSERT、UPDATE 或 DELETE 自动打开事务。这种行为属于 LEGACY_TRANSACTION_CONTROL 分支；一旦设置了 autocommit=False 或 True，isolation_level 就不再承担同样的控制职责。

# 迁移前：先明确旧代码依赖什么
con = sqlite3.connect("app.db", isolation_level="DEFERRED")

# 迁移后：把提交点写在业务单元结束处
con = sqlite3.connect("app.db", autocommit=False)
try:
    con.execute("UPDATE accounts SET name = ? WHERE id = ?", ("Ming", 1))
    con.commit()
except sqlite3.Error:
    con.rollback()
    raise

迁移检查至少要问三件事：原代码是否把多个写操作放在同一事务里；异常路径是否真的调用了 rollback()；连接池或请求结束时是否可能提前 close()。答不清楚时，先不要把模式切成 True。

用 in_transaction 做验收，而不是猜

in_transaction 反映底层 SQLite 的自动提交状态：有未提交变化时为 True，提交或回滚后通常回到 False。它适合写测试断言，也适合在迁移期间打印检查，但不能证明一个跨表业务已经完整成功。

con = sqlite3.connect(":memory:", autocommit=False)
con.execute("CREATE TABLE accounts (id INTEGER PRIMARY KEY, name TEXT)")
assert con.in_transaction is True
con.execute("INSERT INTO accounts(name) VALUES ('Qin')")
assert con.in_transaction is True
con.commit()
assert con.in_transaction is True  # False 模式会立即打开下一事务
con.rollback()
con.close()

最后一个断言容易让人困惑：在 autocommit=False 下，commit() 关闭当前事务后会准备下一事务，所以不要把“提交后一定是 False”写成跨版本的绝对规则。更可靠的验收是查询业务结果，再结合连接状态判断当前事务阶段。

常见问题

autocommit=True 还需要调用 commit() 吗？

可以调用，但在这个模式下 commit() 没有效果。调用它不会把多条 SQL 重新合并成一个事务。

为什么 isolation_level 改了却没有影响？

当 autocommit 不是 LEGACY_TRANSACTION_CONTROL 时，isolation_level 不负责事务控制。迁移时应把提交和回滚写到业务代码中。

关闭连接前还要不要回滚？

如果当前业务没有确认提交，显式调用 rollback() 更容易表达意图；在 autocommit=False 下，带未决变化的 close() 不会替代成功提交。

把迁移清单留在代码评审里

先用内存数据库跑通 connect、INSERT、commit、rollback、close 的路径，再替换生产连接参数。需要一组操作原子完成时选 False，需要每条独立提交时才考虑 True，依赖旧式 isolation_level 的代码则保留 LEGACY_TRANSACTION_CONTROL 并逐个补上验收。