17370845950

Task.Delay(-1) 返回永不完成的Task，等效于Timeout.Infinite，需配合CancellationToken使用；Task.WaitAll同步阻塞线程，禁用在UI/请求线程；二者混用将导致永久冻结，应改用await Task.WhenAll或TaskCompletionSource。

Task.Delay(-1) 会无限等待，但不是“挂起线程”，而是返回一个永不完成的 Task

它等效于 Task.Delay(Timeout.Infinite)（即 int.MaxValue 毫秒），但语义更明确：你主动要求“永远别完成”。这不是错误，也不会抛异常，而是一个合法、可 await 的“死任务”。
常见误用是把它当“暂停直到手动唤醒”——但它没有取消机制，除非你传入 CancellationToken。

• ✅ 正确用法：await Task.Delay(-1, cancellationToken)，配合外部取消触发退出
• ❌ 错误假设：Task.Delay(-1).Wait() 或 .Result —— 这会永久阻塞当前线程（尤其在 UI 线程中 = 界面卡死）
• ⚠️ 注意：.NET 6+ 中 Task.Delay(-1) 已被标记为 Obsolete，编译器会警告，推荐改用 Task.Delay(Timeout.InfiniteTimeSpan)

Task.WaitAll(tasks) 是同步阻塞，不是异步等待

它会让**当前线程停住不动**，直到所有传入的 Task 对象都进入 RanToCompletion、Faulted 或 Canceled 状态。它不关心这些任务是不是 async 方法启动的，只看底层 Task 实例的状态。

• ✅ 合理场景：后台服务的 Main 方法中协调多个 CPU 密集型 Task.Run，且你确定不会阻塞 UI 或请求线程
• ❌ 绝对禁止：在 WinForms/WPF/ASP.NET Core 请求线程（如控制器 action）里调用 —— WaitAll 会锁死线程池线程，引发严重吞吐下降甚至死锁
• ⚠️ 异常处理必须 catch AggregateException，因为任意一个 task 抛异常都会被打包抛出

两者混用是典型反模式：比如 Task.WaitAll(Task.Delay(-1))

这等于让当前线程永远卡住 —— 因为 Task.Delay(-1) 永不完成，Task.WaitAll 就永远等下去。没有任何超时、无法中断（除非线程被强行 Abort，但 .NET Core+ 已禁用）、不可调试。

• ❌ 错误示例：

  var t = Task.Delay(-1);
  Task.WaitAll(t); // 主线程在此处彻底冻结

• ✅ 替代方案：用 await Task.WhenAll(t) + CancellationToken 控制生命周期；或改用 TaskCompletionSource 手动控制完成时机
• ? 关键区别：WhenAll 返回 Task 可 await，不阻塞；WaitAll 是 void 方法，强制同步等待

真正需要“等一个不确定时间”的时候，该用什么？

多数情况下，你要的不是“无限延迟”，而是“等某个条件满足”或“等外部信号”。直接硬写 Task.Delay(-1) 或死等 WaitAll，说明设计上漏掉了取消、超时或事件驱动机制。

• 用 TaskCompletionSource 封装外部事件（如按钮点击、消息到达）
• 用 ManualResetEventSlim + WaitHandle.WaitOne（需注意线程上下文）
• 在 async 方法中优先选 await Task.WhenAny(task, Task.Delay(timeoutMs)) 实现带超时的等待

记住：Delay(-1) 和 WaitAll 都是“能跑通但不该用”的操作——它们暴露的是设计断点，而不是解决方案。