system.loadrules必须手动调用才生效，否则即使cpu达99%也不触发保护；需在服务启动早期加载，规则metrictype支持cpuusage、load（仅linux）、avgrt、qps、concurrent五种策略，任一满足即触发，且埋点必须使用"default"资源名和inbound方向。
system.LoadRules 必须手动调用，否则规则永不生效
初始化 sentinel.InitDefault() 只加载基础模块，system 规则默认为空数组。哪怕 CPU 使用率飙到 99%，只要没调 system.LoadRules()，系统保护就形同虚设。
常见错误是把规则加载写在 HTTP handler 或某个业务函数里——规则只执行一次，且时机错乱，导致后续所有请求都看不到保护逻辑。
- 必须放在服务启动早期，比如
init()函数、main()开头或配置加载完成后的固定入口 - 规则结构体需完整定义
MetricType和TriggerCount，不能只填一半 - 加载失败时
system.LoadRules()返回 error，建议 log 打印并 panic，避免静默失效
resourceName 必须设为 "default"，且埋点要传 Inbound
系统自适应保护是全局维度的，不是针对某个接口。如果埋点时用了 "GET:/api/order" 这类具体资源名，system 规则根本不会匹配——它只认 "default"。
同时，埋点必须显式声明流量方向：sentinel.Entry("default", sentinel.WithTrafficType(base.Inbound))。漏掉 WithTrafficType 或传了 base.Outbound，指标就不会计入系统维度统计。
- HTTP handler 入口统一用
"default"，别按路径拼接；RPC provider 同理 -
e := sentinel.Entry("default", sentinel.WithTrafficType(base.Inbound))后必须判空再 defere.Exit() - recover() 里补
e.Exit()无效：panic 时 goroutine 已中断，上下文已丢失
CPUUsage 和 Load 策略在不同系统行为不一致
system.LoadRules 支持五种 MetricType：CPUUsage、Load（仅 Linux）、AvgRt、Qps、Concurrent。但它们不是“或”关系，而是取最先满足的那一个触发；且跨平台表现差异大。
比如在 macOS 或 Windows 上配置 MetricType: system.Load，该规则会被静默忽略；而 CPUUsage 虽全平台可用，但采样延迟约 2～3 秒，对秒级突增来不及响应。
- 生产环境跨平台部署时，务必用
runtime.GOOS做条件判断，避免规则失效 - Linux 生产机可优先用
system.Load（对应 load1），比 CPU 更早反映过载趋势 -
system.Qps和system.Concurrent依赖埋点统计，没包sentinel.Entry的 goroutine 不计入
阈值设太小会引发误熔断，MinRequestAmount 至少 20
系统规则不是越敏感越好。比如 SlowRatioThreshold: 0.1 + MinRequestAmount: 5，滑动窗口内只要 5 次请求里有 1 次慢，就立刻熔断——真实业务中 P95 RT 波动很常见，这会导致频繁抖动甚至雪崩。
MinRequestAmount 是滑动窗口最小请求数门槛，低于它不计算错误率；StatIntervalInMs 决定窗口长度，默认 1000ms 太短，建议设为 60000（1 分钟）更稳。
-
MinRequestAmount至少设为 20，确保统计有足够样本 -
SlowRatioThreshold推荐 0.3～0.5，配合StatIntervalInMs: 60000 -
SlowCallDurationInMs应略高于接口 P90 RT（例如 P90 是 300ms，设为 400），不是拍脑袋填 100
system.LoadRules() 是否真被执行、以及阈值是否贴合压测结果——漏掉任意一环，系统过载时就只能靠重启硬扛。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
