将普通void事件处理器改为Task类型并await的方案是否合规？

三种写法的优劣分析 #

第一种写法（async Lambda包装返回Task的方法）：完全不推荐

这个写法有个致命问题：你+=和-=的匿名lambda是两个完全独立的委托实例，根本无法成功取消订阅，会导致事件绑定的对象无法被GC回收，出现内存泄漏。
另外你写的返回Task的lambda赋值给PropertyChangedEventHandler这类返回void的事件委托时，编译器会自动把它转成async void方法，你返回的Task根本没有上层调用者接收，和直接写async void没有本质区别，还多了退订失败的隐患。

第二种写法（void方法内弃元异步方法）：仅适合完全无风险的轻量场景

用_ = SomeService.ExecuteAsync(...)本质是「发后不管」，如果ExecuteAsync执行过程中抛出未处理异常，会变成未观察到的Task异常：在.NET Framework中会直接导致进程崩溃，.NET Core+版本虽然默认不会终止进程，但也会触发全局UnobservedTaskException事件，属于潜在风险。
另外你也无法追踪这个异步操作的生命周期，如果绑定事件的对象已经销毁，后台异步操作还在运行的话，很容易触发访问已释放资源的异常。

第三种写法（async void事件处理器）：事件场景下的官方推荐用法

平时不推荐用async void的核心原因是异常无法被常规的try catch捕获、也无法追踪异步执行状态，但事件处理器是官方唯一明确允许使用async void的场景。
使用这个写法需要注意几个点：

• 方法内部必须用try catch包裹所有逻辑，不要让任何异常流出方法，否则异常会直接抛到当前同步上下文，大概率会导致进程崩溃
• 你给出的示例代码里await = SomeService.ExecuteAsync(...)是笔误，正确写法要去掉等于号：await SomeService.ExecuteAsync(...)
• 如果业务允许，建议配合CancellationToken，在对象销毁/页面卸载时取消还在运行的异步操作，避免不必要的报错

最终建议 #

优先选择第三种写法，做好异常处理即可；如果你的异步操作逻辑非常简单、确认不会抛出异常、也不需要关心执行结果，也可以选第二种写法；第一种写法绝对不要用。

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