异步 goroutine 中直接调用 c.json 会 panic，因 *gin.context 非线程安全且生命周期绑定请求；正确做法是不传递 c，改用通道或回调，必要时用 c.copy() 获取只读副本，且通道无需主动 close。
异步 goroutine 里直接用 c.JSON 会 panic
这是最常踩的坑：Gin 的 *gin.Context 不是线程安全的，且生命周期绑定于当前 HTTP 请求。一旦主 goroutine 返回响应、连接关闭，c 就可能被回收。在异步 goroutine 中调用 c.JSON、c.String 等方法，极大概率触发 panic: write tcp: use of closed network connection 或更隐蔽的空指针崩溃。
正确做法是——绝不把 c 传进异步 goroutine；需要返回结果时，改用通道通信或回调函数。
- 必须用
c.Copy()复制上下文（仅当真需在异步中读取请求数据，如 header、query、body 副本） - 复制后的
ctx仅限只读访问，不能调用任何写响应的方法 - 若需发响应，由主 goroutine 或独立的响应协程监听通道后统一处理
taskResultChan := make(chan AsyncTaskResult) 该不该 close()
通道是否关闭，取决于使用模式。对单次请求的异步任务，**不建议主动 close()**，尤其当通道只写一次、且写入者明确知道完成时机时。
原因很实际：close() 后再往该通道发送会 panic；而如果多个 goroutine 可能向同一通道写入（比如重试逻辑或并发子任务），提前 close 容易引发竞争。Gin 场景下，绝大多数是「一个请求 → 一个 goroutine → 一个结果 → 一次写入」，通道用完即弃，GC 会回收，无需手动 close。
- 只有当你用
range遍历接收方（比如for res := range ch）时，才必须 close，否则会死锁 - 用
单次接收，不 close 完全安全 - 若通道被复用（如全局 worker 池），则应由写入方统一管理 close，但 Gin 请求级通道不推荐复用
为什么用通道比全局变量或共享 struct 更可靠
通道天然带同步语义和内存可见性保证。goroutine 间通过通道传递数据，Go runtime 会确保写入操作对读取方可见，避免因 CPU 缓存不一致导致的读到旧值问题。
而用全局变量或未加锁的 struct 字段传递结果，即使加了 sync.Mutex，也容易漏掉边界条件（比如忘记在 defer 里 unlock，或 panic 后锁未释放）。通道把「等待」和「通知」封装成原子操作，代码更直白、更少出错。
- 通道阻塞接收（
res := ）自动实现 goroutine 同步，无需额外 <code>sync.WaitGroup - 类型安全：编译期检查收发数据结构是否匹配，比如
chan AsyncTaskResult不可能误塞string - 可配合
select实现超时控制：select { case res :=
通道泄漏风险：没读完就丢弃 taskResultChan
如果异步 goroutine 已启动，但主流程因错误提前退出（比如参数校验失败、中间件 abort），而你又没监听该通道，那个 goroutine 就会永远卡在 taskResultChan 上，造成 goroutine 泄漏。
关键点在于：**通道写入是阻塞的，除非有接收方准备就绪**。所以不能只管发，不管收。
- 始终确保每个
make(chan T)都有对应的一次（或多次）接收，哪怕只是丢弃：go func() { - 更稳妥的做法是加超时或 context 控制：
select { case taskResultChan - 生产环境建议用带缓冲的通道：
make(chan AsyncTaskResult, 1)，避免写入端无条件阻塞
通道本身不复杂，但 Gin 异步场景下，它和上下文生命周期、goroutine 管理、错误传播三者咬合得非常紧。漏掉任意一环，轻则响应失败，重则服务缓慢甚至 OOM。
