module作用域通过在单个.py文件内仅初始化和销毁fixture一次来避免重复初始化，使20个测试函数共享同一数据库连接而非各自创建，从而将高开销操作（如DB连接、配置加载）从“每用例一次”降为“每文件一次”，提速2–5倍。
module作用域如何避免重复初始化
当fixture的scope="module"时，它在整个.py文件（即模块）内只被创建和销毁一次。这意味着：如果一个测试文件里有20个test_*函数都依赖同一个数据库连接fixture，该连接不会被建立20次，而是仅初始化1次、复用20次、清理1次。
常见错误现象是把高开销资源（如HTTP会话、数据库连接、大型配置加载）设为默认的function作用域——每次测试都重连、重解析、重建对象，I/O和CPU开销直接线性放大。
- 典型耗时操作：建立SSH连接（~100–300ms）、连接PostgreSQL（~50–150ms）、加载YAML配置（含嵌套模板渲染）
- module级复用后，这些操作从“每用例一次”变成“每文件一次”，对中等规模测试集（单文件10–50用例）提速常达2–5倍
- 注意：必须确保fixture内部状态不被后续测试污染（比如数据库写入未回滚），否则会引发用例间干扰
module与session作用域的关键区别
scope="module"不是“全局共享”，而是“模块内共享”。它比session更安全、更可控，尤其适合那些不能跨文件复用但又不想每函数重建的资源。
使用场景差异明显：
立即学习“Python免费学习笔记（深入）”；
- 用
session：全局只读配置、缓存服务器连接、测试环境启动脚本（整个测试套件只需跑一次） - 用
module：每个测试文件需要独立的数据库schema、临时目录、mock server实例——它们彼此隔离，但同一文件内可复用 - 误用
session在并行测试（pytest -n auto）中极易引发资源竞争，而module天然适配多进程（每个worker处理自己的模块）
哪些fixture适合设为module作用域
不是所有fixture都适合提升作用域。盲目设为module可能引入状态残留或并发问题。判断依据很实际：
- ✅ 适合：数据库连接（配合事务回滚）、本地HTTP mock server（
httpx.MockTransport）、预编译正则对象、轻量级配置字典 - ❌ 不适合：带状态的类实例（如未清空的列表缓存）、依赖测试参数生成的数据、修改全局变量的fixture
- ⚠️ 需谨慎：文件系统操作（如
tempfile.mkdtemp()）——必须确保路径唯一且清理可靠，否则模块内多个测试会冲突
示例中常见陷阱：@pytest.fixture(scope="module") def tmpdir(): return tempfile.mkdtemp() —— 这会导致所有测试共用一个目录，文件名碰撞或权限问题频发；正确做法是用tmp_path_factory.mktemp()并显式指定scope="module"。
调试module作用域是否生效
光写scope="module"不等于它真被复用了。验证方式很简单：
- 在fixture函数里加
print(f"init at {time.time()}")和print("teardown")，观察输出次数是否等于模块数而非用例数 - 运行
pytest --setup-show test_module.py，会清晰显示每个fixture的setup/teardown时机和层级 - 若发现仍被多次调用，检查是否被其他fixture间接依赖——作用域取的是“最窄作用域”，比如A（module）依赖B（function），那A也会退化为function级
真正起效的module作用域，往往藏在你没意识到的间接依赖链里。别只看表面装饰器，得顺着yield和return一路追下去。
