public async void DoSth()
{
    await Task.Run(() => {
        //...DoSth...
    });
}

---

①函数的返回类型前加上： async 

②函数内加上：

 await Task.Run(() => {
        
    });

③在上面{ ... } 内添加要处理的程序代码，

这样运行到 DoSth() 函数就单开一个线程异步执行。 

---

在 C# 中，await Task.Run()加与不加await的主要区别在于代码的执行方式是异步等待还是同步阻塞。以下是详细解释：

1. 加await：异步执行（推荐）

csharp

// 异步执行：主线程不会阻塞，继续执行后续代码
await Task.Run(() => {
    // 耗时操作（如文件读写、计算密集型任务）
});

// 耗时操作完成后才会执行这里的代码
Console.WriteLine("任务完成");

特点：

• 非阻塞：调用线程（如 UI 线程）不会等待Task.Run完成，而是继续执行后续代码。
• 异步等待：await会暂停当前方法的执行，直到任务完成，然后继续执行后续代码。
• 适合场景：需要保持界面响应性的 UI 应用，或需要并行执行多个任务的场景。

2. 不加await：同步执行（慎用）

csharp

// 同步执行：主线程会阻塞，直到任务完成
Task.Run(() => {
    // 耗时操作
}).Wait(); // 或使用 .Result

// 任务完成后才会执行这里的代码
Console.WriteLine("任务完成");

特点：

• 阻塞调用线程：调用线程会被挂起，直到任务完成。
• 等效于同步方法：虽然使用了Task.Run，但实际效果等同于直接调用同步方法。
• 风险：
  • 在 UI 线程中使用会导致界面卡顿。
  • 可能引发死锁（例如在ASP.NET或 WPF 的同步上下文中）。

3. 常见误区：返回Task但不await

csharp

// 错误示例：启动任务但不等待，也不保存引用
Task.Run(() => {
    // 耗时操作
});

// 代码继续执行，但无法知道任务何时完成或是否出错

问题：

• 任务变为 “失控” 状态，无法获取结果或异常。
• 若任务抛出异常，可能导致应用程序崩溃。

总结

场景	加await	不加await（加.Wait()）
执行方式	异步非阻塞	同步阻塞
线程行为	释放调用线程，继续执行后续代码	挂起调用线程，等待任务完成
异常处理	可使用try-catch捕获异常	需在Wait()或Result外围捕获异常
适用场景	UI 响应性、异步编程模型	特殊场景（如测试），但需谨慎使用

最佳实践

1. 优先使用await：保持代码的异步性，避免阻塞。
2. 避免同步阻塞：除非确实需要等待结果（如单元测试），否则不要使用.Wait()或.Result。
3. 处理异常：始终用try-catch包裹await操作，或使用Task.WhenAll并行处理多个任务。

csharp

// 推荐：异步处理多个任务
try {
    await Task.WhenAll(
        Task.Run(() => ProcessData1()),
        Task.Run(() => ProcessData2())
    );
} catch (Exception ex) {
    Console.WriteLine($"任务出错：{ex.Message}");
}

await Task.Run 等同于 同步执行 那为啥还要这么写

你的理解存在一个关键误区：await Task.Run()并不等同于同步执行。实际上，它是将同步代码包装在异步操作中执行，本质是一种异步编程模式。以下是详细解释：

1. await Task.Run()的核心作用：将同步代码转为异步执行

csharp

// 场景：在UI线程中执行耗时计算，使用await Task.Run避免界面卡顿
await Task.Run(() => {
    // 同步的耗时操作（如复杂计算、文件读写）
    return HeavyCalculation();
});

// 代码继续执行，UI不会冻结

关键点：

• Task.Run() 将同步方法（如HeavyCalculation()）放到线程池线程中执行，避免阻塞调用线程（如 UI 线程）。
• await 让当前方法在任务完成前暂停执行，但不阻塞调用线程。UI 线程或其他工作线程可以继续处理其他任务。

2. 为什么不直接使用同步方法？

假设没有Task.Run()，直接调用同步方法：

csharp

// 错误示例：直接调用同步方法会阻塞UI线程
var result = HeavyCalculation(); // UI卡顿，直到计算完成

问题：

• 在 UI 应用（如 WPF、WinForms、ASP.NET）中，同步方法会阻塞主线程，导致界面冻结或请求超时。
• 在服务器应用中，同步方法会占用线程资源，降低系统吞吐量。

3. 为什么不直接使用真正的异步 API？

理想情况下，应优先使用原生异步 API（如File.ReadAllTextAsync()、HttpClient.GetAsync()）：

csharp

// 推荐：使用原生异步API（无需Task.Run）
var content = await File.ReadAllTextAsync("data.txt");

但以下场景仍需要await Task.Run()：

1. 调用 legacy 同步代码：当你必须调用没有异步版本的方法（如第三方库的同步 API）。
2. 执行 CPU 密集型任务：如复杂计算，原生异步 API 无法解决，必须用Task.Run()将其放到线程池。
3. 混合异步 / 同步代码：在异步方法中穿插执行同步操作，但不想阻塞当前流程。

4. 总结：await Task.Run()的适用场景

场景	示例代码
避免 UI 卡顿（执行同步代码）	await Task.Run(() => ComputeIntensive());
并行执行多个同步任务	await Task.WhenAll(Task.Run(() => Task1()), Task.Run(() => Task2()));
在异步方法中执行同步 IO	await Task.Run(() => File.WriteAllText("data.txt", content));

5. 常见误区澄清

误区 1：await Task.Run()会阻塞线程

错误：await不会阻塞线程，它只是暂停当前方法的执行，允许调用线程继续处理其他工作。

误区 2：await Task.Run()性能差

不完全正确：对于 IO 密集型操作，使用Task.Run()确实不如原生异步 API 高效（因为涉及线程上下文切换）。但对于 CPU 密集型任务，这是合理选择。

误区 3：应避免使用Task.Run()

错误：在需要将同步代码转为异步执行的场景下（如 UI 响应性、服务器吞吐量），Task.Run()是必要的工具。

最佳实践

1. 优先使用原生异步 API：如果有异步版本的方法，直接使用它。
2. 使用Task.Run()处理同步代码：当无法避免调用同步方法时，用Task.Run()将其包装为异步操作。
3. 避免过度使用Task.Run()：不要将所有同步代码都转为异步，仅在必要时使用（如 UI 线程、高并发场景）。

csharp

// 正确示例：根据场景选择合适的方法
public async Task ProcessDataAsync() {
    // 1. 使用原生异步API
    var data = await DownloadDataAsync();
    
    // 2. 使用Task.Run处理CPU密集型计算
    var result = await Task.Run(() => Compute(data));
    
    // 3. 使用原生异步API保存结果
    await SaveResultAsync(result);
}

总结

await Task.Run()的存在价值在于将同步代码无痛集成到异步编程模型中，让你在不重写现有代码的前提下获得异步编程的优势（如 UI 响应性、资源利用率）。它是一种实用的 “胶水代码”，而非性能优化工具。