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<t></t>； 若必须兼容旧接口（如某些第三方库强制要求
void返回），可用
async Task实现再包装一层，但不要把
async void当便利 shortcut。
基本上就这些。async void 不是 bug，但它是“特例模式”——用对了省事，用错了埋雷。守住边界，多数时候绕开它，是最稳妥的选择。
