session更合适用于线程安全的全局共享资源（如只读配置、测试服务），module适合含可变状态或需模块级隔离的资源；选择取决于资源的可重入性与安全性。
pytest夹具作用域设为session还是module更合适？
取决于被初始化对象的可重入性和线程/进程安全性。如果夹具返回的是全局共享资源（如数据库连接池、HTTP会话、配置加载器），且该资源本身线程安全、不依赖测试间状态，session作用域能彻底避免重复初始化；但若资源含可变状态（如临时目录、mock对象、单例缓存），用session反而导致测试污染。
实操建议：
-
session适合：读取一次配置、启动本地测试服务（如pytest-asyncio中的event loop）、加载大型只读数据集 -
module适合：每个模块共用一个DB连接、复用同一组mock patch、初始化轻量级工具类实例 - 避免盲目设为
session——一旦夹具内部调用time.sleep()或requests.get()，就可能拖慢整个测试套件
如何让夹具在首次调用时才初始化？
用lazy=True参数（pytest ≥ 7.0）配合scope="session"或scope="package"，能让夹具延迟到第一个测试实际请求它时才执行初始化逻辑，而不是在会话开始时就运行。
示例：
立即学习“Python免费学习笔记（深入）”；
@pytest.fixture(scope="session", lazy=True)
def heavy_db_client():
print("→ 初始化数据库客户端")
return DatabaseClient()
注意点：
- 未启用
--tb=short等参数时，lazy=True错误堆栈可能指向fixture定义处而非调用处 - 与
autouse=True组合使用需谨慎：autouse夹具仍会在作用域入口触发，不遵守lazy - 某些插件（如
pytest-xdist）在多进程模式下对lazy=True支持有限，建议先验证
为什么yield夹具比return更容易引发重复初始化？
因为yield夹具在每次被请求时都会重新执行yield前的代码段，即使作用域是session。很多人误以为“只要写了scope="session"，yield前的代码就只跑一次”，其实不然。
常见错误写法：
@pytest.fixture(scope="session")
def bad_cached_config():
config = load_config() # ❌ 每次被引用都执行一次！
yield config
cleanup(config)
正确做法：
- 把初始化逻辑移到函数外部，或用闭包缓存
- 改用
return+ 显式清理（通过request.addfinalizer） - 或者用
functools.lru_cache包装初始化函数
推荐简洁解法：
@pytest.fixture(scope="session")
def good_cached_config():
return load_config() # ✅ 只执行一次
<p>@pytest.fixture(scope="session")
def good_cached_config_with_cleanup(request):
config = load_config()
request.addfinalizer(lambda: cleanup(config))
return config
多进程下pytest-xdist如何影响夹具初始化？
每个worker进程独立运行自己的pytest会话，session作用域在每个worker内各初始化一次，不是全局唯一。这意味着你以为的“一次初始化”其实在4个worker里发生了4次。
解决方向：
- 用
filelock或redis实现跨进程互斥初始化（适合耗时>1s的场景） - 将初始化结果写入文件，并在夹具中检查文件是否存在+时间戳是否新鲜
- 禁用xdist对特定夹具的并行：用
pytest.mark.xfail或自定义标记跳过 - 更务实的做法：接受“每个worker一次”，但确保初始化函数幂等（多次调用不报错、不重复写磁盘）
真正容易被忽略的是：很多团队没意识到--dist=loadgroup和--dist=load对夹具生命周期的影响完全不同，后者会让同一session夹具在多个worker中反复触发——这比性能损耗更危险，它可能造成资源竞争。
