autouse=True的fixture自动执行但不自动注入参数，需显式声明才能获取返回值；执行顺序按作用域从宽到窄，且可能被同名普通fixture覆盖。
autouse=True 的 fixture 会自动运行，但不会自动注入参数
很多人以为加了 autouse=True 就能像普通 fixture 一样在函数签名里直接写变量名——其实不能。pytest 只执行它，不把返回值塞进测试函数参数里。如果你需要访问 fixture 的返回值（比如一个临时目录路径、一个 mock 对象），仍得显式声明参数名，哪怕它 autouse 了。
- ✅ 正确：用
autouse=True做无副作用的初始化（如设置环境变量、清理缓存） - ❌ 错误：指望
def test_something(temp_dir):中的temp_dir自动绑定 autouse fixture，除非你同时在函数签名里写了它 - ⚠️ 注意：
autouse=Truefixture 的执行顺序按作用域从宽到窄（session → package → module → class → function），不是按定义顺序
module 级 autouse fixture 影响整个文件，但可能被同名普通 fixture 覆盖
在 conftest.py 或测试文件顶部定义 @pytest.fixture(autouse=True, scope="module")，确实会让它对当前模块所有测试生效。但一旦某个测试函数显式声明了同名参数（比如也叫 db），pytest 就会优先用那个局部 fixture，而不是 autouse 的那个——这容易导致“为什么这个 autouse 没跑？”的困惑。
- 常见错误现象：
Fixture "db" called directly. Fixtures are not meant to be called directly—— 实际是误写了db()调用，而非声明为参数 - 使用场景：适合统一 setup/teardown，比如启动/关闭本地 Redis 实例，或 patch 全局 logger
- 建议：autouse fixture 名字尽量带前缀（如
_setup_logging），避免和业务 fixture 冲突
autouse fixture 的 yield 写法必须配对，否则 teardown 不执行
带 yield 的 autouse fixture 看似方便，但 teardown 部分（yield 后代码）是否执行，取决于测试是否真正“进入”了该 fixture 的作用域。如果测试因 import error、语法错误或 pytest.mark.skip 直接跳过，teardown 就不会跑。
- 示例问题：
@pytest.fixture(autouse=True, scope="function")中yield tmp_path，但测试函数根本没执行，tmp_path对应的目录可能残留 - 性能影响：autouse fixture 在每个测试前都创建+销毁，频繁 IO 或网络操作会明显拖慢整体测试速度
- 建议：非必要不用 function 级 autouse；改用 module 或 session 级 + 显式清理逻辑更可控
跨文件 autouse fixture 必须放在 conftest.py，且注意作用域继承
想让子目录下所有测试都自动运行某个 fixture？必须把它放进对应层级的 conftest.py，并设好 scope。pytest 不会向上查找父级 conftest 的 autouse fixture，除非作用域允许（比如 session 级可跨文件，function 级只限本文件）。
立即学习“Python免费学习笔记（深入）”；
- 路径示例：
tests/integration/conftest.py里的scope="module"autouse fixture，只对tests/integration/下的测试文件生效 - 兼容性注意：旧版 pytest（pytest>=6.2
- 调试技巧：加
-s -v运行，看输出中 fixture 名字是否出现在每个测试前，确认是否真被加载
autouse 看似省事，实际最麻烦的是隐式依赖和 teardown 失效——尤其当多个 autouse fixture 互相依赖或修改同一全局状态时，顺序和生命周期就很难推断清楚。
