go中禁用afex/hystrix-go因依赖废弃context包，应改用sony/gobreaker或sentinel-go；后者需显式初始化规则并手动标记error为失败，且熔断器须按服务粒度复用全局实例。
Go 里直接用 Hystrix 官方库会编译失败
Go 官方生态没有维护 hystrix-go 的后续版本，它依赖已废弃的 golang.org/x/net/context（旧版 context），在 Go 1.21+ 环境下会报 undefined: context.Err 或类似错误。这不是你代码写错了，是库本身没升级。
实操建议：
- 别碰原版
afex/hystrix-go，哪怕加replace也容易引发间接依赖冲突 - 改用社区轻量替代：
sony/gobreaker（纯 Go 实现，无外部依赖，接口接近 Hystrix） - 如果必须兼容老项目中的 Hystrix 配置逻辑，可封装一层适配器，把
gobreaker.State映射为HystrixCommand的行为语义
Sentinel Go 的启动必须显式初始化规则引擎
不像 Java 版自动扫描注解，sentinel-go 启动后默认不生效——它不会拦截任何函数调用，即使你写了 @SentinelResource（这其实是 Java 注解，Go 里根本不存在）。所有熔断、限流规则都得手动注册。
常见错误现象：
立即学习“go语言免费学习笔记（深入）”；
- 调用
sentinel.Entry没报错，但压测时完全不触发降级或限流 -
sentinel.LoadRules放在init()里，但规则加载早于配置解析，导致空规则集
实操建议：
- 确保
sentinel.InitWithConfig在 main 入口早期执行，且sentinel.LoadRules在配置就绪后调用 - 规则类型要匹配：熔断用
flow.Rule（限流）、circuitbreaker.Rule（熔断），别把降级策略写成系统保护规则 - 测试时用
sentinel.CurrentEntry().ResourceName()打日志，确认资源名和规则中定义的一致——大小写、斜杠、前缀都不能差
gobreaker 和 sentinel-go 的 panic 处理方式完全不同
这是最容易踩坑的地方：两者对「下游出错」的建模逻辑相反。gobreaker 把函数返回 error != nil 当作失败；而 sentinel-go 默认只把 panic 当作异常事件，正常 error 返回会被视为成功，除非你手动调用 entry.Exit() 前判断并标记失败。
使用场景差异：
- HTTP client 调用返回
*http.Response, error：用gobreaker只需检查err != nil；用sentinel-go必须在err != nil时调用entry.BlockError(err) - 数据库查询返回
rows, err：同理，sentinel-go不会自动感知err，漏掉这步就等于没熔断
性能影响：
-
gobreaker开销极低，就是一次原子计数器更新 -
sentinel-go的BlockError会触发统计上下文切换，高频 error 场景下比gobreaker多约 5%~10% CPU 占用
不要在 HTTP handler 里直接 new Breaker 实例
每个请求都 &gobreaker.Settings{...} 生成新实例，会导致状态隔离、指标丢失、内存泄漏。熔断器本质是共享状态组件，必须复用。
实操建议：
- 按下游服务粒度定义全局变量，例如：
var userSvcBreaker = gobreaker.NewCircuitBreaker(...) - 如果用依赖注入（如 wire/DI），把 breaker 作为 singleton 注入，别塞进 handler 结构体字段里
- 避免在中间件里动态构造 breaker：不同路径共用同一资源名时，误配多个 breaker 实例会让熔断统计被稀释，阈值永远达不到
复杂点在于，真实业务里一个服务可能有多个关键路径（如 /user/profile vs /user/orders），它们失败含义不同，该拆成两个 breaker 还是合并？得看错误传播是否相关——不相关的失败不该互相拖垮。这点很容易被忽略，一上来就全用同一个 breaker，结果登录失败导致头像也刷不出来。
