跨模块发布-订阅中，观察者被静态事件、单例服务或第三方事件管理器强引用是内存泄漏主因；需用内存分析工具验证实例增长，定位retainers中的跨模块引用链，并通过weakeventmanager、显式dispose或abortsignal等机制切断强引用。
跨多模块发布-订阅模式中，观察者之间形成强引用链是内存泄漏的高发场景。问题核心不在“谁发消息”，而在于“谁一直被谁拽着不放”——尤其当模块间边界模糊、生命周期不同步时，一个本该释放的对象可能被远端模块里的静态事件、全局监听器或长生存期服务持续持有。
确认是否存在跨模块强引用滞留
先验证泄漏是否真实存在，而非误判：
- 在关键操作（如模块A打开→交互→关闭）前后，用内存分析工具（如 Visual Studio Diagnostic Tools、PerfView 或 Chrome Memory 面板）拍下堆快照
- 筛选目标模块类名（如 ModuleBViewModel、DashboardService），查看实例数量是否随反复进入/退出持续增长
- 对疑似残留对象展开 Retainers（保留者）视图，重点找非本模块的引用源头，例如：
– StaticEventPublisher.OnDataChanged
– GlobalEventBus.Subscribers
– window.addEventListener 持有的闭包
– Map中未清理的回调项
定位强引用路径中的“中间人”
跨模块泄漏往往不是 A 直接引用 B，而是 A → C → B 这样的三级甚至更长链。常见“中间人”包括：
-
静态事件总线：如
public static class EventBus { public static event Action<object> Published; }</object>—— 一旦模块注册后忘记注销，整个链路就锁死 -
单例服务持有的委托集合：比如
INavigationService内部维护了List<action></action>，但未提供清除接口 -
第三方库封装的事件管理器：某些 UI 框架（如 Avalonia、MAUI）的路由或消息中心若未显式调用
Unsubscribe或Dispose，会隐式延长观察者寿命 -
Lambda 订阅 + 无引用变量：如
eventBus.Subscribe(x => UpdateUI(x));—— 因无法生成相同委托实例，后续无法精准 -= 解绑
检查模块卸载时的清理契约是否被执行
多模块协作必须有明确的“谁负责解绑”的约定。排查时逐项核对：
- 模块 A 初始化时向模块 B 的服务注册监听，是否在 A 的 OnDisappearing、OnDestroy 或 IDisposable.Dispose() 中执行对应取消逻辑？
- 模块 B 提供的订阅方法是否返回 IDisposable（如
eventBus.Subscribe(...)返回可释放句柄）？调用方是否保存并正确释放？ - 是否存在“一方已销毁，另一方还在发通知”的竞态？例如模块 C 在后台线程中持续触发事件，而模块 D 的监听器早已被 GC 标记但因强引用未回收
- 检查 WeakReference 或 WeakEventManager 是否被误用为“万能解药”——若模块本身未参与弱引用管理（如直接传入 this 而非 WeakReference
），仍会形成强引用
用弱引用机制切断非必要生命周期绑定
对确实需要跨模块通信但又不能强耦合的场景，主动降级引用强度：
- C# 中优先使用 WeakEventManager 替代原生事件：它内部用 WeakReference 存储监听器，避免阻止 GC
- 自定义事件总线时，将订阅者存入 ConditionalWeakTable，确保监听器被回收时自动清理回调
- JavaScript/Vue 中，避免在
mounted中用this.xxx绑定全局监听器；改用局部变量 +onBeforeUnmount清理，或借助AbortSignal自动解绑 - 对于无法修改的第三方库，可在模块销毁前主动调用其 .destroy()、.clearListeners() 等显式释放方法（查阅文档确认是否存在）
