gin默认支持高并发长连接，因其复用net/http.server模型，每个tcp连接由独立goroutine处理；瓶颈通常在read/writetimeout配置、系统ulimit限制或阻塞式handler，而非gin本身。
为什么 Gin 默认就能处理高并发长连接
Gin 本身不管理连接生命周期，它完全复用 net/http.Server 的底层模型：每个新 TCP 连接（包括 HTTP/1.1 keep-alive 或 HTTP/2 多路复用连接）都会触发一个独立 goroutine 执行整个请求生命周期。这意味着只要 Go runtime 调度正常、系统资源（文件描述符、内存）充足，Gin 就天然支持成千上万的长连接——不是“能撑住”，而是“根本不会阻塞其他连接”。
常见误解是把连接数瓶颈归给 Gin，实际卡点往往在：net/http.Server 的 ReadTimeout/WriteTimeout 配置过短、操作系统级 ulimit -n 限制太低、或业务 handler 里用了同步阻塞操作（如未设超时的 http.DefaultClient.Do()）。
长连接场景下必须显式配置的 HTTP Server 参数
直接使用 r.Run() 会启用默认 http.Server，但默认值对长连接极不友好。必须手动构造并启动 server：
-
ReadTimeout和WriteTimeout设为 0（禁用）或足够大（如 5 分钟），否则空闲连接会被强制关闭 -
IdleTimeout必须设置（推荐 60–300 秒），它控制 keep-alive 连接空闲多久后关闭，避免客户端假死连接堆积 -
MaxConns和MaxIdleConnsPerHost要配合客户端行为调优；服务端通常只需关注http.Server.MaxOpenConns（Go 1.19+）防止单机连接数爆炸
示例：
srv := &http.Server{
Addr: ":8080",
Handler: r,
ReadTimeout: 0,
WriteTimeout: 0,
IdleTimeout: 120 * time.Second,
MaxOpenConns: 10000,
}
log.Fatal(srv.ListenAndServe())
goroutine 泄漏：长连接最隐蔽的杀手
当 handler 启动子 goroutine 处理异步任务（如推送、轮询、超时重试），但没做 cleanup，会导致 goroutine 持有 *gin.Context 引用无法释放，进而拖垮整个服务。
关键原则：所有子 goroutine 必须监听 c.Request.Context().Done()，并在退出前清理资源：
- 不要在 goroutine 里直接用
c，应提取必要数据（如c.Param("id")）传入 - 用
select+ctx.Done()替代无条件time.Sleep - 若需跨 goroutine 写响应，改用 channel 通知主线程，而非在子 goroutine 里调用
c.JSON()
错误示范：
go func() {
time.Sleep(5 * time.Second) // ❌ 可能永远不执行
c.JSON(200, "done") // ❌ c 已失效
}()
连接池与反向代理下的真实长连接行为
生产环境几乎都走 Nginx / ALB / Cloud Load Balancer，这些中间件会主动断开空闲连接（通常 60–300 秒），导致你看到的“长连接”其实是被代理层劫持后的短连接链路。此时 IdleTimeout 应略小于代理的 timeout，否则服务端先关连接会触发 RST 包。
更麻烦的是 HTTP/2 场景：客户端复用单个 TCP 连接发大量请求，但 net/http 默认对每个请求仍起新 goroutine。如果业务 handler 存在锁竞争（比如共享 *sql.DB 且 SetMaxOpenConns(1)），高并发下所有 goroutine 会在 acquire connection 时排队——看起来像“长连接卡住”，实则是数据库连接池堵死。
验证方式：用 pprof/goroutine 看是否大量 goroutine 卡在 database/sql.(*DB).conn 或 net/http.(*persistConn).roundTrip。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
