轮询请求在Gin中“卡住”并非Gin限制并发，而是HTTP/1.1连接复用导致客户端串行发包，服务端虽用goroutine并发处理，但队头阻塞和缺乏超时控制（如http.Get未用context.WithTimeout）使单个慢请求拖垮整条连接；修复需切断隐式依赖：所有外部调用加超时、数据库配连接池、禁用同步阻塞、用c.Copy()分离后台任务，并优先改用WebSocket或SSE替代轮询。
为什么轮询请求在Gin里容易“卡住”而不是并发执行
不是Gin限制并发，而是轮询本身常被客户端（如浏览器、curl）用HTTP/1.1 keep-alive复用连接，导致请求按序发出——服务端虽用独立goroutine处理，但日志时间戳反映的是接收顺序，造成“串行假象”。更关键的是，业务层若没做超时控制或阻塞调用（比如http.Get没设context.WithTimeout），单个轮询请求卡住会拖慢整个连接上的后续请求（尤其HTTP/1.1 pipeline已废弃，实际是队头阻塞）。
如何让轮询请求真正并行且不互相干扰
核心是切断请求间隐式依赖，避免共享状态和阻塞I/O：
- 所有外部HTTP调用必须带
context.WithTimeout，例如http.NewRequestWithContext(ctx, ...) - 数据库操作禁用全局未配置池的
*sql.DB，调用前确保db.SetMaxOpenConns(20)、db.SetMaxIdleConns(10) - 禁止在handler里用
time.Sleep或同步文件读写；轮询间隔逻辑应由客户端控制，服务端只响应单次请求 - 若需后台聚合数据，用
c.Copy()复制上下文启动goroutine，原handler立即返回，例如：go func() { time.Sleep(5 * time.Second); log.Println("delayed task") }()
轮询接口的典型性能陷阱与修复
常见错误是把轮询做成“长轮询”却没释放连接资源：
- ❌ 返回前未显式关闭response body：调用
resp.Body.Close()（尤其是用http.Client发起下游请求时） - ❌ 用
gin.H返回大JSON但没启用gzip：加r.Use(gin.Gzip(gzip.DefaultCompression))，并设置MinContentLength: 512 - ❌ 路由写成
/status/:id这种动态路径，高频轮询下Radix树匹配开销上升；改用静态前缀如/v1/status?id=123 - ❌ 中间件里做耗时操作（如JWT解析未缓存结果），每个轮询请求都重复执行；提取到
ctx.Set()并复用
客户端轮询频率与服务端压测验证方法
单纯提高QPS没意义，得验证goroutine是否真在并发跑：
立即学习“go语言免费学习笔记（深入）”；
- 用
ab -n 1000 -c 200 http://localhost:8080/poll压测，观察runtime.NumGoroutine()增长是否接近并发数 - 在handler开头打日志
log.Printf("req %s start at %v", c.Request.URL.Path, time.Now().UnixMilli())，对比时间戳差值 - 检查
GOMAXPROCS是否被设为1（go env GOMAXPROCS），生产环境必须等于CPU核数 - 浏览器开发者工具Network面板看每个轮询请求的“Waterfall”时间线，确认TTFB（Time to First Byte）是否稳定低于100ms
真正难的是让轮询不变成DoS攻击——服务端要能快速拒绝无效请求，比如用gin-contrib/limiter对IP限流，或在Nginx层加limit_req。轮询本身是反模式，高并发场景优先考虑WebSocket或Server-Sent Events。
