微服务数据聚合层在gin中必须并发调用下游服务，不可串行；否则总延迟累加、错误扩散、连接竞争且context失效，应使用带超时的goroutine+channel配合waitgroup。
微服务数据聚合层在 Gin 中必须用并发，不能靠串行拼接；否则延迟直接累加，用户体验断崖式下跌。
为什么不能用 for 循环串行调用下游服务
聚合层本质是“等所有子服务返回再合并”，串行调用（for + http.Get）会让总耗时 = 各服务耗时之和。比如三个下游分别要 200ms、300ms、400ms，串行就是 900ms；而并发只需约 400ms。
- 更危险的是：串行逻辑一旦某个下游超时或失败，后续请求全被阻塞，错误扩散范围大
- Go 的
net/http默认复用连接，串行调用还可能因 keep-alive 复用导致连接竞争，反而触发额外排队 -
gin.Context在 handler 返回后就被回收，串行里看似“安全”的c.Request.Context()实际上在最后一个下游返回前就可能失效
用 goroutine + channel 并发拉取，但必须设超时
直接起 goroutine 调下游没问题，但必须绑定上下文超时，否则一个慢接口拖垮整个聚合层。
- 别用
time.Sleep模拟等待，要用context.WithTimeout(c.Request.Context(), 2*time.Second) - 每个下游请求都应有自己的子 context，避免一个失败影响其他请求的 cancel 信号传播
- channel 缓冲区大小建议设为 1，防止 goroutine 泄漏（如下游 panic 未 recover，goroutine 卡在 send）
- 示例关键片段：
ctx, cancel := context.WithTimeout(c.Request.Context(), 2*time.Second) defer cancel() go func() { defer close(ch) resp, err := http.DefaultClient.Do(req.WithContext(ctx)) // ... 处理 resp/err，写入 ch }()
用 sync.WaitGroup 等待全部完成，但别在 handler 里阻塞主 goroutine
sync.WaitGroup 是最轻量的同步方式，但注意它只负责“等结束”，不处理结果传递 —— 结果仍需靠 channel 或共享变量（加锁）收集。
- 别在
WaitGroup.Wait()后直接读共享变量，除非你加了mutex.Lock()，否则存在竞态 - 更推荐 channel 收集：每个 goroutine 写一个
chan Result，主 goroutine 用for i := 0; i 拉取 - 如果某下游提前失败，不要立刻
return，先发 signal 给其他 goroutine（通过 context cancel），再等它们退出，避免 goroutine 泄漏
别忽略 gin.Context 的生命周期，异步任务必须用 c.Copy()
这是 Gin 聚合层最常踩的坑：在 goroutine 里直接用 c 取参数、写日志、甚至调 c.Request.Header.Get()，运行一阵就 panic “context canceled” 或空指针。
- 只要涉及异步（哪怕只是打一条审计日志），就必须先调
copyCtx := c.Copy() -
c.Copy()复制的是当前请求上下文的快照，包括 URL、Query、Header、Body（已读取部分），但不包含响应写入能力（c.Abort()、c.JSON()会 panic） - 复制后的
copyCtx只能用于读操作，别试图用它返回响应 —— 响应必须由原始 handler 完成
真正难的不是并发语法，而是控制好每个 goroutine 的生命周期、上下文边界和错误传播路径。一个没关掉的 channel、一次没 cancel 的 context、一处没 copy 的 gin.Context，都可能在线上跑几天才暴露为内存泄漏或 500 错误。
