module级fixture（scope="module"）确保同模块内仅初始化和清理一次数据库等资源，但不跨文件共享，且teardown须在yield后显式处理、不可抛异常，也不能接收function级参数。
fixture作用域选错会导致数据库连接反复重建
模块级（scope="module"）是解决重复初始化最直接的手段，但很多人误用scope="session"或默认"function"，结果每次测试函数都重跑setup_database()、重连Redis、重新加载配置文件。这不是慢，是根本没理解fixture生命周期——module意味着整个.py文件只执行一次setup和teardown。
module级fixture必须和测试函数在同一个模块里才生效
常见错误是把fixture定义在conftest.py中却期望它对所有子目录下的test_*.py生效。实际行为是：只有同级或子目录中import了该fixture的模块才会触发绑定。更稳妥的做法是显式声明位置：
- 在
tests/integration/test_api.py顶部写from conftest import db_fixture，并在测试函数参数中引用db_fixture - 或直接把fixture定义挪到
test_api.py顶部，加上@pytest.fixture(scope="module") - 避免跨包调用时隐式继承——
scope="module"不跨文件，哪怕两个test文件都在同一目录下，也不共享fixture实例
teardown逻辑必须显式写在yield后面，且不能抛异常
使用yield定义teardown时，yield之后的代码才是清理阶段。如果这里出现未捕获异常（比如redis.flushdb()失败），pytest会静默吞掉错误，后续测试可能因残留数据而失败，但你完全看不到报错。
快速生成专业的 Python 脚本和应用代码。一键创建完整项目结构，支持CLI、API、爬虫、Bot、Django等多种项目类型，包含完整的项目结构、配置文件、依赖管理、测试、README和文档。
import pytest <p>@pytest.fixture(scope="module") def redis_client(): client = redis.Redis() client.flushdb() # 初始化 yield client try: client.close() # 清理必须放yield后 except Exception: pass # 不要让teardown失败中断整个模块
module级fixture无法接收function级参数，别硬塞request.fixturenames
想让一个scope="module"的fixture根据某个test函数的参数动态初始化？不行。fixture作用域决定了它的参数只能来自同级或更高（session）作用域的fixture。常见翻车点：
立即学习“Python免费学习笔记（深入）”；
- 试图在module fixture里读
request.param→ 报AttributeError: 'FixtureRequest' object has no attribute 'param' - 把
tmp_path（function级）传给module fixture当参数 → pytest直接拒绝运行，提示“fixture 'tmp_path' not found” - 正确解法：拆分职责——module级做全局资源（DB连接池、配置对象），function级做临时路径、mock patch等
模块级fixture不是银弹，它把初始化成本摊薄了，但也锁死了资源复用边界。最容易被忽略的是：当多个test文件import同一个module级fixture时，它们各自获得独立实例——不是共享一个对象，而是每个文件一份。真要跨文件共享，得上scope="session"，但那就必须自己管好线程/进程隔离。
