C# 的 async/await 模型在编译后依赖一种叫异步状态机的结构来保存方法执行位置和异常信息。返回 Task 或 Task<T> 的异步方法可以把异常装进返回的 Task 对象中，由调用方通过 await 或 Wait 来观察。而 async void 方法没有这个返回载体，它的状态机使用 AsyncVoidMethodBuilder，一旦方法内部发生未处理异常，异常会被直接抛到当前同步上下文，很可能变成未处理异常并终止进程。这个差异导致 async void 的异常传播行为与普通 Task 异步方法完全不同，也是它最大危害的来源。

一、async void 与 async Task 的状态机差异

理解 async void 的问题，首先要看 C# 编译器如何处理异步方法。一个标记为 async 的方法并不会原样执行，而是会被改写成一个实现了 IAsyncStateMachine 的状态机。返回 Task 的异步方法使用 AsyncTaskMethodBuilder 来构建状态机，这个 Builder 负责在方法完成、失败或取消时设置 Task 的状态。而 async void 方法使用 AsyncVoidMethodBuilder，它没有可以对外暴露的 Task 对象。换句话说，async void 的方法一旦启动，调用方没有句柄可以检查它是否完成，也没有句柄可以订阅它的异常。

这种设计并非编译器疏忽，而是为了兼容事件处理器。C# 语言规范中事件处理器的签名通常是 void 返回类型，例如 WPF 的 RoutedEventHandler 和 WinForms 的 EventHandler 都要求 void。为了在这些场景中使用 await，语言团队允许 async void 存在。但问题在于，很多开发者把这个特例扩展到了普通业务方法、命令回调和辅助方法中，结果就是异常无法被正常捕获，程序状态难以追踪。下面先看一个典型的事件处理器代码。

private async void OnSaveButtonClick(object sender, EventArgs e)
{
    await SaveDataAsync();
    throw new InvalidOperationException("保存后的后置处理失败");
}

如果 SaveDataAsync 正常完成，异常在 await 之后抛出。调用这个事件处理器的 UI 框架代码根本不知道内部发生了异常，因为它只能调用一个返回 void 的方法。即使你在按钮点击的外层包裹 try catch，也捕获不到异步 void 内部抛出的异常。这个异常会被送到 WinForms 或 WPF 的同步上下文，如果没有全局处理器或 try catch，程序会直接崩溃。

相比之下，如果把同样的逻辑封装为返回 Task 的方法，行为立刻变得可控。代码如下：

private async Task SaveWithPostProcessAsync()
{
    await SaveDataAsync();
    throw new InvalidOperationException("保存后的后置处理失败");
}
private async void OnSaveButtonClick(object sender, EventArgs e)
{
    try
    {
        await SaveWithPostProcessAsync();
    }
    catch (Exception ex)
    {
        MessageBox.Show(ex.Message);
    }
}

这个版本中，异常被保存在 Task 中，事件处理器使用 await 观察并捕获它。即使没有 catch，异常也会通过 await 传递到调用线程，而不是直接散落到同步上下文。这正是 async Task 与 async void 最本质的区别：前者提供异常容器，后者没有。

二、异常无法捕获是 async void 最大的危害

异步方法中的未处理异常会传播到返回的 Task。对于 async Task，如果调用方没有等待该 Task，异常也不会立即抛出，而是留在 Task 中，直到被等待或观察到。对于 async void，没有 Task，编译器只能把异常直接抛给同步上下文。在 WPF、WinForms 等带同步上下文的 UI 应用中，异常会被封送到 UI 线程并抛出；在 ASP.NET Core 或控制台应用中，如果没有捕获，会导致请求失败或进程退出。

来看一段控制台程序的示例：

static async Task Main(string[] args)
{
    try
    {
        RunFireAndForget();
        await Task.Delay(500);
        Console.WriteLine("主流程完成");
    }
    catch (Exception ex)
    {
        Console.WriteLine($"捕获到异常：{ex.Message}");
    }
}
static async void RunFireAndForget()
{
    await Task.Delay(100);
    throw new InvalidOperationException("后台任务失败");
}

运行这段代码时，try 块内的 catch 并不能捕获 RunFireAndForget 中抛出的异常。原因是 async void 方法在 await Task.Delay(100) 之后恢复时，异常会直接被抛出到线程池线程，大多数情况下会导致进程崩溃。你看到的可能不是“捕获到异常”，而是控制台输出未处理异常信息并退出。即使把 try 加在调用 RunFireAndForget 的位置，也无法拦截它内部的异步异常。这个实验可以很直观地说明 async void 的传播路径有多难控制。

在 UI 应用中，危害同样严重。WPF 的 DispatcherUnhandledException 和 WinForms 的 ThreadException 事件可以用来做全局兜底，但它们对 async void 的捕获时机并不可靠。有些异常可能在后台线程 Continuation 中抛出，根本不经过 UI 调度器。最稳妥的做法仍然是避免让异常从 async void 逸出。这也是为什么很多团队会约定：async void 只允许出现在事件处理器中，并且第一行和最后一行之间必须全部被 try catch 包裹。

三、事件处理器中的 async void 例外与正确用法

既然 async void 是为事件处理器设计的，那么在真实项目中就很难完全杜绝它。事件签名已经固定为 void，改成返回 Task 的委托类型在 UI 框架中一般不会被识别。例如 WinForms 的 Button.Click 事件期望的是 EventHandler，其签名为 void(object sender, EventArgs e)，你无法把它改成 Func<object, EventArgs, Task>。因此事件处理器内部的 async void 是可以接受的，前提是内部不能放过任何异常。

一个推荐的事件处理器模式是：处理器本身只负责调用返回 Task 的普通异步方法，并统一捕获异常，把结果呈现给用户或记录日志。这样做可以把核心业务逻辑与 UI 事件绑定解耦，也便于单元测试。示例：

private async void OnLoadDataButtonClick(object sender, EventArgs e)
{
    try
    {
        DisableButton();
        var data = await LoadDataAsync();
        RenderData(data);
    }
    catch (Exception ex)
    {
        LogError(ex);
        ShowErrorDialog("加载失败，请稍后重试");
    }
    finally
    {
        EnableButton();
    }
}
private async Task<List<DataItem>> LoadDataAsync()
{
    await Task.Delay(200);
    // 模拟加载数据
    return new List<DataItem>();
}

上面的代码中，事件处理器内部仍然使用了 async void，但所有可能抛出异常的 await 都被 try catch 挡住。不论 LoadDataAsync 是同步异常还是异步异常，都会进入 catch 分支，而不会散落到 UI 同步上下文。这样 async void 的破坏性就被限制在了最小范围。注意这里 RenderData 和 ShowErrorDialog 如果修改 UI 元素，应当保证在 UI 线程执行。由于事件处理器默认捕获当前同步上下文，await 之后会回到 UI 线程，因此这个结构基本是安全的。

另一个常见问题是，事件处理器内部如果有多个连续的 await，而它们之间没有 try catch，仍然可能漏出异常。因此对事件处理器应保持简洁，不要写长链式业务逻辑。可以把多步操作封装成一个返回 Task 的方法，在事件处理器中只做一次 await 和异常处理。这样做既符合关注点分离，也更容易排查问题。

四、其他常见误用场景与安全的即发即弃模式

构造函数不能标记为 async，于是有人会在构造函数里调用一个 async void 方法来做初始化。这种做法非常危险，因为构造函数执行时对象尚未完全创建，如果异步初始化抛异常，调用方可能只拿到一个半初始化对象，甚至程序直接崩溃。替代方案是使用工厂方法或显式的初始化 Task。例如：

public class DataService
{
    private DataService() { }
    public static async Task<DataService> CreateAsync()
    {
        var service = new DataService();
        await service.InitializeAsync();
        return service;
    }
    private async Task InitializeAsync()
    {
        await Task.Delay(100);
        // 初始化逻辑
    }
}

这样调用方通过 await DataService.CreateAsync() 获取实例，任何初始化异常都会被正常捕获。构造函数保持简单，不涉及异步工作。类似地，接口实现中如果接口方法返回 void，也不要为了内部使用 await 而把实现改成 async void。最好重新审视接口设计，将返回类型改为 Task 或 Task<T>。如果是第三方接口无法修改，就在实现内部使用同步等待或安全的异步桥接，但不要用 async void 逃避设计问题。

即发即弃操作也是 async void 被滥用的高发区。例如日志写入、通知发送、缓存刷新等不需要等待结果的场景，开发者可能图方便写一个 async void 方法直接调用。正确的做法是返回 Task，并在调用处确保异常被观察。如果确定不等待，可以使用一个安全包装方法来记录失败：

public static void FireAndForget(Func<Task> action)
{
    _ = Task.Run(async () =>
    {
        try
        {
            await action();
        }
        catch (Exception ex)
        {
            // 记录异常，避免进程崩溃
            Console.WriteLine(ex.Message);
        }
    });
}

调用时传入一个返回 Task 的异步 Lambda，例如 FireAndForget(() => SendNotificationAsync())，这样即使通知发送失败，异常也会被记录而不会直接终止进程。注意 Task.Run 本身返回一个 Task，用下划线显式丢弃可以避免编译器警告，同时异常已经在内部处理。这种模式比直接调用 async void 安全得多。

单元测试中同样应当避免 async void。虽然测试框架对异步测试的支持通常基于返回 Task 的方法，但如果你写了一个 async void 测试方法，测试运行器无法等待它完成，断言可能在异步操作结束前就执行了，导致测试结果不可靠，甚至测试结束后后台任务还在运行。更严重的是，async void 测试抛出的异常可能不会标记测试失败，而是直接让测试进程崩溃。因此测试方法应始终返回 Task 或 Task<T>。如果测试框架要求 void，请检查是否有相应的异步支持版本。

总结一下，async void 并非绝对禁止，但它的适用范围非常窄：仅用于 UI 事件处理器或与 void 委托签名绑定的回调。其他场景中，返回 Task 或 Task<T> 是更安全的选择。所有 async void 方法内部都应该有完整的异常处理，不能有任何异常逃逸路径。即发即弃操作要显式设计异常观察机制。理解了这些边界，就能在享受 async/await 便利的同时，避免异步编程中最常见的程序崩溃隐患。