Gin 不控制单个长连接的最大请求数，该限制由 Nginx 等反向代理或客户端决定；Go http.Server 无 keepalive_requests 配置，需在 Nginx upstream 中设置并协同 IdleTimeout 使用。
Gin 本身不控制单个长连接的最大请求数，这个限制必须由反向代理（如 Nginx）或客户端行为决定。Gin 是 HTTP 应用层框架，它看到的已经是解包后的每个独立请求，无法感知底层 TCP 连接是否复用、复用了几次。所谓“单个长连接处理多少请求”，是传输层和代理层的事，不是 Gin 的职责范围。
为什么 keepalive_requests 不在 Gin 配置里生效
这个指令属于 Nginx 的 upstream 模块或 http/server/location 块，Gin 启动的 Go HTTP server（http.Server）压根不解析也不支持该配置。Go 标准库的 http.Server 只提供 MaxConnsPerHost、IdleTimeout、ReadTimeout 等连接级参数，但没有“每连接最多服务 N 个请求”这一开关。
- 如果你在 Gin 项目里试图写
keepalive_requests 50到某个配置文件中，它不会被读取，也不会报错——只是完全无效 - 浏览器或 curl 发起的 HTTP/1.1 keep-alive 连接，在 Go server 端默认会一直复用，直到客户端主动断开、超时、或服务端进程重启
- Go 的
http.Server在连接空闲时会等待IdleTimeout（默认 0，即不限制），但不会按请求数计数关闭连接
想在 Go 层模拟“每连接限请求数”，只能靠客户端配合
纯服务端无法可靠实现，因为：
- TCP 连接复用对 Go 来说是透明的，
http.Request对象之间没有共享的“连接 ID”或计数器上下文 - 多个 goroutine 可能并发处理同一连接上的不同请求，无法安全地原子递增一个跨请求的计数器
- 即使你 hack 出一个 per-connection map（比如用
net.Conn.RemoteAddr()做 key），也无法区分“同一个 IP 的多个连接”和“同一个连接的多次请求”，极易误判
可行的折中方案只有：让客户端在请求头里带上自增序号（如 X-Request-Seq: 1），然后 Gin 中间件校验该字段是否 ≤ N，并在达到阈值后返回 Connection: close 响应头 —— 但这依赖客户端守约，不具备强制性。
真正有效的做法：交给 Nginx 控制长连接生命周期
如果你用 Nginx 做反向代理（绝大多数生产场景都是），就把 keepalive_requests 放在 upstream 块里，这才是它该在的位置：
upstream backend {
server 127.0.0.1:8080;
keepalive 32;
keepalive_requests 50;
}同时确保：
- Nginx 的
proxy_http_version 1.1和proxy_set_header Connection ''已启用，否则后端收不到 keep-alive 请求 - Go 的
http.Server开启了IdleTimeout（例如设为30 * time.Second），与 Nginx 的keepalive_timeout协同，避免连接半开 - 不要把
keepalive_requests设为 1 —— 这会让所有连接退化成短连接，触发大量TIME_WAIT和握手开销
最后提醒一句：HTTP/2 场景下，keepalive_requests 依然生效（从 Nginx 1.15.3 起），但它的意义更接近“单个 TCP 连接上最多处理多少个 HTTP/2 stream”，而浏览器自身也会限制并发流数（如 Chrome 默认 1000），所以实际效果是两者取小。别指望靠它做精细流控，那是 http2_max_concurrent_streams 的事。
