Sentinel Go 能用但极易失效：资源埋点须在主 goroutine 且 Entry/Exit 严格配对，e 为 nil 时 defer Exit 会 panic；系统规则只认 "default"，需显式设 Inbound 类型；熔断参数需科学配置，初始化必须早于埋点调用。
直接说结论：Sentinel Go 能用，但埋点错一次、配对漏一回、规则加载晚一秒，就等于没加——统计失真、流控失效、熔断误判是常态，不是例外。
资源埋点必须在主 goroutine 且 Entry/Exit 严格配对
这是 Sentinel Go 失效的头号原因。Entry() 返回的 e 可能为 nil（比如规则未加载、初始化失败），而 defer e.Exit() 会直接 panic；更危险的是，把 Entry() 丢进 go func() 里执行，会导致上下文丢失、指标归零。
- 必须在 HTTP handler 或业务入口的主 goroutine 中调用
sentinel.Entry() -
defer前务必判空：if e != nil { defer e.Exit() } - 不能在
recover()后补e.Exit()——panic 时 goroutine 已终止，统计链路已断裂 - 资源名建议统一格式，如
"GET:/api/order"或"POST:/api/payment"，避免字符串散落
系统规则只对 Inbound 流量生效，且 resource name 必须是 "default"
系统级保护（CPU、Load、RT、QPS）不是针对某个接口，而是全局入口维度的兜底。它不会识别你自定义的 "GET:/api/user"，只认 "default" 这个固定名字。
- 埋点时必须显式传
sentinel.WithTrafficType(base.Inbound)，否则指标不计入系统维度 - 规则加载示例：
system.LoadRules([]*system.SystemRule{{MetricType: system.Load, TriggerCount: 8.0}}) - 同一时间只生效一种指标（取最先满足的），不要同时设 CPU 和 Load 规则
- 规则必须在服务启动早期完成加载，不能每次请求都调
system.LoadRules()——会锁死规则引擎
熔断阈值设太小 = 自己制造雪崩
真实服务中，SlowRatioThreshold 和 MinRequestAmount 是最容易拍脑袋填错的两个参数。设低了，P90 RT 正常波动就被熔；设高了，故障已蔓延却毫无反应。
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
立即学习“go语言免费学习笔记（深入）”；
-
MinRequestAmount至少为20，否则滑动窗口内请求数太少，错误率抖动剧烈 -
SlowRatioThreshold推荐0.3～0.5，配合StatIntervalInMs: 60000（1 分钟窗口）更稳 -
SlowCallDurationInMs应略高于接口 P90 RT（例如 P90 是 300ms，设为400），不是填100或500 - 熔断规则加载后不会自动生效，需确认
sentinel.InitDefault()已成功调用且无 error
flow.Reject 和 flow.Throttling 的行为差异影响重试风暴
两者都基于滑动窗口统计，但响应时机和方式不同，选错会把下游压得更死。
-
flow.Reject：超阈值立刻返回TokenResult{Blocked: true}，适合支付类强实时接口，但客户端若无退避逻辑，会立即重试 → 放大流量压力 -
flow.Throttling：允许部分请求通过，其余匀速放行，适合读多写少、可容忍延迟的场景，天然抑制重试风暴 - 别在中间件里每次请求都调
flow.LoadRules()，应预加载 + 热更新机制
最常被忽略的其实是初始化顺序：Sentinel Go 不是“引入依赖+加中间件”就完事，sentinel.InitDefault() 必须早于任何 Entry() 调用，且要检查返回 error；否则所有埋点静默失效，连日志都不会报——你以为加了防护，其实裸奔。
