Sentinel Go系统保护规则必须显式调用system.LoadRules加载才生效，否则即使CPU达99%也不会触发保护；其支持CPUUsage、Load（仅Linux）、AvgRt、Qps、Concurrent五种策略，任一满足即限流，且依赖资源埋点统计。
Go 服务上线后突然被刷接口，CPU 拉满、数据库连接耗尽——这不是偶然，而是没配对 flow.Rule 的典型后果。Sentinel Go 的系统保护阈值不是“开箱即用”，必须显式配置 system.LoadRules 才生效，否则只靠默认的 CPU 阈值（80%）根本挡不住真实攻击流量。
system.LoadRules 必须手动调用，不调用等于没配
很多人以为初始化 sentinel.InitDefault() 后系统保护就自动启用了，其实只是加载了基础模块，system 规则默认为空。不调用 system.LoadRules，哪怕 CPU 到 99%，也不会触发任何保护动作。
-
system.LoadRules是唯一入口，必须在规则加载阶段（如 init 函数或服务启动早期）执行 - 规则结构体中
SystemRule的Strategy字段决定触发依据：支持CPUUsage、Load（Linux only）、AvgRt、Qps、Concurrent五种策略，不能混用 - 若同时配置多个策略，Sentinel 会取最严格的那个生效（例如 CPU > 70% 且 QPS > 1000 时，任一满足即触发）
- 示例中常见错误是把
system.LoadRules放在 HTTP handler 里——规则只会加载一次，放错位置会导致永远不生效
CPUUsage 和 Load 策略在不同系统行为差异大
CPUUsage 在所有平台可用，但 Load（系统平均负载）仅 Linux 生效，Windows/macOS 下会静默忽略该规则项。生产环境若跨平台部署，务必检查 Strategy 值是否被实际识别。
- Linux 上
Load对应/proc/loadavg的 1 分钟均值，建议阈值设为 CPU 核数 × 1.5～2.0；过高易失效，过低会误熔断 -
CPUUsage统计基于runtime.ReadMemStats+os.CpuCount推算，实测延迟约 2～3 秒，不适合秒级突增场景 - 两者不可叠加为“或”逻辑：Sentinel 不支持
Strategy: CPUUsage | Load这种写法，只能分别建两条规则 - 测试时用
stress-ng --cpu 4 --timeout 30s模拟负载，比单纯跑 for 循环更贴近真实压测
Qps 和 Concurrent 阈值必须配合资源埋点才有效
SystemRule 中的 Qps 和 Concurrent 并非全局总 QPS，而是指「当前节点上所有通过 sentinel.Entry 埋点的资源」的聚合统计值。没埋点的 goroutine 或直连 DB 的调用完全不计入。
立即学习“go语言免费学习笔记（深入）”；
- 必须确保关键路径（如 HTTP handler、RPC 方法）都包裹了
sentinel.Entry("resource-name")，否则系统规则看到的 QPS 永远是 0 -
Concurrent统计的是并发执行中的Entry数量，不是 goroutine 总数；若业务用了长连接或协程池，需额外评估 buffer 容量 - 阈值设置要留余量：比如压测峰值 QPS 是 800，系统规则建议设 1000，避免因统计抖动误触发
- 注意
system规则和flow规则的优先级：系统规则是兜底，一旦触发会直接拒绝所有新Entry请求，不管单资源限流是否还有余量
最容易被忽略的一点：系统保护规则没有“预热期”概念，WarmUp 仅适用于 flow.Rule。只要指标一超阈值，立刻生效——所以压测前务必确认 system.LoadRules 已加载且阈值合理，否则第一次真实流量进来就可能直接雪崩。
