gin 默认不熔断，因其仅为http路由框架，无内置健康感知能力；所有熔断需在业务层显式封装下游调用（如用hystrix.go包装client.do），并配置errorpercentthreshold与requestvolumethreshold等参数触发。
为什么 Gin 默认不熔断，哪怕下游全挂了
Gin 本身是 HTTP 路由和中间件框架，不内置服务健康状态感知能力。它不会因为你调用 http.Client 失败 10 次就自动拒绝后续请求——所有错误都得你手动捕获、判断、上报，否则熔断器根本“看不见”故障。Go 版 sentinel-golang 的 degrade 模块只管资源维度的指标统计，不自动 hook HTTP handler；hystrix-go 也只封装单次函数调用，不自动包裹整个 Gin route。系统级故障（如依赖服务整体不可达、DNS 解析失败、连接池耗尽）必须靠你在业务代码里显式触发降级逻辑。
用 hystrix-go 在 Gin 中做最简系统级熔断
适合快速兜底，不改业务结构，对下游 HTTP 调用做一层包装：
-
hystrix.Go("order_service", runFunc, fallbackFunc)必须包裹每个外部调用，不能只包一次 handler 入口 -
runFunc里要包含完整 HTTP 请求逻辑（含client.Do()），否则超时/连接拒绝类错误无法被捕获 -
fallbackFunc必须返回与runFunc相同签名的值，比如都返回[]byte, error，否则编译报错 - 全局
hystrix.ConfigureCommand需设ErrorPercentThreshold: 50和RequestVolumeThreshold: 20，否则低流量下永远不触发熔断
示例片段：
func getOrder(c *gin.Context) {
id := c.Param("id")
data, err := hystrix.Go("order_http", func() (interface{}, error) {
resp, err := client.Get("http://order-svc/v1/order/" + id)
if err != nil {
return nil, err // 连接失败、DNS 错误都会进这里
}
defer resp.Body.Close()
return io.ReadAll(resp.Body), nil
}, func(err error) (interface{}, error) {
return []byte(`{"msg":"order service degraded"}`), nil
})
if err != nil {
c.AbortWithStatusJSON(503, map[string]string{"error": "circuit open"})
return
}
c.Data(200, "application/json", data.([]byte))
}
sentinel-golang 做细粒度熔断时最容易漏掉的三件事
比 hystrix-go 更灵活，但埋点稍重，漏掉任意一项规则就完全失效：
- 没调
degrade.TraceError("resource_name", err)：panic、timeout、status != 200 都不算“异常”，必须手动上报 -
Entry和Exit不成对：defer entry.Exit()放在 handler 开头之后、业务逻辑之前，否则 panic 会跳过Exit，计数器卡死 - 资源名含动态参数：写成
"GET /order/:id"会导致每条 ID 生成独立资源，熔断阈值永远凑不够MinRequestAmount
正确资源名应为固定标识，例如 "order_query_http" 或 "order_service_call"，与路径无关。
当连接层直接失败（如 dial timeout、no route to host）时，熔断器还来得及吗
来得及，但必须把网络层错误纳入判断范围。HTTP 客户端默认不抛出底层连接错误到业务层——client.Do() 返回的 err 就是 dial error、TLS handshake failed 等系统级错误，这些都要传给 degrade.TraceError 或作为 hystrix.Go 的 runFunc 错误返回。别写 if resp.StatusCode != 200 { ... } 就完事，那只会漏掉 90% 的真实故障场景。
真正容易被忽略的是：熔断统计窗口（TimeWindow）和最小请求数（MinRequestAmount）在低频接口上几乎无效。如果你的订单查询 QPS 只有 2，60 秒内凑不满 10 次请求，MinRequestAmount: 10 的规则就永远不会生效——此时要么调低该值，要么换用基于时间窗口失败率的 GradeSlowRequestRatio 规则并配更小的 TimeWindow。
