async void 最大问题是无法被等待、异常无法捕获、破坏异步可控性，仅应限于UI事件处理器等顶层入口；应优先使用 async Task 以支持 await、异常传播、取消和调试。
async void 在 C# 中最大的问题是：它无法被等待、无法捕获异常、破坏了异步编程的可控性，只应出现在事件处理程序等极少数场景中。
async void 无法被等待，导致调用方失去控制
与 async Task 不同，async void 方法没有返回值，调用后立即“消失”，调用方无法 await 它，也无法知道它何时完成。这会让依赖其执行结果的逻辑出错或提前执行。
- 比如在按钮点击中写
async void Button_Click(...)，UI 可能以为操作已结束，但后台还在跑； - 若在单元测试里调用
async void，测试框架根本等不到它结束，直接通过或超时失败。
未处理的异常会直接崩溃应用
async void 中抛出的异常不会进入 Task 的异常容器，也不会被 await 捕获，而是直接抛到同步上下文（如 UI 线程）上，变成未处理异常——在 WinForms/WPF 中可能直接弹框崩溃，在 ASP.NET 中可能终止请求甚至影响整个 AppDomain。
-
try/catch写在async void方法内部可以捕获，但一旦漏写，风险极高； - 全局异常处理器（如
AppDomain.UnhandledException）虽能兜底，但属于事后补救，不该作为常规手段。
仅限 UI 事件处理器等特定场景使用
.NET 设计者明确将 async void 保留给“真正不需要返回、也不需要被协调”的顶层入口点，典型就是 WPF/WinForms/UWP 的事件处理方法：
- ✅ 允许：
private async void Button_Click(object s, RoutedEventArgs e)； - ❌ 禁止：
public async void SaveData()、private async void HelperMethod()、任何被其他代码调用的非事件方法。
替代方案始终优先选 async Task：它可 await、可组合、异常可传播、支持取消和超时——这才是现代异步编程的正确基元。
调试和日志更难追踪
因为没有 Task 对象，你无法检查其状态（IsCompleted、IsFaulted）、无法附加延续（.ContinueWith）、无法统一监控生命周期。日志打点也容易遗漏“开始”和“结束”的对应关系，尤其在嵌套调用或错误路径下。
- 建议所有业务逻辑层、服务层、工具方法，一律用
async Task或async Task； - 若必须兼容旧接口（如某些第三方库强制要求
void返回），可用async Task实现再包装一层，但不要把async void当便利 shortcut。
基本上就这些。async void 不是 bug，但它是“特例模式”——用对了省事，用错了埋雷。守住边界，多数时候绕开它，是最稳妥的选择。
