C# 中的异步委托（Asynchronous Delegates）还推荐使用吗？

异步委托在 C# 中通常指通过 Delegate.BeginInvoke 和 EndInvoke 启动后台执行，并借助 IAsyncResult 获取结果。它属于早期异步编程模型 APM 的一部分，在当前主推的 async/await 模式出现前，确实承担了大量后台任务。但这项技术是否还值得在新代码中继续使用，答案基本是否定的。

一、异步委托的工作机制与历史背景

在 C# 中，任何一个委托类型都提供 BeginInvoke 和 EndInvoke 方法。调用 BeginInvoke 时，公共语言运行时会把委托目标投递到线程池，并立即返回一个 IAsyncResult 对象。之后可以通过轮询 IsCompleted、等待 WaitHandle 或者注册 AsyncCallback 回调来获取执行结果。EndInvoke 用于接收返回值并抛出执行过程中的异常。

这种模型属于早期的异步编程模式 APM。它把同步方法包装成异步调用，不需要开发人员手动创建线程。对于 CPU 密集型工作，异步委托确实比直接 new Thread 更轻量，因为线程池会复用线程。下面的示例演示了最简单的用法：

Func<int, int> square = x => x * x;
IAsyncResult ar = square.BeginInvoke(8, null, null);
int result = square.EndInvoke(ar);
Console.WriteLine(result);

但是这种写法隐藏了很多细节。线程池线程执行完成后，结果和异常都暂存在 IAsyncResult 中，必须调用 EndInvoke 才能释放资源。如果忘记调用，很容易造成资源泄漏。回调方式虽然不用阻塞主线程，但会把代码拆成 BeginInvoke 和回调两个位置，流程变得零散。

二、异步委托在现代 .NET 中的兼容性问题

异步委托最大的硬伤是跨平台兼容性。.NET Framework 完整支持 Delegate.BeginInvoke，但 .NET Core 以及后续的 .NET 版本并没有实现这一能力。在这些运行时上调用任何委托的 BeginInvoke 方法，都会抛出 PlatformNotSupportedException。因此只要项目目标框架不是纯 .NET Framework，异步委托就不能作为可移植方案。

即使不考虑运行时限制，APM 设计本身也存在明显缺点。EndInvoke 与 BeginInvoke 必须成对出现，否则内部等待句柄和异常对象可能不被释放。回调线程来自线程池，如果回调中继续嵌套异步调用，代码会形成多层缩进，可读性很差。此外，异常不会自动回到原始调用上下文，捕获异常必须显式调用 EndInvoke，很多开发人员会遗漏这一点，导致后台异常被吞掉。

还有一点容易被忽略：异步委托只适合 CPU 密集任务。如果用它执行网络、磁盘等 I/O 操作，它仍然会占用线程池线程等待 I/O 完成，这与真正的异步 I/O 相比并不能提升吞吐量，反而会浪费线程资源。

三、推荐替代方案：Task.Run 与 async/await

现代 C# 的异步编程围绕 Task、async 和 await 展开，这种模式称为基于任务的异步模式 TAP。对于原先用异步委托执行的 CPU 密集工作，可以直接使用 Task.Run 包装同步委托。Task.Run 同样使用线程池，但返回 Task 对象，可以自然地 await、检查状态、等待完成。

Func<int, int> square = x => x * x;
int result = await Task.Run(() => square(8));
Console.WriteLine(result);

与 BeginInvoke 相比，Task 的优势非常明显。异常通过 await 重新抛出，不需要额外的 EndInvoke；Task 支持 ContinueWith、WhenAll、WhenAny 等组合操作；还可以配合 CancellationToken 取消任务，或者通过 IProgress 汇报进度。这些都是异步委托很难实现的。

需要注意的是，Task.Run 不是万能的。对于已经提供异步 API 的 I/O 操作，例如 File.ReadAllTextAsync、HttpClient.GetStringAsync、DbContext.SaveChangesAsync，应当直接 await 这些方法，而不是用 Task.Run 包装同步调用。Task.Run 主要用于没有异步版本的 CPU 密集计算，或者需要把长时间同步工作从 UI 线程移走。

四、旧代码迁移和实际选择建议

如果正在维护一个纯 .NET Framework 项目，并且现有代码大量使用 BeginInvoke 和 EndInvoke，并不意味着必须立刻全面重写。只要运行环境没有变化，这些代码仍然可以工作。但在新增功能或进行重构时，应当优先改为 Task 和 async/await，逐步降低对旧模型的依赖。

迁移时可以把一个异步委托调用改写成 Task.Run 包装，然后由调用方 await。比如原先通过回调获取结果，现在可以改为：先启动 Task，再继续其他工作，最后统一 await。这样更容易维护执行顺序，也方便统一异常处理。

如果项目需要跨平台，或者未来可能迁移到更高版本的 .NET，那么必须避免使用 Delegate.BeginInvoke。因为只要运行到 .NET Core 及以上环境，调用就会直接失败。即使使用条件编译隔离，也会增加测试成本。因此在新代码中不推荐继续使用异步委托。

总结来说，C# 中的异步委托已经完成历史使命。它帮助早期 .NET 开发者用简单方式调度后台任务，但如今无论是运行时支持、代码可读性还是异常模型，都无法与 Task 和 async/await 相比。新项目请直接使用 TAP，旧项目也应把异步委托作为迁移对象。

C#异步委托Task.Runasync/await修改时间：2026-08-30 23:59:38