gin.context 在 goroutine 中直接使用会 panic，必须用 c.copy() 深拷贝后使用；仅需部分数据时应提取值而非传 context；c.copy() 不可缓存复用；异步 channel 缓冲推荐设为 64–128。
gin.Context 在 goroutine 中直接使用会 panic
直接把 c 传进新 goroutine 并调用 c.JSON() 或 c.MustGet()，几乎必然在请求结束后触发 panic: reflect: call of reflect.Value.Type on zero Value。因为 gin.Context 底层复用自 sync.Pool，请求生命周期一结束就被回收重置，goroutine 拿到的是已失效的内存块。
正确做法只有且必须是：c.Copy()。它会深拷贝当前上下文的状态（包括 c.Keys、c.Request.URL、c.Params 等），但不复制响应 writer —— 这很关键，异步任务本就不该写响应。
-
c.Copy()返回的新*gin.Context可安全用于后台任务，但不能再调c.Abort()或c.Next() - 若只需读取参数或中间件存的数据，优先提取值再传入 goroutine，避免携带整个
Context - 不要对
c.Copy()做缓存或跨请求复用，它的生命周期只属于当前异步任务
并发写日志或 DB 时 channel 缓冲大小要设合理
用 channel 做异步日志或消息投递时，缓冲太小（如 make(chan []byte, 1)）会导致写 goroutine 频繁阻塞；太大（如 10240）又可能积压大量未处理数据，OOM 风险陡增。实测在 5k QPS 场景下，64–128 是较稳的平衡点。
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
- 写端用
select+default防止阻塞：select { case logCh - 读端需做 recover，避免单条坏日志导致整个 pump goroutine 崩溃
- DB 写入类 channel 不建议用无缓冲，因
db.Exec()本身有网络延迟，容易卡住生产者
多个 goroutine 同时调 c.Set() 会数据竞争
c.Set() 内部操作的是 c.Keys 这个 map，而 Go 的 map 并发读写 panic 是确定行为。即使你只在中间件里 set 一次、handler 里 get 多次，只要存在任意两个 goroutine 同时写（比如两个并行子任务都尝试 c.Set("trace_id", ...)），就会 crash。
- 所有
c.Set()必须发生在主 goroutine（即 handler 执行流中），禁止在子 goroutine 里调 - 若子任务需要往 context 传数据，应由主 goroutine 统一收集后一次性
c.Set() - 更安全的做法是：用
context.WithValue()构建新 context 传给子任务，gin.Context本身只读
WebSocket 连接管理不能依赖 gin.Context 生命周期
很多人试图在 Gin 路由里调 upgrader.Upgrade()，然后把 *websocket.Conn 存进 c.Set()，指望后续中间件或 handler 能取出来 —— 这完全错误。gin.Context 生命周期只到 HTTP 响应结束，而 WebSocket 连接此时才刚开始。
- WebSocket 升级必须绕过 Gin，走原生
http.HandleFunc，否则 header 被篡改、连接被静默断开 -
*websocket.Conn必须绑定到独立结构体（如type Client struct { conn *websocket.Conn; send chan []byte }），生命周期由连接自身控制 - 绝不要把
conn存进c.Keys或任何基于gin.Context的存储，它和Context根本不是同一生命周期维度
真正容易被忽略的是：gin.Context 不是线程安全的容器，也不是长期存活的对象。它只是请求处理流程的一次性快照，设计上就拒绝被跨 goroutine 共享。任何想把它当“上下文总线”用的思路，都会在高并发下准时翻车。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
