因为gin.Context非线程安全且绑定请求生命周期，直接跨goroutine使用会导致读写冲突或访问已回收内存；必须用c.Copy()创建只读副本，且需提前提取Body等不可重复读数据。
为什么 gin.Context 不能直接跨 goroutine 使用
因为 gin.Context 不是并发安全的：它的内部字段（如 Keys、Params、Writer）会被多个 goroutine 同时读写，且没有锁保护。更关键的是，它绑定着当前 HTTP 请求的生命周期——一旦 handler 返回，Gin 就会回收并复用该 Context 实例，若异步 goroutine 还在访问，就会读到脏数据或 panic。
常见错误现象：panic: reflect.Value.SetMapIndex: value of type *gin.Context is not addressable 或日志中出现 http: response.WriteHeader on hijacked connection，本质都是原 Context 已被释放或写入冲突。
- 必须用
c.Copy()创建副本，再传给 goroutine -
c.Copy()会重置Writer、清空Keys和handlers，确保副本不干扰主流程 - 不要对副本调用
c.Abort()或c.JSON()等响应方法——它已无有效响应器
全局变量修改引发的竞态怎么快速定位
比如一个计数器 var count int 在 handler 中直接 count++，压测时返回值远小于预期，就是典型的非原子操作导致的竞态。Go 不保证 count++ 是单条 CPU 指令，它实际拆成「读→加→写」三步，多 goroutine 并发执行时必然丢更新。
使用 go run -race main.go 能立刻捕获这类问题，输出类似：Read at 0x00c000010240 by goroutine 7 + Previous write at 0x00c000010240 by goroutine 6。
- 简单整数计数：改用
sync/atomic，如atomic.AddInt64(&count, 1) - 需要保护一段逻辑（比如同时更新 map 和 counter）：用
sync.Mutex或sync.RWMutex - 避免用全局
map存请求状态——改用context.WithValue()或本地结构体
Gin 中间件和 handler 的并发模型真相
Gin 本身不启动 goroutine；它完全依赖 Go 标准库 net/http.Server 的调度：每个新连接到来，http.Server 自动起一个 goroutine 执行整个请求链（路由匹配 → 中间件 → handler）。所以 Gin 天然支持高并发，瓶颈从来不在框架层。
但你看到的日志“串行”，往往是因为：
- 客户端复用 HTTP/1.1 连接，请求按序到达，服务端虽并发处理，但日志时间戳反映接收顺序
- handler 中有阻塞调用（如没设超时的
http.Get、未配连接池的db.Query），该 goroutine 挂起，但不影响其他请求 - 用了
gin.Default()，其默认Logger中间件带锁，QPS 超 5k 后日志写入成瓶颈，建议换无锁日志库
异步任务里怎么安全读取请求参数
如果要在 goroutine 里访问 query、form 或 header，不能直接用原始 c，也不能只复制 c.Copy() 就完事——因为 c.Copy() 不复制底层 http.Request.Body，而 Body 是 io.ReadCloser，只能读一次。
正确做法是：在启动 goroutine 前，把需要的数据提取出来，作为参数传入。
- 读 query：
q := c.Query("id")，然后go doAsync(q) - 读 JSON body：先
c.ShouldBindJSON(&req)解析到结构体，再传req进 goroutine - 绝对不要在 goroutine 里调用
c.PostForm()或c.GetHeader()——此时c.Request可能已被回收
最易被忽略的点：Body 读取不可逆，c.Copy() 不解决这个问题；所有需要多次访问的数据，必须在 handler 主流程中一次性提取干净。
