应避免在基类中使用autouse=true的module/session级fixture，子类重定义同名fixture时需显式注入父fixture（如extended_config(base_config)），并按职责设不同scope，禁用unittest.testcase继承以确保fixture生效。
fixture 怎么覆盖父类测试配置而不污染子类
继承链越深，fixture 越容易互相覆盖或漏加载。Pytest 默认按作用域和名字匹配 fixture，setup_method 类方法或 __init__ 构造函数里的初始化逻辑，在 fixture 里重复写就容易出错。
实操建议：
- 用
@pytest.fixture(autouse=True)+scope="function"控制粒度，避免在基类里用autouse=True的 module 或 session 级 fixture - 子类中重定义同名 fixture 时，显式调用
super_fixture（通过参数注入），而不是靠 pytest 自动查找：比如基类定义base_config，子类写def extended_config(base_config) - 避免在 fixture 里直接修改类属性（如
MyClass.default_timeout = 5），这会跨测试用例残留；改用实例属性或局部变量
多层继承下如何让每个层级的 fixture 只初始化一次
比如 A ← B ← C，你希望 A 层 fixture 初始化数据库连接、B 层准备 mock 服务、C 层构造具体业务对象——但默认情况下，pytest 对每个测试函数都重新运行所有 fixture，导致重复 setup。
实操建议：
- 按职责拆分 fixture 作用域：
db_conn设为scope="session"，mock_service设为scope="class"，business_obj设为scope="function" - 在 class 级 fixture 中缓存实例：用
cls._cached_instance = ...+if not hasattr(cls, '_cached_instance')判断，比依赖 scope 更可控 - 注意 scope 越大，越容易遇到 teardown 顺序问题；
yieldfixture 必须确保 yield 后的清理代码在正确时机执行，尤其涉及线程/进程资源时
测试类继承 pytest.TestCase 时 fixture 不生效怎么办
如果用了 class TestBase(unittest.TestCase) 再继承，pytest 的 fixture 注入机制会失效——因为 pytest 只对以 Test 开头、且不继承 unittest.TestCase 的类自动支持 fixture。
Python 3.14.2是Python编程语言在2025年12月5日发布的稳定版本，属于3.14系列的第二个维护更新。该版本包含了18项修复，重点解决了多进程、数据类及正则表达式等模块的回归问题，并修复了CVE-2025-12084等安全漏洞。此版本标志着自由线程模式（移除GIL）正式获得官方支持，是Python发展的重要里程碑。
常见错误现象：
- fixture 参数出现在 test 方法签名里，但报
TypeError: test_xxx() missing 1 required positional argument - 明明写了
@pytest.fixture，但断点调试发现根本没进该函数
实操建议：
- 彻底放弃
unittest.TestCase继承，改用纯 pytest 风格：删掉self.setUp()，把逻辑移到 fixture 中 - 如果必须兼容 unittest（比如跑在旧 CI 上），用
pytest_plugins = ["pytest_unittest"]并配合@pytest.mark.usefixtures("my_fixture")显式声明 - 不要混用
setUp和 fixture 处理同一类资源（比如都去连 DB），否则可能 double-close 或 connection lost
fixture 返回复杂对象时，子类怎么安全地 patch 或 reset 其状态
比如基类 fixture 返回一个带内部状态的 ApiClient 实例，子类测试需要临时 patch 某个方法返回值，但又不能影响其他测试用例——这时直接用 monkeypatch 或 patch 容易泄漏。
实操建议：
- 在 fixture 内部用
with+patch包裹，确保退出时自动还原：with patch("mod.Client.get") as m: yield Client(); m.reset_mock() - 子类中定义新 fixture 时，优先用参数形式接收父 fixture 实例，再做 patch：
def patched_client(api_client): with patch.object(api_client, 'fetch') as m: ... yield api_client - 避免在
__del__或atexit里清理 fixture 创建的资源，pytest 的 teardown 是同步且确定的，依赖异步钩子反而不可靠
继承链越长，fixture 的生命周期管理越容易变成“谁建的谁负责清理”这种模糊地带。最稳妥的方式是：每个 fixture 明确自己创建什么、销毁什么，不假设上层或下层会帮忙兜底。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
