Blazor 怎么在组件销毁时释放资源
Blazor组件销毁时应实现IDisposable或IAsyncDisposable接口释放资源：IDisposable用于同步清理（如取消事件订阅、释放Timer），IAsyncDisposable推荐用于异步操作（如取消HTTP请求）；注意Dispose中不可调用StateHasChanged，且不保证一定执行，关键资源需尽早显式释放。
mer），IAsyncDisposable推荐用于异步操作（如取消HTTP请求）；注意Dispose中不可调用StateHasChanged，且不保证一定执行，关键资源需尽早显式释放。Blazor 组件销毁时释放资源，核心是实现 IDisposable 或使用 IAsyncDisposable（推荐用于含异步清理的场景），并在对应方法中执行清理逻辑。
实现 IDisposable 清理同步资源
适用于取消订阅事件、释放 Timer、关闭同步流、释放非托管句柄等场景。组件继承自 ComponentBase 后，直接实现接口即可：
- 重写
Dispose(bool disposing)，在disposing == true时清理托管资源 - 调用基类
base.Dispose(disposing)确保父类逻辑执行 - 避免在
Dispose中调用虚拟方法或触发状态更新（如StateHasChanged()），此时组件已不可用
示例：
public class MyComponent : ComponentBase, IDisposable
{
private Timer? _timer;
protected override void OnInitialized()
{
_timer = new Timer(_ => { /* 定时任务 */ }, null, TimeSpan.Zero, TimeSpan.FromSeconds(5));
}
public void Dispose()
{
_timer?.Dispose();
GC.SuppressFinalize(this);
}}
使用 IAsyncDisposable 处理异步清理
当需 await 异步操作（如取消 HTTP 请求、关闭 SignalR 连接、释放数据库连接池资源）时，优先实现 IAsyncDisposable：
- Blazor Server 和 WebAssembly 均支持该接口（.NET 5+）
-
DisposeAsync()会在组件卸载前被框架自动调用 - 可安全 await，但不要在此方法中调用
InvokeAsync(StateHasChanged)—— 组件生命周期已结束
示例：
public class DataFetcher : ComponentBase, IAsyncDisposable
{
private HttpClient _httpClient = new();
public async ValueTask DisposeAsync()
{
await _httpClient.CancelPendingRequestsAsync(); // .NET 8+
_httpClient.Dispose();
GC.SuppressFinalize(this);
}}
注意组件生命周期与框架调用时机
Blazor 不保证 Dispose 或 DisposeAsync 一定被调用（如页面强制刷新、异常中断），因此：
- 关键资源（如文件句柄、网络连接）建议设为
using或尽早显式释放 - 避免依赖
Dispose执行业务关键逻辑（如保存用户数据），应改在用户操作或导航前完成 - 在
OnParametersSet或OnInitialized中重复注册资源时，先检查并清理旧实例，防止内存泄漏
服务注入场景下的资源管理
若组件依赖的服务本身实现了 IDisposable 或 IAsyncDisposable，且由 Blazor 的 DI 容器提供（作用域为 Scoped 或 Transient）：
- 组件无需手动释放该服务 —— 框架会在作用域结束时统一释放
- 但如果你在组件内
new了服务实例，或用了ActivatorUtilities.CreateInstance，就必须自己负责释放 - 跨组件共享资源（如全局 WebSocket 实例）建议提取到
Singleton服务中，并由该服务自身管理生命周期
基本上就这些。不复杂但容易忽略的是：别在 Dispose 里搞 UI 更新，也别假设它一定会执行 —— 关键资源要“早释放、早保险”。
