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<int>），需手动封装：
var func = new Func<int>(() => {
Thread.Sleep(1000);
return 42;
});
// 转为 Task
Task<int> task = Task.Run(func);
若必须保留原有 BeginInvoke 调用点（如维护老代码），可用以下模式桥接：
Unified LLM Gateway - One API for 70+ AI models. Route to GPT, Claude, Gemini, Qwen, Deepseek, Grok and more
下载
统一LLM网关 - 一个API对接70+AI模型，使用单一API密钥即可调用GPT、Claude、Gemini、Qwen、Deepseek、Grok等主流模型。
-
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<T>+Report，而不是模拟多次BeginInvoke
真正麻烦的不是语法转换，而是上下文语义迁移：原来靠线程隐式传递的 HttpContext、CallContext、AsyncLocal<T> 在 Task 模型下行为不同，尤其跨 await 边界时容易丢失——这点几乎没人一开始想到。
