因为*gin.context含可变状态且非线程安全，直接传入goroutine会导致并发读写panic；必须用c.copy()创建只读副本，或通过c.request.context()传递标准context。
不能把 *gin.Context 当普通指针传给 goroutine，它不是线程安全的。
为什么 *gin.Context 不能直接传给子 goroutine
因为 *gin.Context 内部包含可变状态：比如 Values（键值对）、Request（可能被重写）、Writer（响应写入器）。这些字段在多个 goroutine 并发读写时会触发 panic，典型错误包括：panic: runtime error: invalid memory address 或 http: response.WriteHeader on hijacked connection。
常见误用是写类似这样的代码：
go handleAsync(c)
而 handleAsync 里又调了 c.JSON()、c.Set() 或 c.Request.Body —— 这些操作都可能出问题。
-
ctx.Copy()只复制Values和部分只读字段，不复制http.ResponseWriter，所以副本只能读，不能写响应 - 若需异步处理并写响应，必须用 channel 把结果送回主 goroutine，由
c.JSON()等统一执行 - 别在 goroutine 里调
c.Request.Body，它可能已被主 goroutine 读过或关闭
如何安全地在 goroutine 中读取请求上下文数据
如果只是读取用户 ID、TraceID、参数等只读信息，应该用 c.Copy() 创建副本，并确保只调用安全方法：
- 允许的操作：
ctx.Param()、ctx.Query()、ctx.Value(key)（前提是 key 是私有类型，且值本身生命周期足够长） - 禁止的操作：
ctx.JSON()、ctx.Set()、ctx.Request.Body、ctx.Writer相关任何写行为 - 注意
ctx.Value()存的结构体指针（如&User{}）必须指向长生命周期对象；handler 内临时分配的指针，请求结束后内存可能已复用
想传 TraceID 或用户身份，该用哪个 context
必须用 c.Request.Context()（标准库 context.Context），而不是 *gin.Context 自己的封装：
-
c.Request.Context()支持跨 goroutine 安全传递、能被 OpenTelemetry 正确注入/提取、可透传到下游 HTTP 调用 - 往
*gin.Context上用c.Set()塞"trace_id"，日志和链路系统根本拿不到 - 中间件中更新后，一定要写
c.Request = c.Request.WithContext(newCtx)，否则 handler 拿不到新 context - key 必须是私有类型（如
type traceCtxKey struct{}），不能用"trace_id"字符串 —— 否则跨包冲突、类型断言失败
中间件与 handler 之间传数据，c.Set() 和 context.WithValue() 怎么选
c.Set() 简单够用，但仅限 Gin 生态内部；context.WithValue() 更通用、类型安全，推荐用于需要跨框架或对接 OTel / 日志系统的场景：
-
c.Set()底层其实也是转成 string key 调context.WithValue()，但丢失类型信息，容易被其他中间件覆盖（比如两个中间件都c.Set("user", ...)） -
context.WithValue()要求 key 是接口或指针类型，天然防冲突；value 建议用值类型或全局指针，避免传 map/slice 引发竞态 - HTTP handler 到 service 层，应提前完成 token 解析，把
*User注入 context，而不是传原始 token 字符串 - 所有
ctx.Value()取值后必须做类型断言并检查ok，不能静默忽略失败
最易被忽略的一点：无论用哪种方式，*gin.Context 的生命周期只到 handler 返回为止。它的内存会被 Gin 复用，所以任何对其字段的引用（尤其是指针）都不能逃逸出 handler 作用域。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
