aggregate不是sum替代品，而是状态累积的控制权移交；漏种子、错顺序、硬转类型任一都会运行时崩溃；空集合时两参数版必炸，必须显式传seed；seed类型决定返回类型且空时直接返回；字符串拼接禁用acc+x，应以stringbuilder为累加器；需计数或索引时须用三泛型重载；plinq版需额外提供线程合并函数。
Aggregate 不是 Sum 的替代品，它是状态累积的控制权移交——漏种子、错顺序、硬转类型，三者任一都会在运行时炸。
空集合直接抛 Sequence contains no elements 就是没传 seed
两参数版 Aggregate(Func<t t>)</t> 本质是“无初始状态的二元归约”，空集合时根本找不到第一个元素当起点，必然炸。这不是 bug，是设计：它要求你明确回答“空的时候我该返回什么”。
- 必须显式传 seed，哪怕只是
0、string.Empty或new List<int>()</int> - seed 类型决定最终返回类型，和源集合元素类型无关
- 空集合时直接返回 seed 值，不进 lambda，也不抛异常
- 别依赖
DefaultIfEmpty()后再用两参数版——绕路且语义不清
字符串拼接用 (acc, x) => acc + x 性能断崖式下跌
每次 acc + x 都新建 string 对象，N 次拼接触发 O(N²) 内存拷贝。尤其处理几百个以上字符串时，GC 压力肉眼可见。
Gateway Restart Profiler
下载
OpenClaw Gateway 重启性能分析工具：分析重启速度、定位启动慢原因、生成性能报告、诊断启动问题。支持 Windows (PowerShell) 与 Linux (Bash)。触发场景：分析 gateway 重启、检查启动时间、生成报告、诊断异常。
- 正确做法是用
StringBuilder当累加器：传new StringBuilder()作 seed - lambda 里只调
Append，避免条件判断导致分支跳转（如sb.Length == 0 ? ... : ...可改用sb.Append(',').Append(x)+ 最后 Trim） - 最后用四参数重载的 resultSelector 提取：
sb => sb.ToString() - 别在 lambda 里反复 new 大对象——seed 是每个线程/调用独享的，但滥用仍拖慢 GC
要带计数、索引或中间状态，必须用三泛型参数重载
两参数版只接受 (T, T) => T，完全无法携带“当前处理第几个”或“前面累计了多少个满足条件”。所有上下文都得塞进 TAccumulate 类型里。
- 典型模式：用元组或自定义类封装状态，例如
(count: 0, sum: 0.0, lastValue: 0) - func 签名固定为
(TAccumulate, TSource) => TAccumulate，顺序不能颠倒 - 若最终结果类型和累加器不同（比如要算平均值），必须上四参数重载：
Aggregate(seed, func, resultSelector) - resultSelector 只在全部元素处理完后调一次，不是每轮都执行
PLINQ 的 Aggregate 要额外写线程合并逻辑
并行版 AsParallel().Aggregate 不是简单加速——它把数据分片，每片跑一个累加器，最后还得把各片结果合起来。漏掉第三个参数（线程间合并函数），就只拿到某个分片的结果。
- 四个参数依次是：seed（全局初始值）、per-thread func、thread-combine func、resultSelector
- thread-combine func 必须和 per-thread func 同签名，否则类型不匹配
- 标准差示例里，各线程算的是平方和，最后用
(total, thisThread) => total + thisThread合并——这步漏了就白算 - 性能未必比顺序版快：小集合+简单逻辑时，线程调度开销反超收益
最常被忽略的其实是 seed 和 func 的耦合性：seed 不仅是默认值，它定义了整个累积过程的内存布局和生命周期。传一个 new Dictionary<int int>()</int> 还行，但传 new MemoryStream() 就得小心 Dispose 时机——Aggregate 不管资源释放，全靠你收尾时手动处理。
