热点参数限流与普通QPS限流本质区别在于统计维度：前者针对特定参数值（如id=1001）独立限流，后者仅统计接口总QPS；Sentinel热点限流依赖参数索引位置、只支持基本类型，需显式传参且类型严格匹配，否则规则失效。
热点参数限流和普通QPS限流有什么本质区别
普通QPS限流只看接口总调用量，而热点限流关注「某个参数值是否高频」。比如 /user/{id} 接口，id=1001 被刷了1000次/秒，其他 id 都正常，这时普通限流拦不住，必须靠热点规则识别出 id=1001 是异常热点。
Sentinel 的热点限流依赖参数索引位置（不是参数名），且只支持基本类型（int、string、long 等）。如果你用 struct 传参或 map，Sentinel 拿不到具体值，规则会失效。
- Go SDK 中需显式调用
sentinel.Entry并传入WithResourceArgs，否则参数不会被提取 - 规则配置里指定的「参数索引」从 0 开始，比如
HandleUser(int64, string)，第一个int64是索引 0，string是索引 1 - 默认只统计最近 60 秒的访问频次，窗口大小不可改（Go 版暂不支持自定义滑动窗口）
如何在 Gin 路由中正确提取并传递热点参数
Gin 的 c.Param("id") 或 c.Query("uid") 返回的是字符串，但 Sentinel 热点规则要求类型匹配。如果后端函数签名是 func(id int64)，你传 "123" 进去，Sentinel 会因类型不匹配跳过该参数，导致规则不生效。
正确做法是：先做类型转换，再把转换后的值作为 WithResourceArgs 传给 sentinel.Entry。
立即学习“go语言免费学习笔记（深入）”；
func handleUser(c *gin.Context) {
uidStr := c.Param("uid")
uid, err := strconv.ParseInt(uidStr, 10, 64)
if err != nil {
c.AbortWithStatus(400)
return
}
// 注意：args 必须按函数参数顺序传，且类型严格匹配
e, err := sentinel.Entry("GET:/api/user/:uid", sentinel.WithResourceArgs(uid))
if err != nil {
c.AbortWithStatus(429)
return
}
defer e.Exit()
c.JSON(200, map[string]interface{}{"uid": uid})
}
- 不要传
uidStr，必须传uid（int64类型） -
WithResourceArgs只接受扁平参数列表，不支持嵌套结构体或 map - 如果路由有多个动态段（如
/order/:uid/:oid），要按顺序传两个参数：sentinel.WithResourceArgs(uid, oid)
为什么热点规则没生效？常见断点排查路径
最常遇到的现象是：规则已加载，但 sentinel.GetNode 查不到热点统计，或者 flow.RuleManager.LoadRules 后始终 fallback 到默认 QPS 限流。
- 检查
sentinel.Init是否早于所有路由注册——否则中间件无法拦截 - 确认
Entry的 resource 名和规则中配置的完全一致（包括大小写、斜杠、冒号位置） - 用
sentinel.GetNode("GET:/api/user/:uid").CurHotParams()手动查当前热点参数缓存，返回空说明参数没被识别 - Go 版 Sentinel 默认只支持最多 1000 个不同参数值（
hotParamCapacity），超出后老值会被淘汰，不是 bug 是设计限制 - 日志级别设为
debug，搜索"hot parameter not matched"或"no hot parameter extractor"错误
生产环境部署时容易忽略的资源隔离问题
同一个微服务里多个接口共用一个热点规则名（比如都叫 GET:/api/user/:uid），但参数提取逻辑不同（有的取 path，有的取 query），会导致统计混乱。Sentinel 不区分来源，只认 resource 名 + 参数位置。
更隐蔽的问题是：HTTP 和 gRPC 接口如果用了相同 resource 名，但参数结构不同，热点统计会互相污染。
- 建议 resource 名带上协议和语义前缀，例如
HTTP-GET-/api/user/:uid、GRPC-GetUser - 避免复用已有 resource 名添加新热点规则——旧规则还在内存里，新规则可能被忽略
- 热参数阈值（
burstCount）不能设得太低（如 1），Go runtime 的调度抖动可能导致误触发；建议不低于 5 - 本地测试时用
sentinel.Reset清理全局状态，否则历史规则残留会影响新配置
热点限流真正起作用的前提，不是规则配得有多细，而是参数提取路径是否干净、类型是否稳定、resource 命名是否无歧义——这三个点漏掉任何一个，规则就形同虚设。
