Gin集成Sentinel流控必须使用sentinel-golang官方SDK，核心难点在于埋点位置、Entry/Exit配对、resourceName格式（须为"default"且显式指定Inbound）、系统规则命名；埋点须在主goroutine中完成，不可在go func内调用Entry，Exit须defer判空调用，系统规则加载仅能在main初始化阶段执行一次。
直接上结论：Gin 集成 Sentinel 做流控，必须用 sentinel-golang 官方 Go SDK（非 Java 版），且核心难点不在引入依赖，而在 埋点位置、Entry/Exit 配对、resourceName 格式、系统规则命名 四处。错一处，限流就静默失效。
埋点必须在 Gin 主 goroutine 中完成，不能进 go func
常见错误现象：system.InboundQPS 规则始终不触发，system.Load 指标为 0，Dashboard 显示“无数据”。
根本原因：Sentinel Go 的统计上下文绑定在当前 goroutine，跨协程调用 Entry() 会导致指标丢失。
- Gin 中间件里写
go func() { sentinel.Entry(...) }()→ 统计归零 - 在
c.Next()后或 recover() 里补e.Exit()→ panic 或空指针 - 正确姿势：Entry 放在中间件最开头，Exit 用 defer 且判空
示例片段：
func SentinelMiddleware() gin.HandlerFunc {
return func(c *gin.Context) {
e, err := sentinel.Entry("GET:/api/user", sentinel.WithTrafficType(base.Inbound))
if err != nil {
c.AbortWithStatusJSON(429, map[string]string{"msg": "rate limited"})
return
}
defer func() {
if e != nil {
e.Exit()
}
}()
<pre class="brush:php;toolbar:false;"> c.Next()
}}
resourceName 必须统一格式，系统规则必须设为 "default"
常见错误现象：配置了 system.CPU 规则但没生效，Dashboard 看不到系统维度数据。
原因：系统级保护（system.Load / system.CPU / system.RT 等）只认一个 resourceName —— "default"，且埋点时必须显式传 WithTrafficType(base.Inbound)。
- 错：
sentinel.Entry("user-api")→ 不计入系统指标 - 错：
sentinel.Entry("default")但没传WithTrafficType→ 指标类型错配 - 对：
sentinel.Entry("default", sentinel.WithTrafficType(base.Inbound))
系统规则加载示例：
system.LoadRules([]*system.Rule{{
MetricType: system.CPU,
TriggerCount: 80.0, // CPU 使用率 > 80%
}})
规则加载只能做一次，不能放中间件或 handler 里
常见错误现象：服务启动后前几秒限流有效，之后突然全部放行；日志反复打印 “rule engine locked”。
原因：system.LoadRules() 和 flow.LoadRules() 内部加全局锁，高频调用会阻塞规则引擎，甚至导致统计中断。
- 必须在
main()初始化阶段、HTTP server 启动前完成 - 不能在每个请求里 reload 规则（哪怕判断了变化）
- 如需动态更新，请用
sentinel-datasource-nacos或自定义数据源监听器
BBR 自适应策略不是万能的，QPS 固定阈值仍需保留
常见误用：只配 system.BBR，结果大促时 CPU 已飙到 95%，QPS 却还在 180+，数据库连接池被打满。
真相：BBR 是基于响应时间 + 入口 QPS 计算的自适应模型，但它不感知下游瓶颈（如 DB 连接数、Redis 超时），也压不住突发毛刺流量。
-
system.InboundQPS+Strategy: system.BBR适合稳态长尾流量，但需配合固定阈值兜底 - 建议组合：先设
InboundQPS=200固定限流，再叠加system.CPU=75.0降级保护 - 并发数限流（
system.Concurrency）更适合慢接口，比如导出、批量写入，防 goroutine 泛滥
真正容易被忽略的是：Sentinel Go 的系统规则是“短路优先”逻辑——只要任意一项指标（Load/CPU/RT/Concurrency/QPS）触发，就立刻拒绝新请求，不等其他指标计算完。这意味着你配了 CPU=80 和 RT=500，实际生效的永远是先达到的那个。上线前务必用压测工具验证各指标真实触达顺序。
