应优先使用Action，仅在需卸载CPU密集型同步计算时用Task.Run；传Func极易导致悬空任务、未观察异常或意外同步执行，正确做法是直接await原async方法。
Task.Run 里传 Action 和 Func<task></task> 的行为完全不同
传 Action 是让线程池执行一个「不返回任务的普通方法」，而传 Func<task></task> 是让线程池执行一个「返回未启动任务的工厂函数」——但这个返回的 Task 本身不会被自动 await 或启动，容易造成悬空任务或意外同步执行。
为什么 Func<task></task> 容易出问题
常见错误是误以为 Task.Run(() => SomeAsyncMethod()) 会正确调度异步操作。实际上：
-
SomeAsyncMethod()在线程池线程上被**立即调用**，返回一个Task -
Task.Run只负责运行这个委托，**不关心它返回什么**，也不 await 它 - 如果
SomeAsyncMethod()内部很快完成（比如直接 return Task.CompletedTask），那整个调用看起来“同步结束”，但真正耗时的 await 部分仍在线程池线程上发生，可能阻塞该线程 - 更危险的是：若
SomeAsyncMethod()抛异常，异常会包装进返回的Task，但这个Task没被 await，就变成未观察的异常，.NET 6+ 默认会终止进程
正确写法：用 Func<task></task> 前必须 await 返回值
如果真要传 Func<task></task>，必须确保外层代码会 await 它的结果，否则不如不用 Task.Run。典型安全用法只有两种：
- 想把「已存在的、未 await 的
Task」丢到线程池等它——但极少需要，因为Task本身已可 await - 配合
Unwrap()处理嵌套任务：var outer = Task.Run(() => DoAsyncWork()); // 返回 Task<Task> await outer.Unwrap(); // 等内层 Task 完成
绝大多数场景下，应该直接用 Func<task></task> 的等价替代：
await Task.Run(() => { /* 同步计算 */ }); // 正确：CPU 密集型工作
await SomeAsyncMethod(); // 正确：本就是异步，无需 Task.Run 包裹
一句话判断该用哪个
只在需要将「纯同步、CPU 密集」代码卸载到线程池时用 Action；Func<task></task> 几乎总是错的起点——如果你手头有个 async 方法，别把它塞进 Task.Run，直接 await 它。真正需要 Func<task></task> 的场合，往往说明你已经在处理多层异步封装，这时更要小心任务生命周期和异常传播。
