Gin 默认支持高并发长连接，因其完全复用 net/http.Server 的连接级 goroutine 模型：每个 TCP 连接由独立 goroutine 持续处理，不随单次请求结束而销毁；瓶颈仅在于业务代码阻塞，而非框架本身。
为什么 Gin 默认就支持高并发长连接？
Gin 本身不管理 goroutine 创建，完全复用 net/http.Server 的底层模型：每个新 TCP 连接进来，http.Server 就起一个 goroutine 处理整个连接生命周期。这意味着只要连接保持打开（比如 WebSocket、HTTP/2 流、或 HTTP/1.1 keep-alive 下的长轮询），该 goroutine 就持续运行，不会因“请求结束”而销毁。
你不需要在 Gin 里手动 go handle()，也不用担心“框架串行阻塞”——瓶颈只可能出在业务代码里。
- ✅ 正确理解：Gin 的并发粒度是「连接级」，不是「请求级」；长连接天然享受 goroutine 持有优势
- ⚠️ 常见误判：看到日志时间戳堆叠，就以为是 Gin 串行处理，实际可能是
log.Println被 stdout 缓冲区卡住，或终端刷新延迟 - ⚠️ 真正风险点：handler 里调用
time.Sleep、未设超时的http.Get、或阻塞式数据库查询，会挂起该 goroutine，但不影响其他连接
如何安全地维持 HTTP 长连接（如 SSE 或长轮询）？
HTTP 场景下维持长连接，核心是避免服务端提前关闭响应流，同时防止客户端断连后 goroutine 泄漏。
- 必须设置
context.WithTimeout或context.WithDeadline，而不是依赖连接空闲超时——http.Server.ReadTimeout只管读，不管 handler 内部阻塞 - 响应头要显式声明：
c.Writer.Header().Set("Content-Type", "text/event-stream")+c.Writer.Header().Set("Cache-Control", "no-cache") - 每次写入后调用
c.Writer.Flush()，否则数据卡在缓冲区，客户端收不到 - 务必监听
c.Request.Context().Done()，一旦返回，立即退出循环，释放 goroutine
示例片段：
立即学习“go语言免费学习笔记（深入）”；
func handleSSE(c *gin.Context) {
c.Header("Content-Type", "text/event-stream")
c.Header("Cache-Control", "no-cache")
c.Header("Connection", "keep-alive")
<pre class="brush:php;toolbar:false;">ctx := c.Request.Context()
ticker := time.NewTicker(5 * time.Second)
defer ticker.Stop()
for {
select {
case <-ctx.Done():
return // 客户端断开，goroutine 安全退出
case <-ticker.C:
_, _ = c.Writer.WriteString("data: ping\n\n")
c.Writer.Flush() // 关键：强制刷出
}
}}
WebSocket 长连接必须配 gorilla/websocket，Gin 只做升级路由
Gin 不内置 WebSocket 支持，它只负责把 HTTP 请求“升级”成 WebSocket 协议。真正管理连接生命周期、收发帧、心跳、错误恢复的，是 gorilla/websocket。
-
upgrader.Upgrade()必须在 Gin handler 中调用，且只能调用一次；之后所有读写都绕过 Gin，直接操作*websocket.Conn - 不要在 handler 里做耗时同步操作（如 DB 查询）——应启动新 goroutine 或发消息到 worker channel
- 务必设置
upgrader.WriteBufferSize和upgrader.ReadBufferSize，默认 4096 太小，高频消息易触发频繁 malloc - 生产环境禁止
CheckOrigin: func(r *http.Request) bool { return true }，必须校验r.Host或 Origin 白名单
长连接场景下最容易被忽略的资源泄漏点
长连接存活时间远超普通请求，goroutine、内存、文件描述符、数据库连接都更容易堆积泄漏。
- 全局 map 存连接时，没配
sync.Map或锁，写入 panic 导致 goroutine 消失但连接未 close - 忘记调用
conn.Close()—— 即使 client 断开，server 端的*websocket.Conn仍占用 fd，直到 GC 回收（可能很久） - DB 查询未用
context.WithTimeout，goroutine 卡在db.QueryRowContext上，连接池被占满 - 日志里打
c.Request.RemoteAddr没做脱敏，长连接持续打日志导致磁盘写满
真正难的不是“怎么连上”，而是“怎么干净地断开并回收”。每条长连接背后，都是一个需要主动管理的资源生命周期。
