go api聚合网关核心是隔离下游故障：需为每个请求配独立context.withtimeout、用sync.waitgroup等待、defer cancel()防泄漏；响应结构体字段用指针类型区分空值与缺失；director仅改url/host，鉴权和日志前置；http.transport须显式配置连接池与超时。
Go 做 API 聚合网关，核心不是“能不能并发请求”，而是“怎么让多个下游响应不互相拖垮、不掩盖失败、不漏超时”。直接用 http.Client.Do 串行调三个服务，或用 goroutine 开一堆但不等结果，都会在线上出事。
聚合必须用 context.WithTimeout + sync.WaitGroup 控制生命周期
每个下游调用都要绑定独立的 context.Context，不能共用父 ctx 或全局 timeout。否则一个慢接口会拉长所有响应时间，甚至卡死整个聚合流程。
- 为每个下游请求生成独立子 ctx：
ctx, cancel := context.WithTimeout(parentCtx, 2*time.Second) - 用
sync.WaitGroup等待全部 goroutine 完成，而不是靠time.After粗暴等待 - goroutine 内部必须 defer cancel()，避免 ctx 泄漏
- 不要在 goroutine 里直接
http.DefaultClient.Do(req)，要传入带 timeout 的自定义http.Client
聚合结果结构体字段要用指针类型（如 *string）
下游服务返回的字段可能为空、缺失或为零值，如果结构体字段是 string 类型，就无法区分“字段没返回”和“返回了空字符串”。前端适配时容易误判。
- 用
*string、*int64、*bool等指针类型定义聚合响应结构体 - 反序列化时，JSON 包会自动把缺失字段设为
nil，有值才分配内存 - 别为了省事用
map[string]interface{}，后期字段变更、类型校验、文档生成全崩
Director 函数里只改 URL 和 Host，别碰鉴权和日志
很多人在 ReverseProxy.Director 里塞 JWT 解析、DB 查询、甚至打日志——这会让每个请求都多一次阻塞操作，且错误归因困难。
-
Director只负责把请求“改写成能发给后端的样子”：改req.URL.Host、req.URL.Path、req.Host，加X-Forwarded-*头 - 鉴权必须放在 Director 之前，作为独立中间件；失败就直接
http.Error，不进代理链 - 日志中间件也得前置，记录原始 path/method/status，否则 Director 改完后就看不出用户真正调了什么
- WebSocket 流量要提前拦截，检查
Upgrade和Connection头，跳过默认代理逻辑
下游 hang 住时，网关 CPU 持续高？检查 Transport 连接池和超时
现象：某个下游服务卡死，网关响应从 100ms 涨到 30s，top 显示 Go runtime 占满 CPU。这不是代码逻辑问题，而是 http.Transport 配置不当导致连接堆积、协程疯涨。
- 必须显式配置
http.Transport：设置MaxIdleConns、MaxIdleConnsPerHost、IdleConnTimeout -
DialContext要带超时，避免 DNS 查询卡死；TLSHandshakeTimeout也要设，防止 TLS 握手挂住 - 别用
http.DefaultClient，它默认不限制连接数，高并发下会耗尽文件描述符 - 转发前清掉 hop-by-hop 头：
req.Header.Del("Connection")、req.Header.Del("Keep-Alive")，否则某些后端会拒收
聚合网关最难的从来不是并发调用，而是每个下游都可能失败、超时、返回格式不一致、甚至根本连不上。你得在 Director 之外建一层错误分类，用 ModifyResponse 统一兜底，再靠 ErrorHandler 把 dial timeout、503、空响应区分开——这些细节不补全，线上第一波流量就会暴露问题。
大量免费API接口：立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游，为数据API应用能力赋能！
