Blazor组件间状态变更传递方案咨询：自制事件总线是否可行？

1. 事件总线方案是否属于Blazor推荐实践？ #

事件总线在Blazor中是可行但非首选的方案。对于无直接层级关系的组件间状态同步，它能快速解决问题，但需要注意两个关键点：

• 必须在组件销毁时（IDisposable.Dispose）取消事件订阅，否则会引发内存泄漏
• 复杂场景下容易导致事件泛滥，难以追踪状态变更链路

如果是小型应用或简单的跨组件通信需求，自制事件总线完全可以用；但中大型项目更建议用Blazor原生或更规范的状态管理方案。

2. 现成的替代工具 #

不需要自己造轮子，有不少成熟工具可选：

• Blazored.EventBus：专门为Blazor设计的轻量事件总线库，内置了订阅管理、自动清理等功能，适配WebAssembly和Server模式
• MediatR：CQRS风格的中介库，不仅能处理命令，也支持事件发布订阅，适合需要解耦业务逻辑的场景
• 状态管理库：比如Fluxor、Blazor State，这些库自带事件驱动的状态更新机制，同时能统一管理全局状态，比单纯的事件总线更规范

3. Blazor特有的状态传递方式 #

如果放弃事件总线，这些Blazor原生/专属方案更贴合框架特性：

• 组件参数+EventCallback：如果组件有间接父子关系（比如都属于UserExplorer的子组件），可以把状态放在父组件UserExplorer中，AddUser通过EventCallback通知父组件用户新增，父组件再更新ViewUsers的列表参数，触发ViewUsers重新渲染
• 全局状态服务：通过依赖注入注册单例/作用域的状态服务（比如UserStateService），服务内部维护用户列表，实现INotifyPropertyChanged或用Observable，组件注入后监听状态变更，自动刷新UI
• 级联参数（CascadingValue/CascadingParameter）：适合跨多层组件传递共享状态，比如把用户列表包装在CascadingValue中，下层的AddUser和ViewUsers通过CascadingParameter获取，状态变更时触发全局刷新
• 服务器端Blazor的ComponentState：如果是Server模式，可利用框架内置的组件状态追踪，但更适合特定场景，不如前几种通用

内容的提问来源于stack exchange，提问作者Matthew Layton