c# BeginInvoke / EndInvoke 模式和 Task 模式的转换

BeginInvoke/EndInvoke是.NET Framework 1.0起的异步委托机制，现不推荐新代码使用；应改用Task.Run或FromAsync转换，注意UI上下文、异常处理及AsyncLocal语义迁移。

BeginInvoke / EndInvoke 是什么，现在还该用吗

它是一套基于 .NET Framework 1.0 就存在的异步委托调用机制，本质是借用了 ThreadPool，通过 BeginInvoke 发起调用、EndInvoke 阻塞等待结果或获取异常。但现在（.NET Core / .NET 5+）**不推荐新代码使用**——它没有 async/await 的可组合性，无法取消，异常处理笨重，且容易因漏掉 EndInvoke 导致资源泄漏或死锁。

如何把 BeginInvoke / EndInvoke 转成 Task 模式

最直接的方式是用 Task.Factory.FromAsync 包装，但仅适用于有标准 IAsyncResult 模式（即成对的 BeginXxx/EndXxx 方法）的委托。对普通委托（比如 Func），需手动封装：

var func = new Func(() => {
    Thread.Sleep(1000);
    return 42;
});

// 转为 Task
Task task = Task.Run(func);

若必须保留原有 BeginInvoke 调用点（如维护老代码），可用以下模式桥接：

• BeginInvoke 后立即用 task = Task.Factory.FromAsync(beginDelegate, endDelegate, state)
• 注意：委托签名必须匹配 BeginInvoke 的参数顺序（输入参数 + AsyncCallback + object）
• 如果原方法无 EndInvoke 调用（比如只 fire-and-forget），改用 Task.Run 更安全

常见转换陷阱和兼容性问题

直接替换时容易忽略三点：

• BeginInvoke 的目标委托若捕获了 UI 线程上下文（如 WinForms/WPF 中的 this.InvokeRequired 场景），Task.Run 会脱离

  

  上下文——需显式用 Control.Invoke 或 Dispatcher.Invoke 回到 UI 线程
• EndInvoke 会重新抛出原始异常；而 Task 异常被包裹在 AggregateException 中，await task 会自动解包，但直接读 task.Exception 需遍历 InnerExceptions
• .NET Standard 2.0+ 和所有现代运行时已移除对 Delegate.BeginInvoke 的 JIT 优化支持，性能比 Task.Run 差约 2–3 倍（实测小委托场景）

Task.Run 不是万能替代，何时该用 ConfigureAwait 或 IProgress

如果原 BeginInvoke 是为了“后台跑一段耗时逻辑并更新 UI”，单纯换 Task.Run 只解决了一半：

• 后台工作用 Task.Run 没问题
• 但结果回传到 UI 层不能靠 await 自动调度——WPF/WinForms 默认会捕获 SynchronizationContext，但控制台或 ASP.NET Core 则不会。生产代码应明确写 await task.ConfigureAwait(true)（需要上下文）或 false（不需要）
• 若需进度通知（类似老代码里用 AsyncCallback 分段回调），优先用 IProgress + Report，而不是模拟多次 BeginInvoke

真正麻烦的不是语法转换，而是上下文语义迁移：原来靠线程隐式传递的 HttpContext、CallContext、AsyncLocal 在 Task 模型下行为不同，尤其跨 await 边界时容易丢失——这点几乎没人一开始想到。