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+ 已禁用）、不可调试。
Gateway Restart Profiler
下载
OpenClaw Gateway 重启性能分析工具：分析重启速度、定位启动慢原因、生成性能报告、诊断启动问题。支持 Windows (PowerShell) 与 Linux (Bash)。触发场景：分析 gateway 重启、检查启动时间、生成报告、诊断异常。
- ❌ 错误示例：
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 都是“能跑通但不该用”的操作——它们暴露的是设计断点，而不是解决方案。
