绝大多数场景应优先用 task，仅当必须独占线程、控制调度细节或绕过线程池时才用 thread；task 更安全轻量易维护，thread 创建开销大且异常未捕获会直接终止进程。
Thread 和 Task 不是“选哪个更好”，而是“该不该自己扛线程管理这摊事”。绝大多数场景下，用 Task 是更安全、更轻量、更易维护的选择；只有当你明确需要独占线程、控制调度细节或绕过线程池时，才该碰 Thread。
什么时候必须用 Thread？不是“想用”，而是“不得不”
以下情况绕不开 Thread：
- 任务需长期驻留且不能被线程池回收（比如一个永不退出的传感器轮询循环）
- 必须设置
Priority、IsBackground = false（前台线程）、ApartmentState.STA（如 COM 组件或某些 UI 交互） - 要绑定到特定 CPU 核心（通过
ProcessorAffinity），或避免被线程池“偷走”执行权 - 调试/监控要求精确对应到 OS 级线程 ID（
ManagedThreadId≠NativeThreadId，但Thread.ManagedThreadId可稳定映射）
注意：Thread 创建即分配约 1MB 栈空间，频繁新建会快速耗尽虚拟内存。不要在循环里 new Thread。
Task.Run 默认复用线程池，但不等于“总是安全”
Task.Run 看似简单，实际行为取决于你传进去的是什么：
- 传纯计算逻辑（如
() => { for(...) {...} }）→ 交由ThreadPool执行，可能抢占 I/O 线程，导致async操作卡顿 - 传
asynclambda（如async () => await File.ReadAllBytesAsync(...)）→ 实际不占线程，只注册回调，真正执行靠 I/O 完成端口 - 传阻塞调用（如
() => Thread.Sleep(1000)）→ 白占线程池线程 1 秒，高并发下容易拖垮线程池（ThreadPool.GetAvailableThreads会持续下降）
验证方式：在 Task.Run 内部打日志 + Thread.CurrentThread.ManagedThreadId，观察是否复用、是否切换。
异常处理差异直接决定程序是否崩溃
Thread 中未捕获异常 → 直接终结进程（.NET 6+ 默认行为），没有挽回余地：
var t = new Thread(() => { throw new InvalidOperationException("boom"); });
t.Start(); // 进程立即退出，Main 里的 try/catch 捕不到
Task 中未捕获异常 → 封装进 Task.Exception，仅在 await 或 Wait() 时抛出，可集中捕获：
var t = Task.Run(() => { throw new InvalidOperationException("boom"); });
try { await t; }
catch (AggregateException ex) { /* ex.InnerExceptions 包含原始异常 */ }
但要注意：如果完全不 await / 不 Wait / 不读取 Exception 属性，.NET 会触发 UnobservedTaskException 事件（默认终止进程），这点常被忽略。
返回值、状态、组合能力不是“锦上添花”，而是“能否落地”
你需要等多个操作完成再汇总结果？Thread 得自己搞 ManualResetEvent + 共享变量 + 锁；Task 一行解决：
var tasks = urls.Select(url => DownloadAsync(url)); var results = await Task.WhenAll(tasks); // 自动并发、自动聚合、自动异常合并
你要限制最大并发数？Thread 得手写信号量 + 队列；Task 配合 SemaphoreSlim 十分自然：
var semaphore = new SemaphoreSlim(5);
await semaphore.WaitAsync();
try { await ProcessItemAsync(item); }
finally { semaphore.Release(); }
这些不是语法糖——它们把资源竞争、状态同步、错误传播这些极易出错的底层逻辑，封装进了运行时保障的语义里。跳过它们，等于主动选择重复造轮子和埋坑。
真正难的从来不是“怎么写多线程”，而是“怎么让多线程不出错”。用 Task 不代表能避开并发问题，但它把出错面从“线程生命周期+同步原语+异常传播”压缩到了“数据竞争+取消协作”这一层，已经窄得多。
