C#怎么实现发布订阅模式 C#如何用事件总线EventBus实现模块间的松耦合消息通信【架构】

C#原生eventdelegate可实现发布订阅需用private字段封装event、判空调用、及时反订阅防泄漏MediatR适用于需管道中间件的场景ChannelT适合后台批量消费事件总线非万能解耦方案。用 event delegate 实现最简发布订阅不用引入任何第三方库C# 原生就能跑通核心逻辑。关键不是“怎么写”而是“谁该负责订阅、谁该触发、委托签名要不要泛型”。常见错误是把 event 声明成 public 字段——这会让外部直接赋值覆盖所有监听器彻底破坏订阅机制。必须用 private 字段 public 事件包装器或直接用自动实现的 event。delegate 类型推荐用 ActionT 或自定义泛型委托避免为每种消息类型写一堆非泛型委托触发事件前务必判空MyEvent?.Invoke(data)否则空引用异常在生产环境很难定位如果发布者生命周期短于订阅者比如窗体关闭后后台任务还在发消息记得在释放时调用 - 反订阅否则引发内存泄漏public class NewsPublisher{ public event Actionstring NewsPublished; public void Publish(string news) NewsPublished?.Invoke(news);}用 MediatR 替代手写 EventBus 的真实理由MediatR 不是“更高级的 EventBus”它是把请求/响应、通知、管道中间件这几层职责拆清楚了。如果你只想要“发个消息让别人收到”用它反而绕路但如果你需要“发完消息后统一加日志、验证、事务包装”它就省掉大量胶水代码。容易踩的坑是混淆 IRequestHandler 和 INotificationHandler前者是一对一同步处理如保存订单后者才是一对多广播即传统意义上的发布订阅。注册必须用 AddMediatR(Assembly)漏掉程序集会导致 Handler not found 错误且无明确提示INotification 默认异步执行但不会自动 await 所有 handler —— 如果某个 handler 抛异常其他 handler 仍会继续执行这点和原生 event 不同不要在 handler 里直接 new DbContextMediatR 的 scope 生命周期和 ASP.NET Core 的 request scope 对齐应通过构造函数注入System.Threading.Channels 适合什么场景下的“发布订阅”当你的“订阅者”其实是消费者线程比如后台工作队列、批量处理任务而不是 UI 更新或业务逻辑响应时ChannelT 比事件模型更合适。它天然支持背压、限流、取消且不依赖对象引用关系。 VWO 一个A/B测试工具