单例测试失败主因是跨测试状态残留，应使用function级fixture重置singleton._instance为none并验证其为none；断言需用s1=singleton();s2=singleton();assert s1 is s2确保内存地址一致。
直接用 s1 is s2 断言两个 Singleton() 调用结果，大概率失败——不是单例写错了，而是测试环境让类对象被重复加载，id(Singleton) 都不一致，自然无法共享同一个 _instance。
为什么 test_a 和 test_b 看起来“互相污染”
单例实例常驻在模块生命周期内，而 pytest 默认不重载模块。只要一个测试调用了 Singleton()，Singleton._instance 就被设为非 None；后续测试再调用，拿到的就是前一个测试留下的对象，字段值、内部状态全都被继承下来。
- 典型现象：test_a 修改了
s = Singleton(); s.counter += 1，test_b 中Singleton().counter已经是 1，而非预期的 0 - 根本原因不是代码逻辑错，而是
_instance类变量跨测试存活 - 即使你写了
__new__+cls._instance缓存，只要没清理，它就一直挂着
怎么安全地重置单例状态（function 级）
最稳的方式是每个测试开始前手动把单例“退回到未初始化状态”，而不是依赖 monkeypatch 或 reload —— 后者容易漏掉绑定逻辑或触发意外副作用。
Python Sdk
下载
inference.sh 的 Python SDK：运行 AI 应用、构建智能体，并集成 150 多个模型。包名：inferencesh (pip install inferencesh)。支持同步/异步……
- 先确认状态存在哪：常见是
Singleton._instance、Singleton.__instance，极少数藏在模块级变量里 - 用
@pytest.fixture(scope="function", autouse=True)注入重置逻辑，比setup_method更符合 pytest 习惯 - 写法要直白：
Singleton._instance = None，别用monkeypatch.setattr(...)—— 它可能被__dict__直接赋值绕过 - 加一行验证更安心：
assert Singleton._instance is None放在 fixture yield 前
怎么写断言才真正验证“唯一性”
单例的本质不是“调用同一个类”，而是“任意调用都返回同一块内存”。所以必须绕过类对象一致性，直击运行时实例地址。
- 错误写法：
assert Singleton() is Singleton()—— 如果两次调用之间类被 reload 过，会创建不同类的实例，is必然 False - 推荐写法：
s1 = Singleton(); s2 = Singleton(); assert s1 is s2，确保两次调用发生在同一上下文 - 更底层但更可靠：
assert id(Singleton()) == id(Singleton())，内存地址比对不依赖类身份 - 别只测“能创建”，一定要覆盖“多次调用是否真复用”——这是生产环境唯一关心的事
多个单例共存时容易忽略的细节
当项目里有 DBConnection、ConfigLoader、Logger 多个单例类时，重置逻辑不能图省事一刀切。
- 别给所有单例 fixture 加
autouse=True：一个测试只用到ConfigLoader，却清空了DBConnection._instance，可能干扰其他测试 - 按需声明 fixture 参数：
def test_something(reset_config_loader):，语义清晰且可追溯 - 如果单例用了继承（比如
BaseSingleton→RedisClient），清理时确认操作的是子类的_instance，不是父类的 - 构造函数有副作用（如建 TCP 连接）？fixture 里得一并 mock 掉
__init__，否则重置后下次调用仍会触发真实连接
最难的从来不是写重置代码，而是准确识别单例把状态存在哪——有时它不在 _instance，而在闭包里、模块全局 dict 里、甚至 C 扩展的静态变量里。先 print 出来，再动手。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
