网关层必须为每个下游服务单独设置context超时，而非全局统一超时；否则会导致快服务被误杀、链路透传中断、无法分级控制。
go微服务网关中，全链路超时控制必须由 context 驱动，降级和熔断必须按下游服务维度隔离部署；不这样做，超时会堆积 goroutine，熔断会误伤无关依赖，降级会返回不兼容结构。
为什么网关层的 context.WithTimeout 不能只设一次
网关作为所有请求入口，需为每个下游服务调用单独设置超时，而非在 handler 入口统一设一个全局 timeout。否则：
- 下游 A 服务响应慢（比如 2s），B 服务快（50ms），但共用 1.5s 超时 → B 总被误杀
- context 一旦 cancel，整个链路无法再透传到更深层调用（如 RPC 子调用）
- 没法做超时分级：HTTP 层 800ms、gRPC 层 1.2s、DB 查询层 300ms
实操建议：
- 在路由匹配后、调用前，用 context.WithTimeout 为每个 upstream 单独派生子 context
- 把 timeout 值从配置中心加载（如 etcd 或 nacos），支持 per-route 级别热更新
- 用 req = req.WithContext(ctx) 显式替换 request context，避免漏传
gobreaker 必须每个下游服务一个实例
常见错误是整个网关只初始化一个 gobreaker.CircuitBreaker 实例，然后所有服务调用都走它。后果是：
- 用户服务失败导致订单服务也被熔断（共享失败计数）
- ReadyToTrip 判定逻辑无法区分 HTTP 503 和 gRPC codes.Unavailable
- MaxRequests 设为 1 时，半开探测刚进来就拒绝全部请求（实际应 ≥10）
实操建议：
- 按 upstream.Name（如 "user-svc"、"order-svc"）注册独立 breaker
- Interval 设为 30s～2m（太短易受瞬时抖动干扰）
- Timeout 不是 HTTP 超时，而是“Open 状态持续多久后进入 Half-Open”，推荐 15s
- ReadyToTrip 函数里必须检查 status code：HTTP 5xx、gRPC codes.Internal 算失败；4xx（如 404）通常不算
降级响应必须与原接口结构体兼容
网关降级不是返回 {"code":503,"msg":"fallback"} 就完事。真实踩坑点：
- 原接口返回 struct{ UserID int `json:"user_id"` }，降级返回 map[string]interface{} → JSON 序列化字段名不一致，前端解析失败
- 降级逻辑里调用了另一个可能失败的缓存服务（如 Redis），导致 fallback 自身 panic
- 未设置 Content-Type: application/json，浏览器收到纯文本直接报 CORS 或解析错
实操建议：
- 降级函数必须返回与主逻辑**完全相同的类型**（包括指针/值语义）
- 所有降级数据预加载进内存（如启动时从配置或本地文件读取默认用户对象）
- 用 http.Error 或显式 write header + body，确保 status code 和 header 与原路径一致
- 降级分支禁止任何外部 I/O（不连 DB、不发 HTTP、不查 Redis）
熔断指标暴露必须绑定 Prometheus Label
如果只暴露 gobreaker_requests_total 这种无 label 的指标，你根本没法知道是哪个服务触发了熔断。线上排查时只会看到 “Open 率 100%”，但不知道是 payment-svc 还是 notify-svc。
实操建议：
- 初始化 breaker 时传入 Name: "payment-svc"，并用 gobreaker.Metrics 注册带 service label 的指标
- 至少暴露三个指标：circuit_breaker_state{service="xxx"}（0=Closed, 1=Open, 2=HalfOpen）、circuit_breaker_requests_total{service="xxx",result="success|failed|rejected"}、circuit_breaker_fallback_total{service="xxx",reason="timeout|open|panic"}
- Grafana 看板按 service 分组，设置告警：当某 service 的 circuit_breaker_state == 1 持续 60s，立刻通知负责人
最容易被忽略的是：网关的熔断器状态必须能被上游感知——比如前端 SDK 需要根据 X-RateLimit-Remaining 或自定义 header（如 X-Circuit-State: open）决定是否降级 UI。这要求你在 cb.Execute 失败后，显式写入 response header，而不是只改 body。
