本地自测熔断降级需绕过注册中心、手动包装error（如HTTP非2xx、gRPC特定状态）、启停真实服务验证状态切换、降级逻辑解耦可测、重写ReadyToTrip避免慢调用误熔断。
本地自测熔断降级，核心是绕过服务发现和注册中心，直接构造故障场景验证行为是否符合预期——否则你测的不是熔断逻辑，而是 Consul/Etcd 的健康检查延迟或网络抖动。
用 gobreaker 模拟真实调用链路时必须手动包装 error
很多人把 gobreaker.Execute 当成黑盒，传进去一个函数就以为万事大吉。但实际中，gobreaker 只认 error 类型失败：它不会自动把 HTTP 404、503 或 gRPC StatusError 当作熔断依据，除非你显式返回 error。
- HTTP 客户端调用后要检查
resp.StatusCode，非 2xx 需手动return nil, errors.New("http error") - gRPC 调用后要检查
status.Code(err)，Canceled、Unavailable、DeadlineExceeded这类才该触发熔断 - 别依赖
err != nil做判断——比如超时返回context.DeadlineExceeded是 error，但连接拒绝（如端口未监听）可能返回connection refused，这两者在熔断策略里应同等对待
本地启停被调用服务来验证 Open / Half-Open 状态切换
最直接的验证方式：让下游服务进程真实不可达，而不是 mock 返回 error。这样能同时覆盖网络层异常（如 TCP RST）、客户端超时、以及熔断器状态机响应。
- 写个极简 HTTP server（用
net/http），只监听:8081，不注册到 Consul，也不加任何中间件 - 启动它 → 调用方发起请求成功 → 手动
kill -9它 → 连续发 5 次请求（确保超过ConsecutiveFailures阈值）→ 第 6 次应直接走Open状态，不发请求、秒返 error - 等满
sleepWindow（比如 5s）后，再发一次请求 → 此时应进入Half-Open，真正发一次请求试探；若仍失败，重置计数器并回Open；若成功，则恢复Closed
降级逻辑必须与熔断器解耦，且独立可测
降级不是熔断器的一部分，而是业务代码对 gobreaker.Execute 返回 error 的响应策略。如果把降级逻辑硬塞进 Execute 的 fallback 函数里，会导致两个问题：无法单独单元测试降级分支、无法在熔断关闭时复用同一套兜底逻辑。
立即学习“go语言免费学习笔记（深入）”；
- 定义清晰的降级接口，例如
type FallbackProvider interface { GetUserFallback(ctx context.Context, req *GetUserRequest) (*User, error) } - 在调用处显式判断：
if err != nil { return fallback.GetUserFallback(ctx, req) }，而不是在Execute闭包里做 - 测试时可直接 new 一个 fake
FallbackProvider，注入 mock 数据，验证是否真走到了降级路径
最容易被忽略的一点：熔断器的 ReadyToTrip 函数默认只看连续失败次数，但在真实微服务中，慢请求（如 P99 > 2s）和错误请求（5xx）对系统危害不同。如果你没重写这个函数，哪怕成功率 99%，只要连续几个慢调用就能误熔断——这在压测或冷启动时特别容易发生。
