单机限流用令牌桶，跨服务限流必须用 sentinel；gin 中间件因无法跨实例同步状态，仅适用于单机场景，多副本部署时需依赖 sentinel-golang 实现集群级限流。
单机限流选令牌桶，跨服务限流必须用 Sentinel，别在 Gin 里自己手撸分布式限流逻辑。
为什么 Gin 自带中间件只适合单机令牌桶
Gin 的中间件天然运行在单个进程内，gin.Context 和内存变量（比如计数器、时间戳）无法跨实例同步。你写一个基于 time.Now() 和本地 count 变量的限流中间件，在单机压测时能跑通，但一上 K8s 多副本就彻底失效——每个 Pod 各自计数，实际 QPS 是配置值的 N 倍。
常见错误现象：429 Too Many Requests 出现频率远低于预期，或完全不触发；压测时流量轻松突破阈值，监控看到各实例请求数加起来远超设定值。
实操建议：
- 仅用于开发联调、单体服务、或明确单实例部署的边缘网关
- 速率和窗口必须硬编码，避免从配置动态加载（防止热更新时状态错乱）
- 不要在
count上加锁——Gin 的 goroutine 模型下，sync.Mutex会成为性能瓶颈；改用atomic.Int64+ 时间窗口重置更稳妥
sentinel-golang 是 Gin 微服务限流的事实标准
当你的 Gin 服务接入 Consul 或 Nacos 做服务发现，且部署 ≥2 个实例时，sentinel-golang 是唯一能开箱落地的方案。它不依赖外部存储，靠心跳+规则广播实现集群维度的系统级限流，比 Redis 计数器方案延迟低、故障面小。
关键参数差异：
-
system.InboundQPS：按入口总 QPS 限流，适合防刷、秒杀，但阈值需预估集群总容量 -
system.Concurrency：按活跃 goroutine 数限流，适合保护慢接口（如导出、报表），避免连接池耗尽 -
system.Load：直接读取/proc/loadavg，服务器负载高时自动收紧阈值，适合混合部署场景
容易踩的坑：sentinel.SentinelMiddleware 必须放在所有业务中间件之前，否则 ctx.Abort() 会被后续中间件覆盖；system.BBR 策略需要至少 10 秒冷启动期才能生效，压测前务必预热。
别把 Gin 当微服务框架用，限流只是治理链条的一环
Gin 本身不提供服务注册、熔断、链路追踪能力。你在 main.go 里塞了 sentinel 限流，但下游 MySQL 挂了，Gin 不会自动熔断——你得额外集成 gobreaker 或 go-zero 的熔断组件。
真实生产约束：
- 若微服务数 ≤5，Gin +
sentinel-golang+gobreaker+ Prometheus 手动埋点，是可控组合 - 若微服务数 ≥20，限流规则分散在各服务的
main.go里，运维成本爆炸；此时该切go-zero，用goctl统一生成带限流/熔断/监控的代码骨架 -
sentinel-golang的system.CPU和system.Memory策略在容器环境下不准，因 cgroup 限制导致读数失真，优先用system.Load或system.InboundQPS
复杂点在于：限流策略不是静态配置，而是要随服务拓扑变化联动调整。比如一个 Gin 网关后面挂了 3 个模型服务，其中一个升级后吞吐翻倍，你不能只改那个服务的限流阈值——网关层的并发控制、下游的连接池大小、甚至 Kubernetes 的 HPA 触发条件，都得同步校准。这事没法靠单个中间件解决。
