直接开goroutine处理请求会panic，因gin.Context非线程安全且请求结束后被回收，须用c.Copy()创建副本才能安全读取已解析参数，但不可调用响应方法或读取未解析body。
为什么直接开 goroutine 处理请求会 panic？
因为 gin.Context 不是线程安全的，原生上下文在请求生命周期结束后会被 Gin 自动回收。如果在 goroutine 中直接访问 c.Param("id")、c.Request.URL 或 c.GetHeader()，极大概率触发 panic: context canceled 或空指针崩溃。
必须用 c.Copy() 创建一个独立副本，才能在异步任务中安全读取请求数据。注意：复制只保留当前已解析的参数（如 c.Param、c.Query、c.Get 设置的值），不包含未读取的原始 body 流——若需 body 内容，得提前调用 c.ShouldBindJSON() 或 c.GetRawData() 保存。
-
c.Copy()是浅拷贝，不复制底层http.Request和http.ResponseWriter - 复制后不能调用
c.Abort()、c.JSON()等响应方法，否则无效 - 高频场景下，频繁
c.Copy()本身也有小开销，建议只在真正需要异步时才复制
并发调用多个下游服务怎么避免超时雪崩？
用 context.WithTimeout() 给每个 goroutine 单独设超时，而不是共用主请求上下文。主上下文一取消，所有子 goroutine 全部中断，无法实现“部分成功”。
典型错误写法：go callService(c, ch) —— 所有 goroutine 共享同一个 c.Request.Context()，一旦客户端断连，全部中断；正确做法是为每个调用新建带独立 deadline 的子 context。
- 每个下游调用应使用
ctx, cancel := context.WithTimeout(context.Background(), 2*time.Second) - 用
sync.WaitGroup+select等待结果或超时，避免死等 - 对失败调用做降级（如返回缓存值、空结构体），不要让单点失败拖垮整个响应
sync.Pool 缓存什么对象最有效？
不是所有对象都适合放 sync.Pool。真正收益大的是：高频创建、生命周期短、结构固定、含可复用字段（如缓冲区、JSON 解码器、临时 map）。
比如每次请求都 new 一个 bytes.Buffer 或 json.Decoder，GC 压力明显；但缓存一个 *gin.Context 没意义——它本身已由 Gin 内部池管理，且强绑定请求生命周期。
- 推荐缓存：
bytes.Buffer、encoding/json.Decoder、预分配的[]byte切片、自定义结构体（如ResponseBuilder） - 避免缓存含指针或闭包的对象，可能引发内存泄漏
- 务必在每次使用后调用
buf.Reset()，否则下次取出时内容残留
中间件里启动 goroutine 有什么隐藏风险？
中间件执行顺序和 c.Next() 控制流容易被忽略。如果在中间件里开 goroutine 并试图修改 c 状态（如 c.Set("key", val)），主线程可能早已执行到响应阶段，导致数据竞争或写入丢失。
更隐蔽的问题是：中间件 A 启动 goroutine 修改了上下文，中间件 B 在后续链中读取该值，但 B 执行时 goroutine 还没完成——这属于典型的竞态，pprof 看不到，压测才暴露。
- 中间件中异步操作只应做“旁路”事，如日志上报、指标打点、消息投递
- 绝对不要在 goroutine 中调用
c.Set()、c.Error()、c.Status() - 如需传递异步结果给 handler，改用 channel 或全局 map（带锁）+ 请求 ID 关联，而非依赖上下文
实际并发优化中最容易被跳过的，是「限制 goroutine 数量」。无节制 go func(){}() 在高 QPS 下会迅速耗尽系统线程资源，触发调度延迟甚至 OOM。别只盯着 c.Copy() 和 sync.Pool，先用带缓冲的 worker pool 控制并发度。
