gobreaker熔断器启动panic的主因是Settings.Name未设置导致nil map写入；重试应优先用retryablehttp并配置CheckRetry，避免手动实现的三大陷阱；重试与熔断组合时需封装闭包确保Execute仅接收最终结果；状态需外存（如Redis）以防重启丢失。
Go 里用 gobreaker 做熔断，但服务启动就 panic？
常见错误是没给 gobreaker.Settings 设置 Name 字段，导致内部 map key 为 nil，一调用 cb.Execute 就 panic： panic: assignment to entry in nil map。这不是配置问题，是结构体字段漏填的硬伤。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
-
Name必须设成非空字符串，哪怕只是"user-service"这种标识名 - 别依赖默认值——
gobreaker的Settings几乎全无默认，ReadyToTrip、OnStateChange等都得显式传 - 如果多个 API 共用一个熔断器，
Name相同会共享状态；想隔离，就用不同Name或单独实例
HTTP 请求重试该用 retryablehttp 还是手写 net/http + time.Sleep？
直接手写容易掉进指数退避逻辑错、context 超时未传递、error 类型未区分这三坑。比如对 503 Service Unavailable 重试有意义，但对 401 Unauthorized 重试只是浪费资源。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 用
retryablehttp.Client，它默认只重试网络层错误（如连接拒绝），要重试特定 HTTP 状态码，得配CheckRetry函数 - 务必设置
Request.Context()，否则重试可能无视上层超时，拖垮整个请求链路 - 别把重试次数设太高（比如 >5），尤其在高并发场景下，容易放大下游压力
重试 + 熔断组合时，gobreaker 的 Execute 里能直接塞 retryablehttp.Client.Do 吗？
能，但不推荐。因为 gobreaker.Execute 期望函数返回 error 来判断是否失败，而 retryablehttp.Client.Do 成功时也返回 *http.Response 和 nil error，看似没问题——可一旦重试耗尽后返回 error，熔断器会把它当“业务失败”计入失败计数，但其实可能是下游暂时不可用，该进熔断，而不是单纯记一次失败。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 把重试逻辑包在闭包里，只让
Execute看到最终结果：成功返回nil，彻底失败才返回error - 若需区分“重试耗尽”和“熔断开启”，可在
OnStateChange回调里打日志或发 metric，别靠 error 字符串解析 - 注意
gobreaker默认失败阈值是 5 次，如果重试 3 次+熔断触发，实际可能只发起 1 次原始请求，但计数已+3——得结合ReadyToTrip自定义逻辑
生产环境里 gobreaker 状态没持久化，重启后熔断器全恢复 OPEN？
是的。gobreaker 纯内存状态，进程一挂，OPEN 状态就丢。这在滚动发布或偶发 OOM 时会导致流量瞬间打垮刚启的服务。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 不要指望它自动恢复，得自己存状态。最轻量的是用本地文件（如
/tmp/cb-state.json）定期写入，启动时读取 - 更稳的做法是集成 Redis：用
SET cb:user-svc-state OPEN EX 300，配合OnStateChange更新，但要注意 Redis 不可用时的 fallback 行为 - 如果服务本身无状态且部署密度高，干脆接受“重启即重置”，但得确保下游有容量余量，否则就是把风险转嫁出去
真正麻烦的不是怎么写重试逻辑，而是搞清哪类错误值得重试、哪类该立刻熔断、哪类必须透传给前端——这些边界没理清，代码写得再工整也只是在错误路径上跑得更快。
