Stephen Cleary 是 C# 异步编程领域公认的实战派专家，他不是只讲理论的学者，而是长期在真实项目中踩坑、填坑、提炼模式的工程师。他的核心建议不是“怎么写 async”，而是“怎么不写错 async”——尤其在跨线程上下文、测试、UI 集成和库设计等容易静默崩溃的场景。
避免 async void
，除非你真在写事件处理程序
这是 Cleary 反复强调的“第一戒律”。
async void方法无法被
await，异常会直接抛到
SynchronizationContext（比如 UI 线程），导致应用崩溃且难以捕获；它也不支持超时、取消或组合（如
Task.WhenAll）。 ✅ 正确：事件处理器（如
button_Click）可
async void，因为事件签名强制返回
void❌ 错误：把业务逻辑方法写成
async void DoWork()—— 改为
async Task DoWorkAsync()⚠️ 注意：
Console.Main在 .NET 6+ 允许
async Task Main()，但旧版或类库中仍需避免
void
用 ConfigureAwait(false)
除非你明确需要上下文
默认情况下，
await会尝试“回到原上下文”（如 UI 线程或 ASP.NET 请求上下文）。这在库代码中是危险的：它可能引发死锁（尤其调用
.Result或
.Wait()时），也拖慢性能。 ✅ 库/工具方法中：所有
await后加
.ConfigureAwait(false)，例如
await stream.ReadAsync(buffer).ConfigureAwait(false)❌ UI 层或 ASP.NET Controller 中盲目加：可能破坏数据绑定或
HttpContext访问 ? 小技巧：用 Roslyn 分析器（如
ConfigureAwaitChecker）自动检测遗漏点
测试异步方法时，别用 .Result
或 .Wait()
Cleary 明确指出：“单元测试里出现
.Result，基本等于埋雷”。它会阻塞当前线程，在 xUnit/NUnit 的同步测试上下文中极易触发死锁（尤其涉及
SynchronizationContext时）。 ✅ 正确：测试方法本身标记为
async Task，并
await被测方法 ❌ 错误：
[Fact]
public void TestGetData() {
var result = GetDataAsync().Result; // ⚠️ 死锁高发区
Assert.Equal("OK", result);
}
? 补充：xUnit 支持 async Task测试方法；NUnit 需 ≥ 3.0 并启用
AsyncTest特性
别让 CPU 密集型操作假装“异步”
异步 ≠ 并行。Cleary 强调：
await Task.Run(() => ComputeHeavy())不是真正的异步 I/O，只是把同步工作扔进线程池——它解决的是 UI 响应问题，但会增加调度开销，且不能缩放。 ✅ I/O 绑定操作（HTTP、DB、文件）：用原生异步 API（
HttpClient.GetAsync、
FileStream.ReadAsync） ✅ CPU 绑定操作：用
Parallel.ForEach或
PLINQ，或明确用
Task.Run并注明“此为线程池卸载，非异步” ❌ 混淆：
async Task<int> CalculateAsync() { await Task.Run(() => ExpensiveMath()); }</int> —— 方法名带 Async却无真正异步语义，误导调用方
真正难的从来不是“怎么让代码跑起来”，而是“怎么让它在并发、中断、失败、升级后依然可靠”。Cleary 的建议之所以被广泛采纳，是因为他始终站在调用链下游、测试覆盖率、部署稳定性这些真实战场说话——比如一个
ConfigureAwait(false)的缺失，可能在压测时才暴露为 5% 的随机超时，而没人能复现。
