async void 方法抛出未捕获异常会直接终结进程，因其不返回 Task，无法被 try-catch 捕获或 await 等待；唯一合法场景是事件处理函数，其余均应使用 async Task。
async void 方法一旦抛出未捕获异常，会直接终结进程，没有补救余地。
为什么 async void 无法被 try-catch 捕获
当你写 async void DoWork()，编译器生成的状态机不会绑定到任何 Task 对象上。这意味着：调用方既不能 await 它，也无法通过 Task.Exception 或 await 的隐式异常传播机制拿到异常。
常见错误现象：
- WinForms/WPF 中事件处理器写成
async void Button_Click，点击后崩溃，控制台甚至没输出堆栈 - 单元测试里调用
async void方法，断言永远不执行，测试“静默通过” - 日志里看不到异常，但程序突然退出（尤其在 .NET Framework 下）
根本原因：这类方法的异常会被抛到 SynchronizationContext 或线程池的默认异常处理器，最终触发 AppDomain.UnhandledException 或 TaskScheduler.UnobservedTaskException —— 这些都不是常规 try-catch 能拦住的。
哪些地方允许且必须用 async void
唯一被语言和框架明确支持的 async void 场景，是 **事件处理函数**。
例如：
button.Click += async (s, e) => {
await LoadDataAsync();
UpdateUi();
};
这是因为事件委托签名固定为 void EventHandler(object, EventArgs)，你无法改成 Task。但注意：仅限于这种“顶层入口”，不要在它内部再调用另一个 async void。
其他看似合理的场景其实都该避免：
- 不要在
Main方法中写async void Main（.NET Core 2.1+ 支持async Task Main） - 不要为测试或工具方法图省事写
async void，哪怕它“看起来只跑一次” - 不要把
async void当作“不需要等待”的快捷写法——那是对异步模型的误解
async Task 和 async void 在异常传播上的实际差异
写一个对比示例最直观：
// ❌ 危险：异常无法被捕获
async void BadMethod() => throw new InvalidOperationException("boom");
try
{
BadMethod(); // 立即返回，不等执行完
}
catch (Exception) // 这个 catch 永远进不去
{
Console.WriteLine("never hit");
}
// ✅ 安全：异常可被 await 捕获
async Task GoodMethod() => throw new InvalidOperationException("boom");
try
{
await GoodMethod(); // 真正挂起，异常在此处重抛
}
catch (InvalidOperationException ex) // 这里能拿到 ex
{
Console.WriteLine(ex.Message); // 输出 boom
}
关键区别在于：async Task 返回的是一个可观测的 Task 实例，它的生命周期、完成状态、异常都由运行时统一管理；async void 是“发射即忘”，失控风险极高。
ValueTask 能替代 async void 吗
不能。虽然 ValueTask 是轻量级结构体类型，用于避免小任务的堆分配，但它仍是一个可等待对象，必须配合 await 使用。它解决的是性能问题，不是异常可见性问题。
如果你看到有人用 async ValueTask 替代 async void，那说明他混淆了两个维度：
-
voidvsTask/ValueTask：决定是否可观察、可等待、可异常传播 -
TaskvsValueTask：决定内存分配开销，仅影响高频小任务
真正要替换 async void，只能选 async Task（或 async ValueTask，前提是调用方能 await 它）。
最容易被忽略的一点是：即使你确保 async void 内部绝不会抛异常，它依然不可观测——你无法知道它何时结束，无法做超时控制，无法参与 Task.WhenAll 编排。这些限制比异常更隐蔽，也更常在后期维护中暴露出来。
