Python跨模块单例通信本质是sys.modules的模块缓存机制，而非类级单例控制；直接在模块中定义可变全局对象即可共享状态，模块对象由解释器保证唯一性。
Python单例通信的本质是模块缓存，不是类实例控制
Python里所谓“跨模块单例”，根本不是靠 __new__ 或装饰器实现的类级单例，而是依赖 sys.modules 对已导入模块的缓存机制。只要两个模块 import 同一个模块路径（比如 from mypkg.config import settings 和 import mypkg.config），它们拿到的就是内存中同一个模块对象——它的全局变量天然共享。
这意味着：你不需要写单例类，直接在模块里定义一个可变对象（如 dict、list、自定义类实例）即可作为跨模块通信载体。
- 模块首次被 import 时执行一次顶层代码，后续 import 直接返回缓存对象
- 修改该模块中的可变全局变量（如
shared_state = {"ready": False}），所有引用它的模块立刻可见变更 - 不可变对象（如
int、str）赋值会切断引用，必须用.update()、.append()等就地修改方法
如何安全地在模块中定义共享状态对象
直接在模块顶层写 state = {} 看似简单，但容易因导入顺序或重载导致状态不一致。推荐封装成惰性初始化的实例：
# shared.py
class SharedBus:
_instance = None
<pre class="brush:php;toolbar:false;">def __new__(cls):
if cls._instance is None:
cls._instance = super().__new__(cls)
cls._instance.data = {}
cls._instance.callbacks = []
return cls._instance模块级单例实例（注意：不是类，是实例）
bus = SharedBus()
这样做的好处是：避免模块重载（importlib.reload()）时重复初始化；显式区分“定义”和“使用”；便于加锁或扩展生命周期管理。
立即学习“Python免费学习笔记（深入）”；
Claw Code Suite (Python-Only Edition)
下载
仅使用 Python 将 Claw Code 虚拟化框架与 OpenClaw 集成，提供 184 种工具和 200 多条命令，用于安全分析和代码质量...
- 其他模块统一用
from shared import bus，不是import shared后访问shared.bus（虽等价，但前者更清晰） - 不要在
shared.py里调用bus.data.update(...)初始化数据——这会让导入即产生副作用 - 若需预设初始值，改用函数
init_defaults()，由主模块显式调用
为什么用模块级对象比用单例类更可靠
基于类的单例（如用 @singleton 装饰器或 __new__ 控制）在跨模块场景下极易失效：
- 不同模块分别
from utils import MySingleton和import utils→ 可能触发两次类定义（尤其涉及reload或多路径导入时） - 类单例依赖
cls._instance类变量，但类本身可能被多次构造（模块 reload 后类对象已不是原对象） - 模块对象由 Python 解释器保证唯一性，类对象则无此保障
- 调试时
id(bus)在所有模块中一致，而id(MySingleton())可能不一致
换句话说：模块是 Python 的“天然单例容器”，强行套用设计模式反而引入不确定性。
常见陷阱：reload、多进程、测试隔离
模块级共享在以下场景会失效或引发问题，必须提前识别：
-
importlib.reload()会清空sys.modules中对应项，重建模块对象 → 原来的bus.data彻底丢失 - 多进程（
multiprocessing）中每个子进程有独立的sys.modules→ 模块级变量不共享，需改用multiprocessing.Manager或消息队列 - 单元测试中频繁 import/reload 模块 → 推荐在
setUp中手动重置shared.bus.data.clear()，而非依赖模块重载 - 异步环境（如 asyncio）中多个 task 并发读写同一
dict→ 需加asyncio.Lock，模块共享不等于线程/协程安全
真正跨模块通信的难点从来不在“怎么让变量唯一”，而在于“谁负责初始化、谁负责清理、谁来保证并发安全”。模块机制只解决唯一性，其余都得自己兜底。
