ASP.NET Core ChangeToken.OnChange无异步重载时的安全写法

现有写法的风险 #

• 写法1：async () => await debouncer.Debounce(OnReloaded) 属于标准async void模式，lambda会被编译器编译为异步void方法，内部抛出的未捕获异常会直接触发进程级崩溃，这也是代码分析器报警的核心原因
• 写法2：() => debouncer.Debounce(OnConfigReloaded).ConfigureAwait(false) 属于隐式发后不理（fire-and-forget），方法返回的Task对象被直接丢弃，内部未捕获异常会触发TaskScheduler.UnobservedTaskException事件，虽然.NET Core 2.0及以上版本默认不会因这类异常终止进程，但依然属于未定义行为，存在不可控隐患
• 两种写法都未对异步逻辑的异常做兜底处理，都不满足生产环境的安全编码要求

官方异步重载上线前的最优实现 #

核心原则：禁止给传入OnChange的Action lambda添加async修饰符，避免生成async void状态机；所有异步逻辑单独抽离，在内部完成全链路异常捕获，杜绝异常逃逸。
参考实现代码：

// 注册变更Token监听
ChangeToken.OnChange(
    () => GetReloadToken(),
    () =>
    {
        // 丢弃返回值是安全的，因为内部已经做了完整异常兜底
        _ = SafeReloadAsync();
    }
);

/// <summary>
/// 带异常兜底的配置重载逻辑
/// </summary>
async Task SafeReloadAsync()
{
    try
    {
        await debouncer.Debounce(OnReloaded);
        // 可根据业务需要选择是否添加ConfigureAwait(false)
    }
    catch (Exception ex)
    {
        // 此处必须处理所有异常：记录错误日志、执行降级逻辑均可，绝对不能让异常抛出方法外
        LogReloadError(ex, "配置重载过程发生异常");
    }
}

该实现的优势 #

• 完全规避async void的进程崩溃风险：传入OnChange的是纯同步Action，不会生成异步void状态机
• 所有异步执行路径的异常都被try/catch完整捕获，既不会触发进程崩溃，也不会产生未观察Task异常
• 逻辑解耦清晰，防抖、业务重载、异常处理逻辑拆分独立，后续维护成本低
• 等.NET官方推出ChangeToken.OnChange的Func<Task>异步重载后，仅需把传入的回调替换为SafeReloadAsync即可，无需改动业务逻辑

注意事项 #

不要使用.GetAwaiter().GetResult()、.Wait()等方式在Action回调中同步阻塞等待异步任务，这类写法在带同步上下文的环境（WPF、WinForm、legacy ASP.NET）下存在极高的死锁风险。
异步方法内部的异常捕获必须覆盖所有可能的异常路径，不要只捕获特定类型的异常，避免遗漏导致异常逃逸。

内容的提问来源于stack exchange，提问作者lonix