pytest中sqlite :memory: 测试报“no such table”是因为每个连接独享内存库，需在fixture中创建engine后立即执行base.metadata.create_all()，且fixture应返回session实例而非sessionmaker，确保测试使用同一连接。
pytest里用sqlite:///:memory:为什么测试总报“no such table”
因为:memory:数据库是每个连接独享的，create_engine建一次就开一个新内存库，而ORM模型没在那个连接里执行Base.metadata.create_all()，表根本不存在。Django的TestCase自动建表，但纯SQLAlchemy+pytest不会。
- 每次
session或connection新建，都得手动触发Base.metadata.create_all(engine) - 别在
conftest.py顶层import后直接调用create_all——那时engine还没创建，或指向的是别的库 - 如果用了
scoped_session，确保create_all在fixture创建engine之后、session初始化之前执行
写fixture时scope="function"和scope="session"怎么选
选错scope会导致测试间污染或重复建库拖慢速度。:memory:库无法跨进程/线程共享，所以哪怕设成session，pytest-xdist并行时每个worker仍会拿到独立内存库——这时session反而不如function直观。
-
scope="function"：最安全，默认推荐。每个测试函数独占干净:memory:库，无需清理 -
scope="session"：仅当所有测试串行运行（禁用-n）、且建库开销大（比如含大量初始数据）时考虑；但必须确认没有测试修改全局Base或engine状态 - 别用
scope="module"：模块内测试共享一个库，但若某个测试commit了脏数据，后续测试可能失败，排查困难
如何让fixture返回的engine和session能被测试函数直接用
关键是把engine和session绑定到同一个:memory:实例，并确保测试中使用的session来自该engine。常见错误是fixture返回engine，测试里又自己sessionmaker(bind=engine)()，结果session连的是另一个内存库。
- fixture应返回
session实例（不是sessionmaker），并在内部完成create_all和session初始化 - 测试函数参数名必须和fixture名一致，例如
def test_user_create(db_session):，其中db_session是fixture名 - 如果测试需要
engine（比如执行raw SQL），在fixture里一并yield出来，如yield {"engine": engine, "session": session}，但注意这会让测试代码变啰嗦
import pytest
from sqlalchemy import create_engine
from sqlalchemy.orm import sessionmaker
<p>@pytest.fixture(scope="function")
def db_session():
engine = create_engine("sqlite:///:memory:")
Base.metadata.create_all(engine) # 表在这里建好
Session = sessionmaker(bind=engine)
session = Session()
yield session
session.close() # 内存库随session销毁自动丢弃，不用drop_all为什么测试跑完数据库没清空，或者报OperationalError: database is locked
:memory:库本身不需要手动清理——Python对象销毁、连接关闭后，内存就释放了。所谓“没清空”，其实是上个测试没session.close()或没rollback()，导致连接还挂着锁；而database is locked通常发生在多线程/协程复用同一:memory:引擎时，但pytest默认单线程，所以大概率是fixture没正确关闭session。
立即学习“Python免费学习笔记（深入）”；
- 务必在fixture的
yield后调用session.close()，不能只靠__del__或GC - 避免在测试里调用
session.commit()后不close()——:memory:虽轻量，但未关闭的session会持锁阻塞下一个测试的同名表操作 - 如果用了
fastapi.testclient之类集成测试，确保依赖注入的db session也被正确reset，而不是复用fixture里的长生命周期session
真正容易被忽略的点是：你以为:memory:能自动隔离，其实隔离边界在连接层，不是进程层；而fixture的生命周期管理稍有松动，就会让锁或未提交事务跨测试泄漏。
