不能直接用net/http.handle做聚合，因其本质是串行阻塞调用，无法满足并发发起、独立超时、统一收口三大硬性条件；真正聚合需用sync.waitgroup+context.withtimeout控制并发，响应结构体字段须用指针类型以区分空值与未返回。
为什么不能直接用 net/http.Handle 做聚合？
直接用 http.HandleFunc 或 http.ServeMux 处理多个下游服务请求，本质是串行阻塞调用。一旦某个下游响应慢或超时，整个聚合响应就被拖住——这不是“聚合”，是“卡死”。
真正可用的聚合中间层必须满足三个硬性条件：并发发起请求、各自独立超时、统一收口组装。标准库不提供开箱即用的聚合能力，得自己搭骨架。
- 每个下游调用必须绑定自己的
context.WithTimeout，不能共用父 context - 必须用
sync.WaitGroup等待所有 goroutine 完成，不能靠time.Sleep或粗暴select轮询 - 响应结构体字段要用指针类型（如
*string），否则无法区分 “空字符串” 和 “字段未返回”
gorilla/mux + httputil.NewSingleHostReverseProxy 是不是够用？
够用，但仅限单路转发。它天生不支持“一个入口，多个后端并行取数再拼装”的聚合逻辑。它的 Director 函数只改请求目标，没法在响应回来后再做数据合并。
如果你的需求是“把 /user/profile 和 /user/orders 两个接口合并成 /user/summary”，那 httputil.NewSingleHostReverseProxy 就不是工具，而是障碍。
- 别在
Director里做鉴权、日志、DB 查询——这是常见误用，会拖垮吞吐 - WebSocket 流量必须显式判断
Upgrade和Connection头，否则直接失败 - 透传客户端 IP 应优先用
X-Real-IP，X-Forwarded-For可被伪造，不可信
用 harnesdk/httpclient 做聚合是否更稳？
是。它封装了重试、熔断、指标上报和可插拔的 RoundTripper，比裸写 http.Client 少踩至少三类坑：连接池泄漏、无重试导致偶发失败、超时配置分散难维护。
关键点在于复用其 Client.Do 的上下文控制能力，而不是把它当普通 HTTP 客户端用。
- 创建 client 时传入
harnesdk.WithTimeout(2 * time.Second)，而非在每次Do时临时套 context - 用
harnesdk.WithRetry(3)防止网络抖动引发的瞬时失败，但注意幂等性 - 聚合场景下，每个下游应使用独立 client 实例（或至少独立
http.Transport），避免连接池争抢
聚合结果怎么避免字段冲突和空值歧义？
下游服务各自定义的 JSON 字段名很可能重复（比如都叫 id 或 name），直接 json.Unmarshal 到 map[string]interface{} 再拼接，极易覆盖或错位。最稳妥的方式是定义明确的聚合响应结构体，并用指针字段接收。
例如下游 A 返回 {"id":123,"name":"Alice"}，下游 B 返回 {"id":456,"title":"Report"}，聚合结构体应写成：
type Summary struct {
UserID *int64 `json:"user_id"`
UserName *string `json:"user_name"`
ReportID *int64 `json:"report_id"`
ReportTitle *string `json:"report_title"`
}
这样既能保留原始语义，又能在 JSON 序列化时自动忽略 nil 字段，前端无需做空值防御性判断。
真正容易被忽略的是错误码对齐——不同下游的 404 含义可能完全不同，聚合层必须统一映射为业务错误码（如 USER_NOT_FOUND 或 REPORT_DELETED），不能原样透传。
大量免费API接口：立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游，为数据API应用能力赋能！
