应显式关闭带缓冲的channel并用sync.waitgroup协调，range卡死因未关通道；聚合用预分配切片而非sync.map；需顺序时携index结构体；各stage须监听ctx.done()实现背压，http调用必复用client并设超时。
直接用 channel + sync.WaitGroup + 显式关通道，别套“框架”概念——Go 里没有开箱即用的 DataFlow API，硬封装反而拖慢吞吐、增加理解负担。
为什么 range channel 会卡死？因为没关通道
常见错误是 wg.Wait() 后直接 for range results，结果主协程永远阻塞。range 只有收到关闭信号才会退出，而通道没关，它就一直等。
- 关通道必须在独立 goroutine 里做：
go func() { wg.Wait(); close(results) }() - 通道必须带缓冲，大小设为任务总数，例如
make(chan Result, len(tasks))；否则 sender 可能因下游未读而阻塞 -
defer wg.Done()一定要放在每个 goroutine 开头，并包裹在recover里，防止 panic 导致计数器不减
聚合阶段别碰 sync.Map，优先预分配切片
如果你只是按固定字段（如 category、region）分组求和或拼接，sync.Map 是过度设计。它适合 key 动态增删、读远多于写的场景；聚合通常是写一次、读多次。
- 主线程初始化
map[string]int或map[string][]string，然后让每个 goroutine 把结果发回channel，主协程统一累加 - 避免在 goroutine 里直接写共享 map —— 即使加了
sync.RWMutex，高频写入也会成为瓶颈 - 若需保留原始顺序（比如输入第 3 条对应输出第 3 条），别依赖 channel 收到顺序；改用
struct{ Index int; Value interface{} }，主协程按Index填入预分配切片
每个 stage 必须监听 ctx.Done() 实现背压
HTTP 请求 → 解析 → 过滤 → 聚合，这种 pipeline 一旦某个 stage 卡住（比如没设 timeout 的 http.Client），整条链就堵死。Go 的背压靠 channel 阻塞天然传导，不是靠缓冲区硬扛。
- 每个 stage 启动独立 goroutine，
select第一分支必须是向输出 channel 发送，且要defer close(out) - HTTP stage 必须复用
http.Client并配Timeout，否则连接池失效、TLS 握手开销爆炸 - 所有底层调用（包括
http.Get、json.Unmarshal、DB 查询）都得传入ctx，并在开头select { case
最容易被忽略的不是聚合逻辑本身，而是上游数据是否持续流入——检查 channel 是否带缓冲、context 是否传到底层、错误是否被吞掉。数据流停了，再快的聚合也没意义。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
