Task.Run仅适用于CPU密集型操作，不可用于包装async方法；async/await本质是协作式异步，不创建线程；类库中应普遍使用ConfigureAwait(false)；优先用Task.Run替代Thread.Start和Task.Factory.StartNew。
Task.Run 适合 CPU 密集型，别用它包 async 方法
很多人一写多线程就下意识 Task.Run(async () => await SomeAsyncMethod())，这其实埋了坑：它把 async 方法“伪装”成同步任务扔进线程池，但 async 方法内部的 await 会释放线程，导致线程池线程被无谓占用又提前交还，既没提升并发，还增加调度开销。
真正该做的是——直接调用 async 方法，让它们自然流转；只有当你确实要跑 CPU 绑定代码（比如图像处理、加密计算）时，才用 Task.Run。
- ✅ 正确：直接
await GetDataAsync()或并行启动多个 async 方法：await Task.WhenAll(api1, api2) - ❌ 错误：用
Task.Run(() => GetDataAsync())，返回的是Task<task></task>，容易漏await内层 task - ⚠️ 注意：
Task.Run启动的委托不能是async void，否则异常会直接崩掉进程
async/await 不等于多线程，它只是协作式异步
这是最常被误解的一点。C# 的 async/await 本身不创建新线程，它靠的是底层 I/O 完成端口（Windows）或 epoll/kqueue（Linux/macOS）实现“等的时候不占线程”。所以你在 UI 线程里 await HttpClient.GetAsync()，不会卡界面，但也不会多出一个 CPU 核心在干活。
如果你需要同时跑 3 个 HTTP 请求，应该用 Task.WhenAll 并发发起，而不是串行 await —— 前者是真正并发，后者是排队等。
- ✅ 并发请求：
var tasks = new[] { client.GetAsync("a"), client.GetAsync("b"), client.GetAsync("c") }; await Task.WhenAll(tasks); - ❌ 伪并发：
await client.GetAsync("a"); await client.GetAsync("b"); await client.GetAsync("c"); - ? 提示：
Task.WhenAll返回的是Task<t></t>，不是Task<task></task>，别多套一层await
ConfigureAwait(false) 在类库中几乎必须加
如果你写的是 NuGet 包、基础工具类或后台服务逻辑，不加 ConfigureAwait(false)，一旦被 UI 或 ASP.NET 同步上下文环境调用，就可能死锁或性能骤降。它的作用是告诉编译器：“这个 await 之后的代码，不需要回到原来的上下文线程执行。”
而 UI 应用（WPF/WinForms）或旧版 ASP.NET（非 Core）才有同步上下文；ASP.NET Core 和控制台程序默认没有，所以影响小些，但类库无法预知调用方。
- ✅ 推荐写法：
await stream.ReadAsync(buffer, 0, size).ConfigureAwait(false) - ❌ 遗漏后果：在 WinForms 中调用一个没配
ConfigureAwait(false)的类库方法，可能卡住整个消息循环 - ⚠️ 注意：UI 更新操作（比如设置
label.Text）必须在 UI 线程做，这时候反而要保留上下文，即不加ConfigureAwait(false)—— 但这类代码不该出现在通用类库里
Thread.Start 和 Task.Factory.StartNew 已过时，优先用 Task.Run
Thread 类手动管理线程成本高、易出错；Task.Factory.StartNew 参数多、重载混乱，且默认行为容易和 Task.Run 混淆（比如它默认不捕获同步上下文，而 Task.Run 会）。.NET 4.5 之后，Task.Run 就是为“快速扔一个工作到线程池”设计的唯一推荐入口。
- ✅ 替代
new Thread(() => DoWork()).Start()→Task.Run(() => DoWork()) - ✅ 替代
Task.Factory.StartNew(() => DoWork())→ 同样用Task.Run(() => DoWork()) - ⚠️ 注意：
Task.Run总是调度到线程池，不支持前台线程、自定义栈大小、线程名称等老特性——需要这些？说明你真该重新评估是否必须用原始线程
事情说清了就结束。真正的难点从来不在语法，而在分清“我到底要等资源”，还是“我真要榨干 CPU”。
