本文介绍一种轻量、安全的技巧：将耗时的初始化逻辑从 pytest 的收集（collection）阶段推迟到测试执行阶段，通过传递可调用对象（如函数或 partial 对象）替代实际值，实现按需初始化，避免重复开销与作用域陷阱。
在 pytest 中，@pytest.mark.parametrize 的参数列表会在测试收集阶段（即运行 pytest --collect-only 时）就被完全求值。这意味着像 fun1()、fun3(n) 这样的调用会在所有测试开始前就执行一次——不仅造成不必要的性能损耗（尤其当某些 fun* 初始化耗时数秒甚至更久），还可能因共享状态、资源竞争或不可重入逻辑引发意外行为。
理想方案是：让初始化发生在每个测试用例真正执行时（即 test_foobar 函数体内），且不显著增加代码冗余。核心思路是——不传“值”，而传“获取值的能力”：即零参可调用对象（thunk）。
✅ 正确做法：参数化传 callable，测试内统一解包
from functools import partial
import pytest
@pytest.mark.parametrize(
"arg_factory", # 更清晰的参数名：它是个工厂函数，不是最终数据
[
fun1, # 已是零参函数 → 直接传
fun2, # 同上
]
+ [partial(fun3, n) for n in range(10)] # 绑定参数，生成零参 callable
+ [partial(fun4, n, model)
for n in range(3, 7)
for model in ["explicit", "implicit"]],
)
def test_foobar(arg_factory):
# ✅ 延迟初始化：此时才真正调用，每次测试独立执行
arg = arg_factory() # 注意：这里才是 fun1() / fun3(n) 等的实际调用点
# 后续测试逻辑（使用 arg）
assert isinstance(arg, ExpectedType)
# ... 其他断言与验证⚠️ 关键细节：优先使用 functools.partial 而非 lambda: fun3(n)。 原因在于闭包变量捕获问题：在列表推导式中，lambda: fun3(n) 会捕获循环变量 n 的最终值（如 n=9），导致所有 lambda 实际都调用 fun3(9)。而 partial(fun3, n) 在构造时即固化 n 的当前值，行为确定可靠。
? 额外优化建议
- 命名清晰化：将参数名设为 arg_factory、setup_fn 或 initializer，比泛泛的 arg 更能体现意图，提升可维护性。
-
批量初始化支持：若单个测试需多个对象，可传入 tuple[Callable, ...] 并统一解包：
@pytest.mark.parametrize("factories", [(fun1, partial(fun4, 5, "explicit"))]) def test_multi_init(factories): obj1, obj2 = (f() for f in factories) # 每个 factory 各自延迟执行 - 异常隔离：因初始化移至测试内，失败将表现为测试失败（pytest 自动标记 FAILED），而非收集阶段崩溃（导致整个测试集中断），更利于调试与 CI 稳定性。
✅ 总结
将初始化逻辑从 parametrize 列表中剥离，改用 callable（函数或 partial）作为参数，并在测试函数首行显式调用，是一种低侵入、高可控的优化模式。它既遵守 pytest 的生命周期约定，又赋予你对资源创建时机的完全掌控——无需额外 fixture、无需重构测试结构，仅需两处微调：参数化列表改传 callable，测试体首行加一次调用。这是平衡简洁性与健壮性的推荐实践。
