pytest中多线程测试共享fixture必然引发竞争，因fixture的function作用域仅限主线程生效；应避免传递可变对象，改用工厂函数或threading.local()实现线程隔离。
Pytest 本身不是多线程框架，但当你在测试中主动启动线程（比如用 threading.Thread 或 concurrent.futures），而这些线程又访问了共享的 fixture 实例时，竞争问题就不是“容易出现”，而是“必然发生”——只要 fixture 返回的是可变对象且未做线程隔离。
fixture 默认按函数作用域缓存，但线程不遵守这个作用域
Pytest 的 scope="function" 意味着：每个测试函数调用前创建新 fixture 实例，调用后销毁。这个机制只在主线程、单测试上下文中生效。一旦你在测试里 spawn 新线程，这些线程运行在独立调度单元中，它们访问的 fixture 对象（比如一个字典、列表或数据库连接）是主线程传入的同一内存地址——pytest 不会为每个线程重新执行 fixture setup。
- 典型表现：
fixture 'db_session' not found不会出现，但db_session.add()在多个线程里并发调用时抛出InvalidRequestError或数据丢失 - 根本原因：fixture 实例被多个线程同时读写，而它内部状态（如 SQLAlchemy session 的 identity map、缓存字典）不是线程安全的
- 注意：即使你把 fixture scope 设为
function，只要测试函数内启动了线程并把 fixture 对象传过去，就已脱离 pytest 的生命周期管理
哪些 fixture 最容易踩坑？
以下三类 fixture 在多线程测试中最常引发竞争，因为它们默认返回可变、共享、非线程安全的对象：
-
dict/list/set等原生容器：比如@pytest.fixture def user_cache(): return {}，线程间直接修改同一字典 - 数据库 session（如 SQLAlchemy 的
Session）：session 内部维护 identity map 和 pending state，跨线程复用会触发DetachedInstanceError或脏读 - HTTP 客户端实例（如
requests.Session或aiohttp.ClientSession）：底层连接池、cookie jar 都非线程安全，多线程并发请求可能覆盖 headers 或重置 auth
怎么避免？关键不是“加锁”，而是“不共享”
给 fixture 加 threading.Lock 是治标不治本——它会让测试变慢、掩盖设计缺陷，且无法解决 session 级别的状态污染。真正安全的做法是切断共享路径：
- 让 fixture 返回工厂函数而非实例：
@pytest.fixture def make_db_session(): return lambda: Session()，线程内各自调用make_db_session()获取独立 session - 用
threading.local()封装 fixture 结果：适用于需要“每个线程一份”的场景，但注意它不能替代进程间通信 - 彻底避免在多线程中传递 fixture 对象：改用参数化 + 单线程串行执行组合用例，或改用
pytest-xdist的进程级并行（-n auto），而非线程级 - 检查第三方 fixture 插件文档：比如
pytest-asyncio明确要求 fixture scope 必须为function，且禁止跨协程共享 session
最隐蔽的陷阱在于：问题往往不报错，只是偶尔失败或数据错乱。等你看到 AssertionError 时，状态可能早已被其他线程悄悄改过——这时候再查日志，已经找不到源头了。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
