gin+sentinel默认无熔断功能，因go版sentinel-golang不自动织入http handler，需手动在handler中调用degrade.entry/exit及traceerror上报指标，否则熔断规则不生效。
Gin 框架本身不带断路器能力，必须靠 Sentinel 的 degrade 模块实现熔断降级；但直接用 Go 版 sentinel-golang 时，它默认只提供系统级限流（如 system.InboundQPS），**不内置 HTTP 层的异常率/响应时间熔断逻辑**——这点和 Java 版 Sentinel 完全不同，容易踩坑。
为什么 Gin + Sentinel 默认没有熔断功能
Java 版 Sentinel 通过 AOP 自动拦截 Controller 方法并统计异常、RT；而 Go 版 sentinel-golang 是面向资源粒度的轻量库，core.degrade 模块需要你手动包裹业务代码并上报指标，没有自动织入 HTTP handler 的机制。
-
sentinel-golang的degrade.LoadRules只注册规则，不绑定任何执行上下文 - 你必须在 Gin handler 里显式调用
degrade.Entry和degrade.Exit，否则熔断永远不触发 - 错误类型（如 panic、error 返回）需自行判断并传给
degrade.TraceError，框架不自动捕获
手动实现 HTTP 接口熔断的三步写法
以“订单查询接口超时或失败率过高时自动熔断”为例，核心是把降级逻辑塞进 Gin handler，并严格配对 Entry/Exit：
- 定义资源名：用路径或业务标识，如
"order_query"，避免用动态参数（/order/:id会生成大量资源） - 规则加载（一次即可）：
degrade.LoadRules([]*degrade.Rule{ { Resource: "order_query", Grade: degrade.GradeSlowRequestRatio, // 或 degrade.GradeExceptionRatio Count: 0.5, // 阈值 50% TimeWindow: 60, // 统计窗口 60 秒 MinRequestAmount: 10, // 最小请求数才触发判断 }, }) - Gin handler 中手动埋点：
func getOrder(c *gin.Context) { entry, blockErr := degrade.Entry("order_query") if blockErr != nil { c.AbortWithStatusJSON(429, map[string]string{"msg": "service degraded"}) return } defer entry.Exit() // 必须 defer，否则 Exit 不执行 // 实际业务逻辑 err := callOrderService() if err != nil { degrade.TraceError("order_query", err) // 手动上报错误 } }
常见错误：panic 没被捕获导致熔断失效
Gin 默认 recover 中间件会吞掉 panic，但 sentinel-golang 不感知这个行为——如果你的业务代码 panic 了，又没在 degrade.TraceError 里显式上报，Sentinel 就当这次请求成功，熔断阈值永远凑不齐。
- 解决方案：在 recover 中间件里补上报，例如：
func panicRecover() gin.HandlerFunc { return func(c *gin.Context) { defer func() { if r := recover(); r != nil { degrade.TraceError("order_query", fmt.Errorf("%v", r)) } }() c.Next() } } - 或者更稳妥：所有可能 panic 的地方都包 try-catch，再统一
TraceError - 别依赖
entry.Block()判断是否熔断——它只反映当前请求是否被拒绝，不等于熔断已开启；查状态要用degrade.GetStat("order_query").IsBlocked()
真正麻烦的不是写几行代码，而是每个要熔断的接口都得手动加 Entry/Exit/TraceError；没封装好就极易漏埋点、错资源名、忘记 defer Exit。线上跑着跑着发现熔断没生效，八成是这里断了链路。
