17370845950

async/await 会导致 Exception.StackTrace 丢失原始抛出位置，因异步状态机在 await 恢复时新建调用帧；可用 ExceptionDispatchInfo.Capture(e).Throw() 显式保留堆栈，但仅适用于手动捕获重抛场景。

async/await 会让 Exception.StackTrace 丢失原始抛出位置

这是最常被忽略的副作用：当异常在 async 方法中抛出，且未在该方法内被捕获，它最终会包装成 AggregateException（仅限 Task.Wait() 或 Task.Result）或直接作为 Task.Exception 的内层异常；但更常见的是——在 await 链中，原始堆栈帧会被截断，StackTrace 显示的是 await 恢复点，而非 throw 那一行。

• 根本原因：.NET 的异步状态机在 await 后恢复执行时，会新建一个同步上下文帧，原始调用栈已在 await 时“保存并丢弃”
• 影响范围：所有 .NET 版本（包括 .NET 6+），只要异常跨 await 边界传播，就无法从 StackTrace 直接看到 throw 行号
• 典型现象：

  at MyApp.Service.DoWork() in C:\src\Service.cs:line 42
  at MyApp.Service.GetDataAsync() in C:\src\Service.cs:line 28
  at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)

  ——但实际 throw 发生在 DoWork() 内部某处第 15 行，而该行不会出现在堆栈里

如何保留完整原始堆栈（.NET 4.5+ 可用）

.NET 4.5 引入了 ExceptionDispatchInfo，它能捕获并重抛异常，同时保留原始堆栈。适用于你必须在 await 后手动处理异常、又不想丢失诊断信息的场景。

• 不能用于自动传播的 await 异常（即未显式 catch 的情况）
• 只对显式捕获再重抛有效：先 catch，再用 ExceptionDispatchInfo.Capture(e).Throw()
• 注意：重抛后仍会触发 await 状态机，所以要在“非 await 上下文”中调用（如同步方法、Task.Run 内部等）

public async Task ProcessAsync()
{
    try
    {
        await DoSomethingAsync();
    }
    catch (Exception ex)
    {
        // 保留原始堆栈信息
        ExceptionDispatchInfo.Capture(ex).Throw();
        // 不会执行到这里
    }
}

调试时怎么看真实抛出点

靠 StackTrace 文本已经不可靠，得换策略：

• 在 Visual Studio 中启用“异常设置”→勾选 Common Language Runtime Exceptions →“当异常被抛出时中断”，IDE 会在 throw 那一刻停住，此时调用栈是真实的
• 使用 ex.ToString() 而非只看 ex.StackTrace：它会包含 InnerExceptions 和可能的 RemoteStackTraceString（如果异常跨线程/上下文）
• 对关键路径添加结构化日志，例如用 ILogger.LogError(ex, "Failed in {Method}", nameof(DoWork))，确保异常对象传入，Serilog/NLog 会尝试提取原始上下文

为什么 async void 更危险

async void 方法中的异常无法被调用方 await，会直接抛到 SynchronizationContext（如 UI 线程）或终结器线程，导致进程崩溃。此时不仅堆栈丢失，连捕获机会都没有。

• 永远不要写 async void，除非是事件处理器（如 Button_Click）且你明确知道后果
• 事件处理器中若需异常安全，应包裹 try/catch 并记录日志，避免让异常逃逸
• 测试时容易漏掉：单元测试框架通常不支持 async void，导致异常静默失败

异常堆栈被截断不是 bug，是异步状态机的设计取舍。真要定位问题，别只盯着 StackTrace 字符串——调试器中断点、日志上下文、以及 ExceptionDispatchInfo 这种显式控制手段，才是实际有效的路径。