async void仅用于UI事件处理器，业务逻辑必须用async Task；ConfigureAwait(false)在无同步上下文场景必加；勿用Task.Run包装I/O异步方法；禁用.Result/.Wait()阻塞调用。

别在 async void 里写业务逻辑

这是最常踩的坑：只要不是事件处理函数（比如按钮点击），就绝不要用 async void。它无法被 await，异常会直接炸到同步上下文，导致应用崩溃且难以捕获。

• async void 方法一旦抛出未处理异常，会触发 AppDomain.UnhandledException 或 TaskScheduler.UnobservedTaskException，调试时根本看不到堆栈归属
• 正确做法是统一返回 Task 或 Task<T>，哪怕不 await 也得用 async Task
• 唯一合理使用 async void 的场景：WPF/WinForms/UWP 的事件处理器，例如 private async void Button_Click(...)

ConfigureAwait(false) 不是可有可无的配置项

在类库、底层工具方法、ASP.NET Core 中间件等**不依赖同步上下文**的场景下，漏掉 ConfigureAwait(false) 可能引发死锁或性能下降——尤其在 UI 线程或旧版 ASP.NET（非 Core）中。

Json Schema Toolkit

使用 JSON Schema 验证 JSON 数据，从示例 JSON 生成 schema，并将其转换为 TypeScript 接口、Python 数据类或 Markdown 文档。

下载

• 默认 await 会尝试捕获当前 SynchronizationContext 并回调回去；服务端代码不需要这个行为，反而造成线程争抢
• ASP.NET Core 已移除默认 SynchronizationContext，但为兼容性与明确意图，仍建议显式写 .ConfigureAwait(false)
• 例外：WPF/WinForms 中更新 UI 控件必须回到主线程，此时不能加 ConfigureAwait(false)，否则 Dispatcher.Invoke 类操作会失败

别用 Task.Run 包裹已异步的 I/O 操作

把 HttpClient.GetStringAsync() 或 FileStream.ReadAsync() 再套一层 Task.Run(() => ...)，等于用线程池线程去等 I/O 完成，纯属浪费资源。

• I/O 异步本质是基于完成端口（IOCP）或 epoll/kqueue，不占线程；Task.Run 却强行调度到线程池，增加调度开销和上下文切换
• 只有 CPU 密集型工作（如 JSON 解析、图像处理）才适合用 Task.Run 脱离当前上下文
• 错误示例：

  await Task.Run(() => httpClient.GetStringAsync(url)); // ❌

  正确写法：

  await httpClient.GetStringAsync(url); // ✅

警惕 async 方法里的同步阻塞调用

在 async 方法中调用 .Result、.Wait() 或 GetAwaiter().GetResult()，极易引发死锁，尤其在有同步上下文的环境（如 WinForms 主线程、旧版 ASP.NET）。

• 这些调用会阻塞当前线程，而 await 后续回调又需要该线程空闲来执行，形成循环等待
• 即使没死锁，也会降低吞吐量——线程被卡住就不能干别的事
• 如果必须同步获取结果（极少见），优先考虑重构为真正异步链路；实在不行，用 await task.ConfigureAwait(false) + GetAwaiter().GetResult()（仅限无上下文环境）

实际项目中最难排查的，往往是跨层调用时某处悄悄用了 .Result，或者类库作者忘了加 ConfigureAwait(false)。异步不是加几个关键字就完事，关键在整条调用链是否真正“放手”。