EventAggregator替代方案咨询：Blazor Server多组件感知CurrentCustomer变更的实现

针对从Silverlight迁移Blazor Server项目的场景——因第三方通用EventAggregator出现事件触发时机异常、故障难定位，需要实现多组件同步响应当前客户变更的核心需求，下面是官方和业界通用的可落地方案：

官方首选：Scoped生命周期强类型状态容器 #

这个方案是Blazor官方文档明确推荐的跨组件通信核心模式，完全适配Blazor Server的Circuit托管模型，没有第三方组件的黑盒逻辑，调试成本极低。

• 核心实现逻辑依托内置依赖注入完成：
  • 注册一个与当前用户会话（Circuit）绑定的Scoped服务，服务内部维护共享的CurrentCustomer属性，以及对应的值变更事件。
  • 当CurrentCustomer被赋值更新时，服务主动触发变更事件，所有提前订阅的组件会同步收到通知，完成自身数据刷新。
• 相比通用EventAggregator的核心优势：
  • 生命周期严格和用户会话绑定，不会出现跨用户的事件串扰
  • 订阅、触发、解绑的逻辑完全由代码显式控制，不会出现第三方组件自动绑定带来的订阅错位、内存泄漏问题
• 最简化的代码实现参考：
  1. 全局注册状态服务（Program.cs）：

  builder.Services.AddScoped<CustomerStateService>();
  

  2. 状态服务定义：

  public class CustomerStateService
  {
      private Customer _currentCustomer;
      // 公开的变更通知事件
      public event Action OnCurrentCustomerChanged;
  
      public Customer CurrentCustomer
      {
          get => _currentCustomer;
          set
          {
              _currentCustomer = value;
              // 值更新时触发所有订阅方通知
              OnCurrentCustomerChanged?.Invoke();
          }
      }
  }
  

  3. 组件端的订阅逻辑：

  @inject CustomerStateService CustomerState
  @implements IDisposable
  
  // 组件初始化时订阅变更
  protected override void OnInitialized()
  {
      CustomerState.OnCurrentCustomerChanged += SyncCustomerData;
  }
  
  // 收到通知后刷新组件视图
  private void SyncCustomerData()
  {
      // Blazor Server场景下跨线程回调需要切回渲染上下文执行
      InvokeAsync(StateHasChanged);
  }
  
  // 组件销毁时必须解绑事件，避免订阅错位、内存泄漏
  public void Dispose()
  {
      CustomerState.OnCurrentCustomerChanged -= SyncCustomerData;
  }
  

嵌套组件树优化：级联值透传状态服务 #

如果你的组件树层级较深，不想每一层组件都手动注入状态服务做参数透传，可以在组件树的根节点（布局组件、路由组件）上把状态服务作为级联值下发：

• 根节点通过<CascadingValue Value="CustomerState">包裹所有子组件
• 深层的子组件直接通过[CascadingParameter]拿到状态服务实例，和上述逻辑一致完成事件订阅、数据同步即可，不需要逐层传递参数。

第三方通用EventAggregator容易出现触发异常的原因 #

大部分开源的通用EventAggregator实现，在Blazor Server场景下有两个天然适配缺陷：

• 多数实现默认采用Singleton生命周期注册，导致所有用户共享同一个事件总线，极易出现跨用户的事件串扰
• 自动绑定的订阅关系没有和组件的销毁周期挂钩，组件回收后订阅关系依然残留，时间长了会出现回调指向已销毁实例、订阅关系错位的玄学问题，直接表现就是“事件发了收不到”“事件在错误的时机触发”，且很难定位根因。

而当前需求非常垂直：仅需要同步“当前客户变更”这一类通知，完全不需要通用事件聚合器的复杂路由逻辑，自定义实现的状态服务代码量极少，所有流程完全可见，不会出现黑盒故障。

配套落地的注意事项 #

• 所有对CurrentCustomer的修改操作，尽量集中在状态服务内部完成，不要在各个组件中随意修改共享属性，避免重复触发通知导致的刷新逻辑混乱
• 订阅和解绑的逻辑必须成对写在组件的初始化和销毁阶段，不要遗漏解绑步骤，这是Blazor跨组件通信中最容易踩的坑
• 如果后续需要扩展更多全局通知（比如权限变更、系统配置更新），直接在现有状态服务中新增对应事件即可，不需要引入额外的第三方依赖

内容的提问来源于stack exchange，提问作者Greg Gum