Blazor WASM页面中嵌套类实例事件是否需始终手动取消订阅？

我有一个ClosestEvents.razor页面，其代码后置如下：

public partial class ClosestEvents: IDisposable
{
    private MyEventSource Source;

    protected override void OnInitialized()
    {
        Source = new MyEventSource();
        Source.OnDataUpdated += StateHasChanged;
    }

    public void Dispose()
    {
        if(Source != null)
            Source.OnDataUpdated -= StateHasChanged;
    }
}

请问是否必须始终手动取消订阅事件并实现Dispose方法？我了解未取消订阅可能导致GC无法回收内存，但在此场景中订阅者（页面组件）和事件源（MyEventSource实例）似乎都会被GC回收，是否可以不取消订阅？GC能否妥善处理这种情况？比如使用如下代码：

public partial class ClosestEvents
{
    private MyEventSource Source;

    protected override void OnInitialized()
    {
        Source = new MyEventSource();
        Source.OnDataUpdated += StateHasChanged;
    }
}

核心结论：建议始终手动取消订阅并实现IDisposable #

1. 理论上的循环引用可回收场景 #

如果组件实例和MyEventSource实例之间只有彼此的引用，没有任何外部对象（比如静态变量、全局服务、活动线程）持有其中任意一方，.NET的GC确实能通过可达性分析回收这两个对象——循环引用不会阻止GC回收，只要没有根节点引用它们，两者都会被标记为可回收。

2. 实际业务中的潜在风险 #

但Blazor组件的实际运行场景没这么理想：

• 外部引用导致泄漏：如果MyEventSource被全局服务、静态容器持有，或者组件被框架缓存（比如路由预渲染、组件库缓存策略），其中一方会被持活，另一方也无法被GC回收，直接造成内存泄漏。
• 销毁后触发事件引发异常：即使GC最终会回收，在回收前MyEventSource可能还会触发OnDataUpdated，此时组件已经被销毁，调用StateHasChanged会抛出“已释放的组件无法更新状态”之类的异常。
• 组件生命周期的标准要求：Blazor组件属于可销毁对象，实现IDisposable清理订阅是生命周期管理的标准做法，能避免复杂场景下的不可控问题——毕竟你很难保证所有场景都没有外部引用。

3. 简化实现的可选方案 #

如果觉得手动取消订阅繁琐，可以使用.NET的弱事件模式（Weak Event Pattern），或者封装一个辅助类自动管理订阅。但对于简单场景，直接在Dispose中取消订阅是最直接可靠的方式。

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