async void 只能用于事件处理器，且必须是 UI 事件
这是唯一被官方默许的
async void使用场景。因为 .NET 的事件委托签名强制要求返回
void（如
EventHandler、
RoutedEventHandler），你无法把按钮点击事件改成返回
Task——那会直接编译失败。
所以当你写
private async void btnDownload_Click(object sender, EventArgs e)时，不是“偷懒”，而是被框架签名锁死的无奈选择。 ✅ 允许：WinForms
Button.Click、WPF
Button.Click、UWP
Button.Click等 UI 事件 ❌ 禁止：自定义事件（哪怕签名相同）、命令执行方法（如
ICommand.Execute）、ViewModel 中的任何方法、测试方法中的调用 ⚠️ 注意：ASP.NET Core MVC/Razor Pages 的控制器 Action 绝对不能用
async void——它不走事件循环，用就挂（500 错误且无堆栈）
异常会直接炸到 SynchronizationContext，没人接得住
async void方法里抛出的异常不会装进
Task，也不会被上层
try-catch捕获。它会顺着当前活跃的同步上下文（比如 WinForms 的 UI 线程消息泵）直接往上抛，最终触发
AppDomain.UnhandledException或
Application.ThreadException——轻则弹窗崩溃，重则静默退出。
这意味着你写的
try-catch只能兜住
await之后的代码，但若
await前就出错（比如参数校验失败），照样飞出去。 ✅ 必须在
async void方法内部做完整异常防护：整个方法体包在
try/catch/finally里 ✅ 在 WinForms 中注册
Application.ThreadException作为兜底；WPF 中监听
Application.DispatcherUnhandledException❌ 不要指望调用方（比如窗体初始化代码）能
try到这个方法的异常
别试图 await 它，它根本不支持等待
你不能在另一个异步方法里写
await btnDownload_Click(...)——编译器直接报错：“无法等待 void”。这导致两个实际问题： ❌ 无法串行化多个 UI 事件逻辑（比如“先保存再刷新再导出”，不能靠
await控制顺序） ❌ 无法在单元测试中可靠验证行为：你只能靠延时 + 状态轮询，或注入模拟依赖后手动触发事件 ✅ 补救思路：把核心逻辑拆成
async Task方法，在
async void里仅做调度和错误兜底
private async void btnDownload_Click(object sender, EventArgs e)
{
btnDownload.Enabled = false;
try
{
await DownloadAndShowAsync(); // ✅ 核心逻辑抽离为 Task
}
catch (Exception ex)
{
MessageBox.Show($"下载失败：{ex.Message}");
}
finally
{
btnDownload.Enabled = true;
}
}
private async Task DownloadAndShowAsync()
{
var data = await httpClient.GetStringAsync(url);
textBox.Text = data;
}
UI 线程死锁风险比你想的更隐蔽
如果你在
async void方法里不小心用了
.Result、
.Wait()或没加
ConfigureAwait(false)，而调用栈又涉及 UI 同步上下文（比如从 WPF
Dispatcher.Invoke内部发起），就可能卡死主线程 —— 因为 await 试图回调回 UI 线程，但 UI 线程正等着你那个
.Wait()返回。 ✅ 所有
await后的操作，默认都应加
.ConfigureAwait(false)（除非你明确需要回到 UI 上更新控件） ✅ 绝对禁用
.Wait()、
.Result、
.GetAwaiter().GetResult()⚠️ 特别注意：第三方库如果内部用了同步等待（比如某些老版本 RestSharp），和你的
async void一起用，就是定时炸弹 真正难处理的从来不是“怎么写”，而是“怎么让别人不误用”——比如新同事在 ViewModel 里随手写了个
async void LoadData()，还觉得“反正能跑”。这种隐患不会立刻报错，但会在某次发布后某个角落突然崩掉，而且查无痕迹。
