go微服务优雅降级需用gobreaker替代hystrix-go，fallback须为纯函数、不重试、不panic；按依赖隔离breaker实例；监控宜用prometheus+grafana而非hystrix dashboard。
Go 微服务里怎么加优雅降级，不是靠 panic 后 recover
降级不是兜底逻辑写在 defer 里就完事——那只是把 panic 拦住，没解决依赖不可用时的业务语义问题。真正的降级要满足：调用方感知不到下游崩了、返回合理默认值或缓存、不拖垮自身线程池。
- 用
gobreaker（比原生hystrix-go更轻、更可控）替代过时的hystrix-go，后者已归档且不支持 Go module 的 clean import - 降级函数必须是纯函数：无副作用、不改全局状态、不发新请求；比如返回
cache.Get("user:123")或硬编码的defaultUser结构体 - 别在降级里重试：重试属于熔断器上游策略，和降级正交；混在一起会导致超时叠加、雪崩风险上升
- 注意
gobreaker.Settings.Timeout单位是time.Millisecond，设成500是 500ms，不是秒——填错会让人误以为“降级没触发”，其实是请求根本没走到降级环节就被超时中断了
Dashboard 监控为什么连不上 Hystrix Stream，Go 服务压根没暴露 /hystrix.stream
Hystrix Dashboard 是 Java 生态产物，它只认 /hystrix.stream 这个固定路径的 SSE 流，而 Go 没有内置等价物。强行套用只会看到 “Unable to connect to Command Metric Stream”。
- 别试图用
hystrix-go的hystrix.StreamHandler()：它输出的是原始 JSON 数组，不是 Dashboard 要的data: {...}格式 SSE，浏览器 F12 看 Network 就能发现响应头缺Content-Type: text/event-stream - 如果真要对接 Dashboard，得自己写一个转换 handler：读取
gobreaker的State()或 Prometheus metrics，按 SSE 格式逐行输出data: {json}，每条后跟两个换行符 - 更现实的做法是弃用 Dashboard，直接用 Prometheus + Grafana：给每个 breaker 实例注册
prometheus.GaugeVec，指标如breaker_state{name="user_client",state="open"}，可视化更灵活，也避免 SSE 长连接对 Go HTTP server 的隐性压力
并发高时降级失效，日志里全是 “circuit open” 但 fallback 函数根本不执行
这不是降级逻辑错了，是熔断器状态切换和请求分流没对齐。当大量请求在熔断器刚打开瞬间涌入，部分会走 fallback，部分直接被拒绝（返回 error），行为不一致。
-
gobreaker.Settings.ReadyToTrip默认是统计最近 100 次调用，错误率超 50% 就熔断——高并发下这 100 次可能集中在几毫秒内，导致“假性熔断”。建议调大RequestVolumeThreshold到 500+，并配Timeout≥ 3000 - 确保 fallback 函数不 panic：一旦 fallback panic，
gobreaker会把它当主函数失败计入统计，加速熔断，形成负反馈循环 - 检查是否用了共享的
gobreaker.CircuitBreaker实例：多个 HTTP handler 共用一个 breaker 时，不同 endpoint 的失败会互相污染统计。应按依赖服务维度隔离，比如userCB、orderCB各自独立
