Sentinel Go 能防雪崩，但埋点错、规则配错、调用位置错会导致失效；Entry/Exit 必须在主 goroutine 严格配对，e.Exit() 需判空 defer，resourceName 统一为 "default" 并显式传 Inbound，系统规则仅启动时加载一次，熔断阈值需合理设置。
直接说结论：Sentinel Go 能防雪崩，但埋点错、规则配错、调用位置错，就等于没装——90% 的失效案例都卡在这三处。
Entry/Exit 必须在主 goroutine 且严格配对
埋点不在主 goroutine，统计就全乱套；e.Exit() 没判空就 defer，一 panic 就 crash。这不是“建议”，是硬约束。
-
sentinel.Entry()必须在 Gin 的 handler 函数里直接调用，不能丢进go func()或协程池里 -
e可能为nil（比如规则没加载完、初始化失败），必须写成：if e != nil { defer e.Exit() } - 绝对不能在
recover()里补e.Exit()——panic 后 goroutine 已终止，上下文丢了，统计失效 - 资源名统一用
"GET:/api/order"这类格式，大小写、空格、斜杠方向都要一致，否则规则不匹配
系统自适应保护必须设 resourceName = "default" 且传 Inbound
系统级保护不是保某个接口，而是拦住所有入口流量。设错 resource 名或漏传流量类型，规则就形同虚设。
- 规则里
resourceName必须是字符串"default"，写成"system"或留空都不生效 - 埋点时必须显式传
sentinel.WithTrafficType(base.Inbound)，否则指标不计入系统维度 -
system.LoadRules()只能在服务启动早期调一次，不能放在 handler 里反复调——会锁死规则引擎 - 推荐先用
system.CPU或system.RT开始试，system.Load在容器环境可能不准
熔断阈值和窗口设置不当反而加剧雪崩
太敏感的熔断比不熔断还危险：客户端密集重试 → 下游压力翻倍 → 更快崩溃。
立即学习“go语言免费学习笔记（深入）”；
-
MinRequestAmount至少设为20，否则滑动窗口内请求数太少，错误率抖动剧烈 -
SlowRatioThreshold推荐0.3～0.5，配合StatIntervalInMs: 60000（1 分钟窗口）更稳 -
SlowCallDurationInMs应略高于接口 P90 RT（例如 P90 是 300ms，设为400），不是拍脑袋填100 - 优先选
flow.Reject（立刻拒绝），慎用flow.Throttling（排队等待）——后者积压请求容易压垮下游
最常被忽略的点：Sentinel 的统计依赖 goroutine 生命周期，而 Go 的中间件执行顺序、defer 执行时机、panic 恢复路径，都会悄悄破坏这个前提。上线前务必用真实压测流量验证 sentinel.GetSph().GetMetrics() 返回的指标是否与预期一致，别只看控制台有没有报错。
