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<t></t>封装外部事件（如按钮点击、消息到达） 用
ManualResetEventSlim+
WaitHandle.WaitOne（需注意线程上下文） 在 async 方法中优先选
await Task.WhenAny(task, Task.Delay(timeoutMs))实现带超时的等待
记住：
Delay(-1)和
WaitAll都是“能跑通但不该用”的操作——它们暴露的是设计断点，而不是解决方案。
