iris 框架不支持开箱即用的每 ip 并发请求数限制，因其 http.handler 与连接状态解耦，需自研中间件配合 sync.map 和原子操作实现精确计数，注意真实 ip 提取、端口剥离、类型断言及增减配对。
Iris 框架本身不提供开箱即用的「每 IP 并发请求数」限制能力，因为它的 http.Handler 生命周期与连接状态解耦，无法在连接建立瞬间拦截和计数——必须自己实现中间件 + 状态管理，且关键逻辑要放在请求进入和退出时精确配对增减。
为什么不能直接用 iris.LimitRequestBody 或 iris.TrafficShaper
iris.LimitRequestBody 或 iris.TrafficShaper
iris.LimitRequestBody 只控单次请求体大小；iris.TrafficShaper 是基于时间窗口的速率限流（类似 rate.Limiter），它统计的是「单位时间请求数」，不是「当前活跃并发数」。两者都做不到：某个 IP 正在同时发起 8 个未结束的 HTTP 请求时实时拒绝第 9 个。
用 sync.Map + 中间件做每 IP 并发计数
sync.Map + 中间件做每 IP 并发计数这是最常用、可控、无外部依赖的做法，但要注意几个硬性条件：
- 真实 IP 必须从
X-Forwarded-For提取（若部署在 Nginx / CDN 后），否则拿到的是代理地址；需校验可信代理网段，避免头伪造 -
r.RemoteAddr带端口（如"192.168.1.100:54321"），IPv6 还带方括号（如"[2001:db8::1]:8080"），提取 IP 时得先切掉端口：strings.Split(r.RemoteAddr, ":")[0]不可靠，推荐用net.ParseIP+ip.To4()归一化 - 计数必须严格配对：
atomic.AddInt32(..., 1)在中间件开头，defer atomic.AddInt32(..., -1)在结尾；否则 panic 或计数泄漏 -
sync.Map的LoadOrStore返回的是interface{}，必须类型断言为*int32，否则运行时报 panic
示例中间件片段：
func IPConcurrentLimit(max int) iris.Handler {
ips := sync.Map{} // key: ip string, value: *int32
return func(ctx iris.Context) {
ip := realIP(ctx.Request()) // 自行实现，含 XFF 解析和可信校验
countPtr, _ := ips.LoadOrStore(ip, new(int32))
count := atomic.AddInt32(countPtr.(*int32), 1)
if count > max {
atomic.AddInt32(countPtr.(*int32), -1)
ctx.StatusCode(http.StatusTooManyRequests)
ctx.Header("Retry-After", "60")
return
}
defer func() {
atomic.AddInt32(countPtr.(*int32), -1)
if atomic.LoadInt32(countPtr.(*int32)) <hr><h3><h3>为什么不用 <code>http.Server.ConnState</code> 钩子</h3></h3><p>有人想复用 Go 标准库的 <code>ConnState</code> 回调来统计连接数，但它有根本缺陷：</p><div class="aritcle_card flexRow artxards">
<div class="artcardd flexRow">
<a class="aritcle_card_img" rel="nofollow" href="/xiazai/gongju/2762" title="Iris框架 12.2.5"><img
src="https://img.php.cn/upload/manual/001/589/237/6aa35e21a9024187.png" alt="Iris框架 12.2.5" onerror="this.onerror='';this.src='/static/lhimages/moren/morentu.png'" ></a>
<div class="aritcle_card_info flexColumn">
<a rel="nofollow" href="/xiazai/gongju/2762" title="Iris框架 12.2.5" class="overflowclass">Iris框架 12.2.5</a>
<p class="overflowclass">Iris框架 12.2.5 版本源码包下载，适合需要 MVC Singleton 控制器、依赖注入字段控制和 debug 错误日志改进的开发者。</p>
</div>
<a rel="nofollow" href="/xiazai/gongju/2762" title="Iris框架 12.2.5" class="aritcle_card_btn flexRow flexcenter"><b></b><span>下载</span>
</a>
</div>
</div>
- 只在连接状态变化时触发（如
StateNew、StateClosed），但一个 TCP 连接可能承载多个 HTTP/2 stream，StateNew只发生一次，而实际并发请求数远高于 1 - 连接异常中断（如客户端断网）时，
StateClosed可能延迟或不触发，导致计数卡死 - 它无法在连接刚建立时就拒绝——资源已经分配，handler 还没执行就白占了 goroutine 和内存
所以它只能用于监控或降级通知，不能用于硬性准入控制。
真正可靠的方案：在 net.Listener 层拦截
net.Listener 层拦截如果业务对「并发连接数」要求极严（比如防 Slowloris），就必须下沉到连接建立阶段，包装原始 net.Listener：
- 用
net.Listen("tcp", ":8080")得到 listener 后，套一层自定义结构体，实现Accept()方法 - 在
Accept()内部调用原 listener 的Accept()，拿到net.Conn后立即解析conn.RemoteAddr().String() - IPv6 地址需用
net.ParseIP处理方括号，再调用.To4()或保留原格式；key 统一用字符串，不要哈希 - 超限时直接
conn.Close()并返回nil, errors.New("too many connections")，http.Server会忽略该 err 并继续 accept - 必须实现
Close()和Addr()方法，否则http.Server启动失败
这个层级的限制不依赖 HTTP 头，无法被伪造，响应最快，但代价是：它限制的是 TCP 连接数，不是 HTTP 请求并发数（HTTP/2 下一个连接可跑上百请求）。
真正落地时，别只盯着“并发数”一个维度。IP 并发限制容易在 NAT 环境下误伤（比如整个公司出口 IP 相同），也防不住 HTTP/2 多路复用。更稳妥的做法是：Listener 层控连接数 + 中间件控请求并发 + Nginx 的 limit_conn 做前置兜底，三者参数需对齐，且所有 IP 提取逻辑必须一致。
