网关层必须为每个下游服务单独设置context.withtimeout并隔离熔断器实例，否则会导致快服务被误杀、慢服务永远超时、熔断状态污染及降级结构不兼容；超时需per-route热更新配置，熔断器timeout指open持续时长而非请求超时，readytotrip须区分错误类型，降级函数签名与主逻辑必须完全一致。
网关层必须为每个下游服务单独设置 context.WithTimeout，不能在入口统一设一个全局超时；熔断器也必须按服务维度隔离，共用一个 gobreaker.CircuitBreaker 实例会导致误熔断和状态污染。
为什么 context.WithTimeout 必须 per-route 单独调用
全局 timeout 看似省事，实则破坏 SLA 分级能力。比如用户服务平均响应 50ms，订单服务因 DB 复杂查询常达 1.8s，若统一设 1.2s 超时，订单服务永远无法成功返回，而用户服务却要多等 1.15s 才释放 goroutine。
- 超时必须在路由匹配后、调用前派生：用
req = req.WithContext(ctx)显式替换 request context，否则下游中间件（如 gRPC 拦截器）收不到 - HTTP client 必须启用
Transport.IdleConnTimeout和Transport.DialContext，否则 DNS 或连接建立阶段会绕过 context 控制 - gRPC 调用需用
ctx入参（如client.GetUser(ctx, req)），不能只传req后再加超时 - 配置值应从中心化配置加载（如 etcd key
/gateway/routes/user-svc/timeout），支持热更新，避免重启生效
为什么每个下游服务都要独立 gobreaker.CircuitBreaker 实例
共享 breaker 是生产事故高发区。曾有团队将所有服务都走同一个 cb，结果缓存服务因网络抖动失败 5 次，直接导致支付服务被熔断——两者根本无依赖关系。
- 实例名必须带服务标识，如
"user-svc"、"inventory-svc"，便于日志追踪和监控聚合 -
Timeout字段不是单次请求超时，而是 “open 状态持续多久后尝试半开”，建议设 15s～60s；别和context.WithTimeout数值混用 -
ReadyToTrip函数里必须区分错误类型：HTTP 5xx、gRPCcodes.Internal算失败；404、400 通常不算，否则正常业务异常也会触发熔断 -
MaxRequests在 half-open 状态下控制试探请求数，设为 1 容易刚探测就打满失败阈值，推荐 ≥5
降级响应结构体不兼容是静默故障主因
前端解析失败往往不是因为没 fallback，而是 fallback 返回了 map[string]interface{}，而主逻辑返回的是 struct{ UserID int `json:"user_id"` } ——字段名、嵌套层级、空值处理全对不上。
- 降级函数签名必须和主逻辑完全一致，包括是否是指针类型（
*UservsUser） - 所有降级数据应在启动时预加载进内存（如从本地 JSON 文件或配置中心读取默认
User对象），禁止在降级路径里再调 Redis 或 HTTP - 务必显式设置
w.Header().Set("Content-Type", "application/json")，否则浏览器收到纯文本会报 CORS 或解析错 - 如果主逻辑返回 error，降级也必须返回同类型 error（如自定义
ErrServiceUnavailable），不能返回nil
最容易被忽略的点是：context 取消后，goroutine 不会自动退出，除非你调用的底层函数（如 http.Client.Do、sql.DB.QueryContext）真正支持 context；而熔断器只管“放不放行”，不管“超不超时”——这两个机制必须正交配合，缺一不可。
