因为http.servemux不感知客户端ip连接上下文，无法跟踪单ip活跃连接数；必须在net.listener的accept()阶段提取ip并计数，才能实现硬性并发限制。
为什么直接用 net/http 默认 ServeMux 无法限制单IP并发连接数
Go 标准库的 http.Serve 和默认 http.ServeMux 不感知客户端 IP 的连接上下文，更不会跟踪「当前有多少个活跃连接来自同一个 IP」。你看到的 http.Request.RemoteAddr 是字符串（如 "192.168.1.100:54321"），但每次请求都是独立生命周期，中间件里没有天然的“连接池”或“会话计数器”。想限制并发，必须自己维护状态，并在连接建立/关闭时同步增减——而标准 HTTP handler 模型不暴露连接级钩子。
用 net.Listener 层拦截并计数才是可靠方案
HTTP server 的真正入口是 net.Listener，它在 accept 阶段就拿到原始 net.Conn，此时可提取 IP 并做准入判断。这是唯一能准确控制「并发连接数」的位置，因为：① 连接刚建立、尚未进入 HTTP 解析；② 可以在拒绝时直接 close，不消耗 handler 资源；③ 避免了基于请求头伪造 IP 的风险（X-Forwarded-For 在这里还没被读取）。
实操建议：
- 包装原始
net.Listener，例如用net.Listen("tcp", ":8080")得到 listener 后，套一层自定义ipLimitListener - 用
sync.Map或带锁的 map 记录IP → int当前连接数，key 用strings.Split(conn.RemoteAddr().String(), ":")[0]提取 IPv4/IPv6 主机部分（注意处理 IPv6 方括号格式） - 在
Accept()返回前检查计数，超限时调用conn.Close()并返回nil, errors.New("too many connections")（http.Server会忽略该 err 并继续 accept） - 必须配套实现
Close()和Addr()方法，否则http.Server启动失败
http.Server 的 ConnState 钩子只能辅助，不能替代 listener 层限制
http.Server.ConnState 回调能感知连接状态变化（StateNew / StateClosed），看似可用于计数，但它有严重缺陷：
- 不是每个
StateNew都对应一个有效 HTTP 连接（比如 TLS 握手失败、半开连接） - 多个请求复用同一连接（HTTP/2、keep-alive）时，
StateNew只触发一次，但实际并发请求数可能远高于连接数 - 连接关闭时回调可能滞后，导致计数泄漏（尤其 panic 或 abrupt disconnect 场景）
- 无法在连接建立瞬间拒绝，只能放行后再等 handler 执行完才回收资源
所以它只适合做统计或降级通知，不能用于硬性并发控制。
要注意 IPv6 地址格式和 NAT 环境下的 IP 提取
直接对 conn.RemoteAddr().String() 做 strings.Split(..., ":") 在 IPv6 下会出错，例如 "[2001:db8::1]:12345"。正确做法是用 net.ParseIP 提取 host：
host, _, _ := net.SplitHostPort(conn.RemoteAddr().String())
ip := net.ParseIP(host)
if ip == nil {
// 处理非法地址，例如 unix socket 或未知格式
return false
}
ipStr := ip.String() // 自动标准化 IPv4/v6 格式
另外，如果服务前有反向代理（Nginx、Cloudflare），RemoteAddr 是代理 IP，不是真实客户端 IP。此时必须依赖 X-Real-IP 或 X-Forwarded-For，但这已脱离 listener 层能力范围——得在 handler 中解析并配合限流中间件（如基于 gorilla/mux + golang.org/x/time/rate 做请求级限速），但那只是「QPS 限制」，不是「并发连接数限制」。
真正要控并发连接数，就得直面 TCP 层；真正在意真实客户端 IP，就得确保网络架构透明或代理明确透传且可信。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
