sentinel-go 的限流和熔断必须分开配置、埋点，且熔断规则默认不生效——需显式调用 circuitbreaker.LoadRules；限流规则无效多因 flow.LoadRules 未在 sentinel.InitDefault() 后调用；Resource 名称须完全一致；熔断策略参数（如 MinRequestAmount、StatIntervalInMs）缺失会导致规则被跳过；Entry 后必须 defer e.Exit()，BlockError 时不可调用 Exit()；RetryTimeoutMs 单位为毫秒，慢调用阈值 MaxAllowedRtMs 需大于真实 P99 延迟。
直接说结论：sentinel-go 的限流和熔断必须分开配置、分开埋点，且熔断规则默认不生效——因为初始化后需显式加载 circuitbreaker.LoadRules，否则只跑限流逻辑。
限流规则加载后没效果？检查 flow.LoadRules 是否在 sentinel.InitDefault() 之后调用
常见错误是把 flow.LoadRules 放在 sentinel.InitDefault() 前，或漏掉这个调用。Sentinel Go 不会自动读取规则，所有规则都靠显式加载。
-
sentinel.InitDefault()只初始化运行时环境（日志、统计模块等），不加载任何规则 -
flow.LoadRules必须在初始化之后、业务请求开始前执行，否则所有Entry都走默认放行逻辑 - 规则中
Resource字符串必须和sentinel.Entry("xxx")中的完全一致（区分大小写） - 若使用
WithTrafficType(base.Inbound)，但规则里没指定TrafficType，默认按Outbound匹配，导致规则不生效
熔断器不触发？确认用了 circuitbreaker.LoadRules 而不是 flow.LoadRules
限流和熔断的规则类型不同，加载函数也不同。混用会导致熔断逻辑完全静默——既不拦截也不报错，就像没配一样。
- 限流规则用
flow.Rule+flow.LoadRules - 熔断规则必须用
circuitbreaker.Rule+circuitbreaker.LoadRules - 熔断策略有三种：
ErrorRatio（错误比例）、ErrorCount（错误计数）、SlowRequestRatio（慢调用比例），每种对参数要求不同 - 例如
ErrorRatio策略必须设置MinRequestAmount（最小请求数）和StatIntervalInMs（统计窗口），否则规则校验失败被跳过
埋点时 Entry 返回 BlockError 但没退出？必须手动调用 e.Exit() 或用 defer
sentinel.Entry 是一个资源守门员，它只管“放行”或“拦住”，不负责清理。如果放行后忘记 e.Exit()，统计指标会持续累积，导致后续误判（比如明明只调了 1 次，却显示 10 次通过）。
立即学习“go语言免费学习笔记（深入）”；
- 正确写法：用
defer e.Exit()包裹业务逻辑，确保无论是否 panic 都能退出 - 错误写法：只在 if/else 的 else 分支里写
e.Exit()，但业务逻辑里发生 panic 就漏掉了 - 如果
b != nil（即被限流或熔断），不能 调用e.Exit()，否则 panic -
WithAcquireCount会影响 token 计数，比如批量操作传WithAcquireCount(5)，就相当于一次消耗 5 个配额
熔断后恢复期行为异常？注意 RetryTimeoutMs 和状态机转换条件
熔断器不是“断开就永远断开”，它会在 RetryTimeoutMs 后进入半开状态，此时仅允许单个试探请求通过。但很多人忽略两个关键点：
- 半开状态下，如果试探请求成功（无 error、未超时），才真正关闭熔断；否则重置计时器，继续熔断
-
RetryTimeoutMs单位是毫秒，填60是 60ms，不是 60 秒——容易配成瞬间反复切换 - 慢调用判断依赖
MaxAllowedRtMs，该值必须大于你服务的真实 P99 延迟，否则正常波动也会触发熔断 - 错误统计基于
base.BlockError和 panic，但非base.BlockError的 error（如业务返回的errors.New("xxx")）不会计入熔断计数
最易被忽略的一点：熔断规则里的 StatIntervalInMs 和限流规则里的同名字段含义不同——前者是熔断统计窗口长度（如 60000 表示 1 分钟内统计错误率），后者是限流滑动窗口的刷新周期（如 1000 表示每秒更新一次 QPS）。两者数值常被误设为相同，但语义和影响完全不同。
