autouse=True用于自动执行无需显式传参的上下文初始化操作，如日志配置、环境变量设置、全局mock替换；其作用域选择不当会导致性能问题或测试污染，且因隐式生效而难以调试。
因为不加 autouse=True，很多初始化逻辑就只能靠手动传参或重复调用，一漏就崩，一改就满盘重修。
哪些初始化操作根本没法“显式传参”？
比如日志配置、环境变量设置、全局 mock 替换——这些不是“资源”，而是“上下文”。你不能把它当参数传给每个测试函数，因为测试函数根本不消费它。
-
logging.basicConfig()只需执行一次，但必须在所有测试开始前生效 -
os.environ["DEBUG"] = "1"要在导入模块前就设好，否则被缓存的模块读不到 - 用
unittest.mock.patch替换整个模块的底层函数时，patch 必须在测试函数执行前就“生效”，而不是等 fixture 返回某个对象再手动 apply
autouse=True 的作用域选错会直接导致测试污染
同一个 fixture，scope="function" 和 scope="session" 表现天差地别：
macOS UI 自动化技能包 —— 用 Python 控制你的 Mac
下载
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
- 设成
function却干了数据库连接这种重操作 → 每个测试都连断一次，跑 200 个用例可能超时 - 设成
session却干了临时文件创建 → 所有测试共享一个目录，test_a写的文件可能被test_b误删或覆盖 - 多个
autousefixture 之间有依赖（比如先设环境变量，再加载配置），但定义顺序写反了 → 配置加载时读不到变量，静默失败
为什么 autouse=True 容易被当成“魔法”，结果调试抓狂？
它不显式出现在测试函数签名里，所以你 grep test_xxx 根本看不到它在哪儿生效。问题常出现在：
- 某个测试行为异常，你翻遍测试函数和显式 fixture，却忘了
conftest.py里有个scope="module"的autouse在悄悄清空全局状态 - 用
pytest -s看输出，发现日志里多了一堆没来由的 “Setting up…” —— 那就是 autouse fixture 在暗处执行 - 想临时禁用某个 autouse fixture？不能像普通 fixture 那样不传参跳过，得用
@pytest.mark.usefixtures("fixture_name")显式覆盖，或者干脆注释掉定义
真正难的从来不是写 autouse=True，而是判断“这个操作到底该不该自动、在哪儿自动、会不会干扰别人”。它省的是代码行数，吃的是设计清晰度。一旦跨模块、跨团队协作，隐式行为比显式依赖更危险。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
