indirect 是 pytest 参数化的路由机制，将参数名解析为 fixture 名并执行对应 fixture；默认 indirect=False 直接传值，indirect=True 或指定列表则触发 fixture 初始化，需确保参数名、fixture 名、indirect 配置三者严格一致。
什么是 indirect 参数化，它和普通 @pytest.mark.parametrize 有什么区别？
indirect 是 @pytest.mark.parametrize 的一个参数，用于把测试用例的参数值，当作 fixture 名称去查找并执行对应 fixture，而不是直接传入测试函数。
它解决的核心问题是：你有一组「需要被初始化的资源名」（比如数据库名、配置环境名），而这些资源的创建逻辑已封装在 fixture 中，你不想在测试函数里手动调用 request.getfixturevalue() 或重复写 setup/teardown。
常见错误现象是：写了 @pytest.mark.parametrize("db_name", ["test_db1", "test_db2"])，但测试函数接收的是字符串，不是已连接好的数据库对象——这时候就要用 indirect。
-
indirect=True：该参数名会被当 fixture 名解析，pytest 先运行同名 fixture，再把 fixture 返回值传给测试函数 -
indirect=False（默认）：参数值原样传入，不触发 fixture -
indirect=["db_name"]：只对指定参数启用 indirect，其余仍按原值传
注意：indirect 不会改变 fixture 的作用域或执行时机，它只是“路由”参数到 fixture 的一种声明方式。
如何让 fixture 接收参数并返回不同实例？
fixture 本身不能直接接收测试参数，但可以通过 request fixture 拿到当前测试的参数值。你需要：
- 在 fixture 函数签名中声明
request - 用
request.param获取当前测试用例中该参数的实际值（仅在indirect启用时有效） - 根据该值做分支初始化（如连接不同数据库、加载不同配置）
import pytest
<p>@pytest.fixture
def db_connection(request):
db_name = request.param # ← 关键：从参数化中取值
if db_name == "sqlite":
conn = sqlite3.connect(":memory:")
elif db_name == "postgres":
conn = psycopg2.connect("host=localhost dbname=test")
else:
raise ValueError(f"Unknown db: {db_name}")
yield conn
conn.close()</p><p>@pytest.mark.parametrize("db_connection", ["sqlite", "postgres"], indirect=True)
def test_query(db_connection):
assert db_connection.execute("SELECT 1").fetchone() == (1,)</p>这里 db_connection 既是 fixture 名，也是参数名，且通过 indirect=True 绑定。每次测试运行前，pytest 先调用 db_connection fixture，并把 "sqlite" 或 "postgres" 赋给 request.param。
立即学习“Python免费学习笔记（深入）”；
容易踩的坑：fixture 名、参数名、indirect 配置三者必须严格一致
这是最常导致 FixtureLookupError 或静默传错值的问题：
- 参数名（如
"db"）必须和 fixture 函数名（def db():）完全相同（包括大小写） - 如果用了
indirect=["db"]，但 fixture 叫database，pytest 找不到dbfixture，报错fixture 'db' not found - 如果参数名和 fixture 名相同，但忘了加
indirect=True，测试函数收到的是字符串"sqlite"，不是连接对象 -
request.param只在indirect生效的 fixture 中可用；在普通 fixture 里访问会报AttributeError: 'FixtureRequest' object has no attribute 'param'
另一个隐性坑：fixture 作用域（scope="session"）和 indirect 冲突。比如你把 db_connection 设为 scope="session"，但参数化了多个值，pytest 会复用同一个 fixture 实例，导致所有测试共享同一连接——这不是你想要的动态初始化。应设为 scope="function" 或根据实际需要选 "class"。
进阶：混合 direct 和 indirect 参数，以及多 fixture 动态初始化
你可以同时参数化多个变量，只对其中一部分启用 indirect：
@pytest.mark.parametrize(
"db_name,timeout,use_cache",
[
("sqlite", 5, True),
("postgres", 10, False),
],
indirect=["db_name"] # ← 只让 db_name 走 fixture，timeout 和 use_cache 原样传
)
def test_api(db_name, timeout, use_cache):
assert isinstance(db_name, sqlite3.Connection) or isinstance(db_name, psycopg2.extensions.connection)
assert isinstance(timeout, int)
如果要初始化多个 fixture，可以这样写：
@pytest.mark.parametrize(
"db_name,config_env",
[("sqlite", "dev"), ("postgres", "staging")],
indirect=True # ← 表示两个参数都对应同名 fixture
)
def test_with_both(db_name, config_env):
# db_name 是数据库连接，config_env 是加载好的 dict 配置
pass
前提是存在 def db_name(request): 和 def config_env(request): 两个 fixture。
真正复杂的地方在于：当 fixture 依赖其他 fixture，又需要基于 request.param 分支行为时，request 的嵌套获取容易出错；另外，参数值如果是复杂类型（比如字典或对象），request.param 依然能接住，但 fixture 内部要做更谨慎的类型检查——这些细节不会报语法错，却会让初始化逻辑悄悄失效。
