因为pytest本身不感知数据库，也不控制事务，必须通过fixture在测试前开启事务、测试后显式回滚，并禁用autocommit=true，否则commit()会致回滚失效，造成数据污染。
为什么直接用 pytest 无法自动回滚数据库事务
因为 pytest 本身不感知数据库，更不会插手事务控制——它只负责运行测试函数、收集结果。如果你在测试里执行了 INSERT 或 UPDATE，默认会提交到数据库（除非你显式禁用自动提交），下一次测试就可能读到脏数据，导致偶发失败。
常见错误现象：IntegrityError: duplicate key value violates unique constraint，或测试间相互干扰、结果不可重现。
核心解决思路：不是靠 pytest 自身，而是借助数据库驱动能力 + 测试生命周期钩子，在每个测试前建事务、测试后强制回滚。
用 pytest.fixture 封装事务级测试环境（以 PostgreSQL + SQLAlchemy 为例）
最稳定的做法是写一个作用域为 function 的 fixture，它在每次测试开始时开启新事务，在测试结束时回滚（不提交）。
- 必须关闭 SQLAlchemy 的
autocommit=True，否则rollback()无效 - 不能直接对
engine调用begin()，要基于connection创建事务，否则 session 可能用错上下文 - fixture 需 yield 出可操作的
session，而非 engine 或 connection，否则 ORM 操作会绕过事务
@pytest.fixture(scope="function")
def db_session():
connection = engine.connect()
transaction = connection.begin()
session = Session(bind=connection)
yield session
session.close()
transaction.rollback()
connection.close()
测试中如何安全使用该 fixture 并避免“假成功”
拿到 db_session 后，所有 ORM 操作都必须走它；但要注意：如果测试里手动调用了 session.commit()，回滚就会失效——这是最容易被忽略的坑。
使用场景举例：验证用户创建后能否被查询，但不希望数据落库：
- ✅ 正确：只调用
db_session.add()和db_session.flush()（触发 INSERT 但不提交） - ✅ 正确：用
db_session.query(User).filter(...).one()查询刚 flush 的记录 - ❌ 错误：调用
db_session.commit()—— 回滚将不生效，且污染后续测试 - ⚠️ 注意：某些 ORM 方法（如
merge()或外键关联插入）可能隐式触发 flush，需结合日志确认 SQL 是否真被发出
SQLite 内存数据库是否更简单？别信
虽然 sqlite:///:memory: 看似“每个测试新建一个库”，但它在多线程/多进程下行为不可靠；更重要的是，:memory: 数据库在连接关闭后即销毁，而 SQLAlchemy 默认复用连接池，导致多个测试共享同一内存实例。
实际表现：看似隔离，实则测试间仍可能互相覆盖数据，尤其当 fixture 未显式控制连接生命周期时。
更稳妥做法仍是统一走事务回滚方案，哪怕用 SQLite —— 即使用 sqlite:///file.db?mode=memory&cache=shared 配合 connection.begin()，也比依赖 :memory: 直觉更可控。
复杂点在于：不同数据库对 SAVEPOINT 的支持程度不同，PostgreSQL 全支持，MySQL 5.7+ 支持有限，SQLite 基本可用；若需跨库兼容，优先测透目标 DB 的事务嵌套行为，而不是幻想一套代码通吃。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
