资源埋点必须放在主goroutine且entry/exit严格配对，否则统计失真、流控失效；entry须在主goroutine调用，不可跨协程，defer前须判空e，resourcename统一为"get:/api/order"格式，系统规则 resourcename 必须设为"default"并传inbound类型。
资源埋点必须放在主 goroutine，且 Entry/Exit 严格配对
埋点位置错、配对漏，是 Sentinel Go 失效的最常见原因。Entry() 必须在处理请求的主 goroutine 中调用，不能丢进 go func() 里；e.Exit() 必须通过 defer 确保执行，且调用前要判空。
-
Entry()返回的e可能为nil（比如规则未加载或初始化失败），直接defer e.Exit()会 panic - Gin 中间件示例：入口处调用
sentinel.Entry(resourceName, sentinel.WithTrafficType(base.Inbound))，resourceName建议统一为"GET:/api/order"这类格式，避免字符串散落 - 不能在
recover()后补e.Exit()—— panic 发生时 goroutine 已中断，统计上下文已丢失
系统自适应规则只对 Inbound 流量生效，且必须设为"default"
系统级保护不是针对某个接口，而是全局维度的入口流量控制。规则里的 resourceName 必须设为 "default"，否则不会触发；同时确保埋点时传了 sentinel.WithTrafficType(base.Inbound)，否则指标不计入系统维度统计。
- 有效配置示例：
system.LoadRules([]*system.SystemRule{{ MetricType: system.Load, TriggerCount: 8.0, }}) - 支持的
MetricType包括system.Load、system.CPU、system.RT、system.Concurrency和system.QPS，但同一时间只生效一种（取最先满足的） - 规则加载必须在服务启动早期完成，不能每次请求都调
system.LoadRules()—— 会锁死规则引擎
SlowRatioThreshold 和 MinRequestAmount 设太小会导致频繁误熔断
熔断不是越敏感越好。阈值设得过低、统计窗口太小，会让正常波动被当成故障，反而加剧雪崩。
-
MinRequestAmount至少设为20，否则滑动窗口内请求数太少，错误率抖动剧烈 -
SlowRatioThreshold推荐0.3～0.5，配合StatIntervalInMs: 60000（1 分钟窗口）更稳 -
SlowCallDurationInMs应略高于接口 P90 RT（例如 P90 是 300ms，设为400），而不是拍脑袋填100
flow.Reject 和 flow.Throttling 的行为差异直接影响重试风暴风险
两者都基于滑动窗口统计，但拒绝时机和响应方式不同，选错会放大下游压力。
-
flow.Reject：超阈值立刻返回TokenResult{Blocked: true}，适合支付类强实时接口，但客户端若无退避逻辑，容易密集重试 -
flow.Throttling：允许请求排队等待，实际是“削峰填谷”，适合后台任务类接口，但需注意队列积压导致延迟升高 - 系统自适应保护底层用的是
flow.Reject模式，所以它触发时是硬拒绝，不是限速
system.CPU 的规则就形同虚设。这时候得切到 system.RT 或 system.Concurrency，而不是硬调 CPU 阈值。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
