Gin 不提供并发请求数限制因其设计轻量，复用 net/http 的 goroutine 模型且无内置限流逻辑；可通过 http.Server 的 MaxConns/ConnState 做连接级限制，或用 semaphore 实现请求级限流，需注意 context 超时与 panic 恢复的协同。
为什么 Gin 本身不提供并发请求数限制
Gin 是一个轻量级 HTTP 路由框架，设计上刻意避免内置连接池、限流、熔断等中间件逻辑。它把 net/http 的 handler 做了封装，但底层仍直接复用 http.Server 的并发模型 —— 每个请求启动一个 goroutine，没有全局并发数闸门。所以你不会在 Gin 文档里找到类似 MaxConcurrentRequests 这样的配置项。
用 http.Server 的 MaxConns 和 ConnState 实现粗粒度限制
最接近“限制并发请求数”的原生方式，是控制底层 http.Server 的连接生命周期。注意：这不是请求级限流（QPS），而是 TCP 连接总数限制，对短连接场景效果有限，但能防止连接耗尽。
-
MaxConns：设置服务器允许的最大并发连接数（Go 1.19+ 才支持） -
ConnState回调：手动统计http.ConnState中的StateActive状态连接数，超限时主动关闭新连接 - ⚠️ 缺点：无法区分“正在处理的请求”和“空闲 keep-alive 连接”，容易误杀；且不感知路由或路径维度
示例片段：
var activeConns int64
srv := &http.Server{
Addr: ":8080",
Handler: r, // your gin.Engine
ConnState: func(conn net.Conn, state http.ConnState) {
switch state {
case http.StateActive:
atomic.AddInt64(&activeConns, 1)
case http.StateClosed, http.StateIdle, http.StateHijacked, http.StateNew:
atomic.AddInt64(&activeConns, -1)
}
},
}
// 启动前加个检查逻辑（需配合中间件或自定义 Listener）
用中间件 + semaphore 实现每路由/全局请求级并发控制
真正可控的方式是用信号量（semaphore）在请求进入时做计数控制。Gin 中推荐使用 golang.org/x/sync/semaphore，它比 channel 更轻量、无内存泄漏风险。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 全局限并发：在
r.Use()中注册中间件，用同一个*semaphore.Weighted - 按路由限并发：为不同
gin.RouterGroup创建独立 semaphore 实例 - 超时必须设：避免 goroutine 卡死，建议
ctx, cancel := context.WithTimeout(c.Request.Context(), 500*time.Millisecond) - 释放时机关键：务必在
defer cancel()或 handler 返回后调用sem.Release(1)，否则资源泄露
简例：
var globalSem = semaphore.NewWeighted(10) // 最多 10 个并发请求
func ConcurrencyLimit() gin.HandlerFunc {
return func(c *gin.Context) {
ctx := c.Request.Context()
if err := globalSem.Acquire(ctx, 1); err != nil {
c.AbortWithStatusJSON(http.StatusTooManyRequests, gin.H{"error": "too many requests"})
return
}
defer globalSem.Release(1)
c.Next()
}
}
r.Use(ConcurrencyLimit())
别忽略 context 超时与 panic 恢复的协同影响
限流中间件若没和 Gin 的 Recovery()、Timeout() 正确配合，会导致两种典型问题：
- panic 发生时
defer sem.Release(1)不执行 → semaphore 泄漏，很快锁死所有请求 - handler 内部用了
context.WithTimeout，但外层限流用的是另一个 context → 超时时间错位，实际并发数不可控 - 正确做法：限流中间件应放在
Recovery()之前，确保 panic 也能触发 defer；超时 context 应从c.Request.Context()派生，而非新建
尤其注意：Gin 默认不自动 cancel 请求 context，如果你在 handler 里启动 goroutine 并传入 c.Request.Context()，要确保它能被正常 cancel —— 否则 semaphore 释放延迟，看起来像“限流失效”。
