推荐初学者用标准库weakref自定义事件总线，生产项目用blinker库；核心是解耦模块依赖，需防范循环发布、异常中断、生命周期错配等陷阱。
Python项目中实现跨模块事件发布与订阅，核心是解耦模块间直接调用，让一个模块“发消息”，其他模块“听消息”而不互相依赖。关键不在于造轮子，而在于选对轻量、可控、易调试的方案。
用标准库 weakref + 自定义事件总线（推荐初学者）
不依赖第三方，逻辑透明，适合中小项目或想理解底层机制的场景。本质是维护一个事件名到回调函数列表的映射，用 weakref 避免内存泄漏（防止订阅者被意外强引用导致无法回收）。
- 定义一个全局或单例的
EventBus类，内部用defaultdict(list)存储事件名与弱引用回调 -
subscribe(event_name, callback)：用weakref.WeakMethod(callback)或weakref.ref(callback)注册 -
publish(event_name, *args, **kwargs)：遍历对应回调列表，调用前检查引用是否有效（cb_ref() is not None） - 模块A只需 import 这个 EventBus 并 publish；模块B import 后 subscribe，彼此无导入依赖
用 blinker 库（推荐生产项目）
轻量、成熟、支持信号分组、临时订阅、自动清理，比手写更稳。安装：pip install blinker。
- 定义信号：
user_registered = signal('user-registered') - 模块B订阅：
user_registered.connect(handle_user_registration, sender=ANY) - 模块A触发：
user_registered.send(app, user_id=123, email="a@b.com") - 支持 sender 过滤（如只响应某类对象发出的信号）、临时连接（
connect_via）、异步兼容（配合 asyncio.run_in_executor 等）
避免常见陷阱
事件机制看似简单，实际落地容易踩坑：
立即学习“Python免费学习笔记（深入）”；
- 循环发布：A 订阅 X 事件 → 处理时又 publish X → 无限递归。解决：加标记位、用队列延后处理、或明确事件流向（如只允许“业务层→UI层”，禁止反向）
- 异常中断：一个订阅者崩溃，不应阻断其他订阅者。blinker 默认会捕获并记录异常；自定义总线需在 publish 循环内 try/except
-
生命周期错配：模块B已卸载但未 unsubscribe，仍接收事件。用 weakref 或显式调用
disconnect()（blinker 支持） -
命名冲突：建议统一前缀，如
auth.login.success、payment.refund.completed，便于排查和过滤
进阶：按需集成异步支持
如果项目用 asyncio，不要强行把同步事件总线塞进协程。更合理的方式是：
- 保持事件总线本身同步，但在订阅回调里用
asyncio.create_task()或await loop.run_in_executor()调度耗时操作 - 或选用支持 async 的库，如
aiosignal（专为 aiohttp 设计）或封装 blinker + asyncio.Queue 做异步中转 - 避免在 publish 里 await —— 会拖慢所有同步发布者
基本上就这些。跨模块通信不是越复杂越好，清晰、可测、易查才是关键。从 weakref 总线起步，跑通再换 blinker，比一上来堆装饰器+元类+反射要实在得多。
