Gin 默认能扛住5000+并发，因其复用net/http.Server的goroutine模型，每个请求由独立goroutine处理；性能瓶颈通常源于业务阻塞、I/O等待或GOMAXPROCS配置不当，而非框架本身。
为什么 Gin 默认就能扛住 5000+ 并发？
因为 Gin 本身不调度 goroutine，它完全复用 net/http.Server 的并发模型：每个新连接进来，http.Server 就起一个 goroutine 处理整个请求生命周期。Go 1.25 默认 GOMAXPROCS 等于 CPU 核数，只要业务逻辑不阻塞，万级并发在 4C8G 机器上很常见。
但你看到的“请求排队”或“响应变慢”，大概率不是 Gin 的锅，而是：
-
http.Client调用下游 AI 服务时没设Timeout或没复用连接池，导致 goroutine 卡在 I/O 上 - 全局
*sql.DB实例没调SetMaxOpenConns()，所有请求争抢数据库连接 - 日志写入直接打到
os.Stdout，高并发下缓冲区满、刷新延迟，造成“串行错觉”
限流中间件该用 golang.org/x/time/rate 还是 Redis？
单机部署、QPS ≤ 2000 时，用 rate.Limiter 更轻量；跨多实例、需全局计数（比如防刷）、或要求滑动窗口精度时，必须走 Redis。
注意两个坑：
立即学习“go语言免费学习笔记（深入）”；
-
rate.NewLimiter(100, 200)表示每秒最多 100 次，但允许突发 200 次——别把 burst 设成 1，否则会拒绝所有并发请求 - Redis 限流若用
INCR + EXPIRE两步操作，在网络分区时可能漏计数；推荐用 Lua 脚本原子执行 - 限流逻辑必须放在认证之后，否则攻击者可绕过 JWT 验证直接打爆限流器
gin.Context 里存东西，为什么有时取不到？
c.Set("key", value) 只对当前请求生命周期有效，且只在同一次中间件链中传递。常见失效场景：
- 你在中间件 A 中
c.Set("user", u)，但在中间件 B（注册顺序在 A 之后）里取不到——检查r.Use(A, B)的顺序是否反了 - 用
c.Copy()启动 goroutine 异步处理时，必须显式传入c.Copy()返回的新 Context，原c在 handler 返回后就失效 - 别往
c里塞大对象（比如原始图片字节），容易引发内存泄漏；优先存 ID 或指针，用完即删
动态路由热更新，为什么改了 YAML 配置却没生效？
Gin 的路由树在 r.Run() 前就固化了，没法运行时修改。所谓“动态”，其实是靠外部配置中心 + 重启路由层实现的。
真正可行的做法只有两种：
- 用
gin.RouterGroup预留通配路径（如r.Any("/api/:service/*path")），所有流量先兜底进 handler，再查配置中心转发——适合小规模网关 - 启动独立的路由管理 goroutine，监听配置变更（如 etcd/Consul），收到信号后新建
gin.Engine实例，用http.Serve切换监听器，旧实例调Shutdown()等待活跃请求结束——这是 Sub2API 生产环境用的方案
别信“反射重写路由树”这类 hack，Gin 内部用的是不可变 trie 结构，强行改会导致 panic 或路由错乱。
