pytest.fixture用于数据级依赖传递，pytest-dependency仅控制用例级跳过；前者负责接口间字段流转（如token注入），后者仅决定是否执行（不传数据），二者分工明确、不可混用。
直接结论：用 pytest.fixture 做数据级依赖，用 pytest-dependency 插件做用例级跳过控制——两者不互斥，但分工明确，混用反而容易失控。
fixture 是接口链路数据传递的唯一可靠路径
接口依赖本质是「前一个接口的响应字段 → 后一个接口的请求参数」，这不是执行顺序问题，而是数据流动问题。fixture 天然支持返回值注入，且生命周期可控。
- 每个关键接口（如登录、创建订单）单独封装成
@pytest.fixture，返回结构化数据（如{"token": "xxx", "order_id": "oid_123"}） - 下游测试函数直接声明该 fixture 名为参数，Pytest 自动执行并传入，无需手动赋值或全局变量
- 避免在 fixture 内部调用
requests时硬编码 URL 或参数；应从配置或参数化 fixture 中获取，否则无法复用 - 若需多组数据（如不同账号登录），用
@pytest.mark.parametrize+indirect=True驱动 fixture，而非在 fixture 函数里写 if/else 分支
pytest-dependency 只用于“失败即跳过”，不传数据
它解决的是「test_login 成功了，test_create_order 才跑；test_login 失败，test_create_order 直接标记 skipped」，但 不负责把 token 从 test_login 传给 test_create_order——那是 fixture 的事。
Python 3.14.2
下载
Python 3.14.2是Python编程语言在2025年12月5日发布的稳定版本，属于3.14系列的第二个维护更新。该版本包含了18项修复，重点解决了多进程、数据类及正则表达式等模块的回归问题，并修复了CVE-2025-12084等安全漏洞。此版本标志着自由线程模式（移除GIL）正式获得官方支持，是Python发展的重要里程碑。
- 被依赖用例必须显式打
@pytest.mark.dependency(name="xxx")，name 是唯一标识，别名优先于函数名（尤其类内方法） - 依赖方写
@pytest.mark.dependency(depends=["xxx"])，scope 默认"module"，跨文件必须用scope="session"并确保被依赖用例先收集（文件名排序或--collect-only检查顺序） - 别在同一个测试函数上又加
@pytest.mark.dependency又试图用 fixture 传参——逻辑割裂，调试时你会分不清是数据没拿到，还是用例被跳过了 - 错误现象：
skipped due to missing dependency 'test_login'—— 检查 name 是否拼错、scope 是否匹配、被依赖用例是否真的被执行（不是被 pytest 本身跳过）
参数化 fixture 导致用例爆炸的真实原因和止损点
当你看到 2 个参数化 fixture（如 env 和 db_type）组合后，用例数变成 4×3=12 个，而你只想要 4 个环境 × 1 个固定数据库配置，问题出在「参数化层级太深」。
- 参数化 fixture 应尽量靠近测试函数：比如
@pytest.mark.parametrize("user_role", ["admin", "guest"])放在测试函数上，而不是做成独立 fixture - 如果必须用参数化 fixture 提供基础配置（如 base_url），确保它的 scope 至少是
"session"，且下游 fixture 不再参数化——否则每次参数变化都会触发重实例化 - 不要让 A fixture 依赖 B fixture，而 B 又被
@pytest.mark.parametrize装饰；改用单个 fixture 内部根据条件分支（如if env == "prod": ... else: ...），把参数逻辑收口 - 验证方式：运行
pytest --collect-only，看列出的用例名是否符合预期数量和命名逻辑
真正难的不是怎么写依赖，而是判断「这个依赖该由数据流承载，还是由执行流控制」。fixture 传数据，dependency 控节奏——边界模糊时，先问一句：我需要的是值，还是开关？
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
