断路器是带超时、计数、重试逻辑的状态机，关键在half-open状态的合理进入（如5次连续超时）与退出（限流探针1–2个），需避免GC延迟导致超时不准、资源争用引发CPU飙升、context与断路器超时不一致、本地规则未加载等隐性失效。
Go 微服务里断路器状态怎么切换才不误判
断路器不是开关，是带超时、计数、重试逻辑的状态机。常见误判是把瞬时网络抖动当成服务永久失败，直接熔断——结果健康请求全被拦在门外。
关键不在“开”或“关”，而在 half-open 状态的进入和退出条件是否合理：
-
failureThreshold要结合接口 SLA 设：比如 P99 延迟 200ms 的接口，设 5 次连续超时（timeout > 300ms）才进open，比固定 3 次更稳 - 进
half-open后必须限制探针请求数（如只放行 1–2 个），不能一开就 flood；Sentinel 的statIntervalMs和retryTimeoutMs配合不好，会导致反复震荡 - Go 原生
time.AfterFunc做状态超时不可靠——GC 或调度延迟可能让open → half-open晚几秒触发，建议用time.NewTimer并显式Reset
Sentinel Go 版 CPU 占用突增的三个诱因
不是 Sentinel 本身慢，而是默认配置和 Go runtime 特性叠加后，在高并发下暴露资源争用问题。
典型现象：CPU 使用率从 15% 跳到 90%，goroutine 数暴涨，但 QPS 没涨甚至下降。
立即学习“go语言免费学习笔记（深入）”；
- 指标滑动窗口用
array实现，但默认bucketCount = 10、intervalSec = 1，每秒新建 10 个 bucket 对象——高频调用下 GC 压力陡增；改成bucketCount = 2+intervalSec = 5可降 60% 分配量 -
ResourceName若含动态参数（如/user/{id}），默认开启hotspot统计，会为每个id单独建 slot，内存和锁竞争双爆；应提前聚合或关掉hotspot - 日志级别设为
debug且未限流时，sentinel-core内部每毫秒打一条entry exit日志，I/O 直接拖垮吞吐；生产必须设info或更低
Go context 与断路器超时怎么对齐才不漏杀
断路器判断超时，和 context.WithTimeout 的超时，是两套独立逻辑。不对齐就会出现：断路器放行了，但下游已因 context cancel 返回 error。
根本问题是时间基准不一致——断路器看的是 time.Since(start)，而 context.Deadline() 可能被父 context 缩短。
- 别在
entry前才建 context；应在调用前统一生成，把context.Deadline()传给断路器做maxAllowedDuration - Sentinel Go 的
entry不接受外部 deadline，得自己 wrap：先ctx, cancel := context.WithTimeout(parentCtx, 800*time.Millisecond)，再检查ctx.Err() == nil才进entry - HTTP 客户端超时（
http.Client.Timeout）要略短于断路器statInterval，否则断路器还没统计完，连接已断，导致失败计数失真
本地调试时断路器永远不熔断的隐藏配置
不是代码写错了，是 Sentinel 默认关闭了运行时规则加载，本地跑单元测试或 go run 时，flowRule 和 degradeRule 根本没生效。
现象：mock 失败返回 后，entry.BlockError() 始终为 nil，GetStatus() 一直显示 closed。
- 必须显式调用
sentinel.InitWithConfig(&sentinel.Config{LogDir: "/tmp/sentinel-log"})，否则日志和规则引擎不启动 - 规则需用
flow.LoadRules或degrade.LoadRules主动加载，不会自动扫描文件；本地调试建议用flow.NewFlowRule构造后LoadRules([]flow.Rule{rule}) - Go test 环境中，
init()函数若依赖全局变量（如未初始化的sentinel实例），会静默失败；加一行require.NoError(t, sentinel.InitWithConfig(...))再测
断路器真正的复杂点不在状态流转图，而在它和 Go 的 goroutine 生命周期、context 传播、GC 行为三者交织时，那些不报错但悄悄失效的边界。
