热点参数限流与全局限流维度不同，前者针对特定参数值独立限流，需解决参数提取与海量值计数问题；sentinel go 通过 paramflowslot 实现，要求显式配置 paramindex/paramkey、metrictype 和 controlbehavior，并注意 burstcount 与 durationinsec 的合理组合。
热点参数限流不是全局限流的“升级版”，而是完全不同的统计维度
全局限流盯的是 resource 总 QPS，而热点参数限流盯的是「某个参数值」在该 resource 下的独立访问频次。比如 getProduct 接口被调用 1000 次/秒，其中 900 次带的是 productId=1001，剩下 100 次分散在其他 ID 上——全局限流可能放行全部，但热点限流会直接对 1001 这个值触发拒绝。
这决定了它必须解决两个底层问题：一是如何从任意结构的入参中稳定提取目标值；二是如何为海量动态参数值（比如千万级用户 ID）做轻量、线程安全的高频计数。Sentinel Go 的 ParamFlowSlot 就是为此设计的，它不依赖全局 Node 树，而是用 ParameterMetricStorage + ConcurrentHashMap 管理每个资源下的参数指标映射。
- 如果你用
@SentinelResource注解但没配ParamIndex或ParamKey，限流规则根本不会生效——它连参数都找不到 - 参数类型必须是基础类型（
int,string,int64等）或实现了ParamFlowArgument接口的对象，否则提取失败且静默跳过 -
ParamIndex是位置索引（从 0 开始），ParamKey是 map 或 struct 字段名；两者互斥，优先用ParamKey更健壮，避免因参数顺序调整导致规则失效
配置规则时必须显式指定 MetricType 和 ControlBehavior
Sentinel Go 的热点参数规则强制要求设置 MetricType（QPS 或 Concurrency）和 ControlBehavior（Reject 或 Throttling）。漏掉任一字段，hotspot.LoadRules 会返回错误，且不会 fallback 到默认值。
常见错误是把 ControlBehavior 设成 Throttling 却没设 MaxQueueingTimeMs，结果请求永远卡在排队队列里；或者用 Concurrency 模式却误设了 Threshold 为每秒请求数，实际限制的是并发 goroutine 数。
-
QPS模式下：Threshold表示该参数值在DurationInSec秒窗口内的最大允许请求数，超出即拒 -
Concurrency模式下：Threshold表示该参数值当前最多允许多少个请求同时执行，适合防慢 SQL 或阻塞 IO -
Throttling行为需配合MaxQueueingTimeMs使用，否则排队无限期等待；建议设为 50–200ms，超过则直接拒绝
自定义参数提取：当入参是 struct 或 map 时必须实现 ParamFlowArgument
如果方法签名是 func getOrder(req OrderRequest)，而你想限流 req.UserID，仅靠 ParamIndex=0 拿不到值——因为 OrderRequest 是一个 struct，Sentinel 默认无法反射取字段。
此时必须让 OrderRequest 实现 ParamFlowArgument 接口：
type OrderRequest struct {
UserID int64 `json:"user_id"`
ProductID string `json:"product_id"`
}
<p>func (r OrderRequest) ParamFlowKey() interface{} {
return r.UserID
}</p>
注意：ParamFlowKey() 返回值必须是可哈希类型（string, int, int64 等），不能返回指针或 slice；若返回 nil，该次调用会被忽略，不参与热点统计。
- 不要在
ParamFlowKey()里做耗时操作（如 DB 查询、HTTP 调用），它在每次 entry 时同步执行 - 如果 struct 字段可能为空（如
UserID=0），需提前判断并返回有意义的默认值，否则所有0值会聚合成一个热点桶，造成误限 - map 类型参数同理，需额外包装一层实现接口，不能直接传
map[string]interface{}
生产环境必须关注 BurstCount 和 DurationInSec 的组合影响
BurstCount 只在 MetricType=QPS 且 ControlBehavior=Reject 时生效，它不是“突发容量”，而是令牌桶的“瞬时爆发上限”。例如 Threshold=10、BurstCount=3、DurationInSec=1，表示每秒最多放行 13 个请求（10 个匀速 + 3 个突发），之后立即触发限流。
这个参数极易被误解为“允许短时间冲高”，但它实际加剧了毛刺风险：如果下游服务响应变慢，请求堆积，BurstCount 会加速耗尽令牌，导致更早触发拒绝。线上建议保守设置，BurstCount ≤ Threshold * 0.2，且 DurationInSec 必须与业务 SLA 匹配——秒级统计窗口不适合防秒杀，毫秒级又太敏感。
-
DurationInSec最小支持 1 秒，不支持 sub-second 精度；想控 100ms 级别需改用Concurrency模式 - 同一资源下不同参数值共享同一个
DurationInSec计数窗口，但各自独立计数，不存在“全局滑动窗口”概念 - 监控时重点看
hotspot_metric_qps指标中的param_value标签，而不是总 QPS；异常值会快速浮现在 Prometheus 的 topK 查询里
真正难的不是配置规则，是预判哪些参数值会在什么时间点成为热点——它依赖实时指标反馈闭环，而不是静态阈值堆砌。上线后头三天务必打开 Sentinel 控制台的热点参数监控页，盯着 topN 参数值的 QPS 曲线，手动调优 Threshold，否则规则只是个摆设。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
