Go高性能聚合需用channel+sync.WaitGroup并显式关通道，缓冲区大小匹配任务数，defer wg.Done()加recover防护，聚合优先用预分配切片而非sync.Map，顺序敏感时带索引传输，各stage须监听ctx.Done()实现背压。
别直接套“流式框架”概念——Go 里没有开箱即用的 DataFlow API，真要高性能聚合，得从 chan、sync.WaitGroup 和明确的生命周期控制出发。盲目封装成“框架”反而增加调度开销和理解成本。
用 channel + sync.WaitGroup 做结果归集，但必须关通道
很多人写完 wg.Wait() 就直接 for range results，结果主协程永远卡住。因为 range 遇不到关闭信号不会退出。
- 关通道的动作必须在单独 goroutine 里做：
go func() { wg.Wait(); close(results) }() - 通道要带缓冲，大小设为任务总数（如
make(chan Result, len(tasks))），否则 sender 可能因阻塞而卡死 - 每个 goroutine 开头就
defer wg.Done()，且放在recover包裹内，防止 panic 导致 wg 永不完成
聚合阶段别碰 sync.Map，优先用预分配切片 + 索引
如果你只是把上万条字符串按 category 分组求和，sync.Map 是过度设计。它适合 key 动态增删、读远多于写的场景；而聚合通常是固定维度、写一次读多次。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 先用
map[string]int或map[string]float64在主线程初始化，然后让每个 goroutine 把结果发回 channel，主协程统一累加 - 若需保留原始顺序（比如输入第 3 行对应输出第 3 行），别依赖 channel 收到顺序——改用
struct{ Index int; Value float64 }，主协程按Index排序或直接填入预分配切片 - 避免在 goroutine 里直接写共享 map：哪怕加了
sync.RWMutex，高频写入也会成为瓶颈
流式 pipeline 中每个 stage 必须监听 ctx.Done()
日志解析 → 过滤 → 上报，这种链路一旦某个 stage 卡住（比如 HTTP 超时没设），整条 pipeline 就堵死。Go 的流式不是靠缓冲区扛压，而是靠 channel 阻塞天然传导背压。
立即学习“go语言免费学习笔记（深入）”；
- 每个 stage 启动独立 goroutine，
select第一分支必须是 - stage 输出 channel 用
defer close(out)，否则下游range out永远等不到 EOF - HTTP 上报 stage 必须用
http.Client配Timeout，且 client 要复用（别每次 new），否则连接池失效 + TLS 握手开销爆炸
最常被忽略的一点：聚合逻辑本身不能成为瓶颈。与其花时间优化 map[string][]int 的并发写，不如确保上游数据能持续流入——检查 channel 是否带缓冲、context 是否传到底层调用、错误是否被吞掉。数据流停了，再快的聚合也没意义。
