熔断保护不是开关，而是Closed→Open→HalfOpen三态状态机，需按接口SLA设定ReadyToTrip条件、超时时间及探测逻辑。
熔断保护不是开关，是带超时和探测逻辑的状态机
Go 微服务里的熔断不是“一断了之”，而是 Closed → Open → HalfOpen 的三态切换过程。关键不在状态本身，而在状态切换的条件是否贴合真实接口 SLA。比如一个 P99 RT 是 200ms 的接口，设“3 次连续超时就熔断”极易误判网络抖动；更稳的做法是设 ReadyToTrip 为“5 次连续 timeout > 300ms”，且 Timeout（Open 持续时间）要略大于下游恢复预期——太短会反复震荡，太长则降级时间过久。
Sentinel Go 熔断规则必须传 base.Inbound 才生效
系统级熔断只对入口流量起作用，且规则 resourceName 必须固定为 "default"。如果埋点时漏传 sentinel.WithTrafficType(base.Inbound)，指标就不会计入系统维度统计，哪怕规则加载成功也完全不触发。
- 错误写法：
sentinel.Entry("GET:/api/order")→ 只用于单接口流控，不参与系统熔断 - 正确写法：
sentinel.Entry("default", sentinel.WithTrafficType(base.Inbound))→ 触发系统级 CPU/Load/RT 自适应保护 - 规则加载必须在启动早期完成，不能每次请求都调
system.LoadRules()，否则规则引擎会被锁死
flow.Reject 和 flow.Throttling 的选型直接影响重试风暴
两者都基于滑动窗口统计，但行为差异极大：flow.Reject 超阈值立刻返回 TokenResult{Blocked: true}，适合支付类强实时接口；flow.Throttling 则把请求排队等待，最大等待时间由 MaxQueueingTimeMs 控制——若客户端无退避逻辑，排队请求会在窗口结束时集中涌出，反而加剧下游压力。
在 Golang 中使用 samber/hot 进行内存缓存，支持 LRU、LFU、TinyLFU、W‑TinyLFU、S3FIFO、ARC、TwoQueue、SIEVE、FIFO 等淘汰算法，提供 TTL、缓存加载器及分片功能。
- 慎用
flow.Throttling配合短StatIntervalInMs（如 100ms），易造成请求堆积后突发释放 -
SlowCallDurationInMs应设为接口 P90 RT + 100ms 左右，而不是拍脑袋填 100 或 200 -
MinRequestAmount至少设为 20，否则滑动窗口内请求数太少，错误率抖动剧烈，熔断容易误触发
Entry/Exit 必须严格配对且在主 goroutine 中
这是 Sentinel Go 失效最常见原因。Entry 返回的 e 可能为 nil（规则未加载、初始化失败等），直接 defer e.Exit() 会 panic；而跨协程调用 Entry 或在 recover 后补 Exit，会导致统计上下文丢失，流控/熔断完全失效。
立即学习“go语言免费学习笔记（深入）”；
- 必须在 Gin/Echo 的 handler 主 goroutine 中调用
sentinel.Entry -
defer前必须判空：if e != nil { defer e.Exit() } - 绝对不要把 Entry 丢进
go func() {}()，也不要在recover()里尝试补 Exit - 资源名统一用
"GET:/api/order"这类格式，避免字符串散落导致规则匹配失败
context 超时与断路器超时的对齐问题：HTTP 客户端的 Timeout 要略短于 Sentinel 的 statIntervalMs，否则断路器还没统计完，请求已因 context cancel 失败——这时熔断器认为“请求失败”，但真实原因是上游主动中断，不是下游故障。 
