正确做法是用通道接收结果，但必须配合上下文提取和显式goroutine启动，且goroutine中不可调用c.json()；因c绑定请求生命周期，handler返回后c即失效，异步写响应会panic。
直接用 chan 在 Gin 里做异步任务响应，容易卡死或 panic——因为通道本身不解决上下文生命周期问题，更不保证响应时机可控。真正安全的做法是：用通道收结果，但必须配合上下文提取 + 显式 goroutine 启动，且不能在 goroutine 里碰 c。
为什么不能直接在 handler 里 go c.JSON(...)？
这是最常踩的坑：c.JSON() 必须在当前 HTTP 请求 goroutine 中调用，否则会 panic（报错类似 http: response.WriteHeader on hijacked connection 或直接 crash）。Gin 的 *gin.Context 绑定到当前请求生命周期，handler 函数一返回，c 就失效。哪怕你用 go func() { c.JSON(...) }()，也大概率失败。
- 错误现象：服务偶尔 panic，日志里出现
write tcp ...: use of closed network connection - 根本原因：goroutine 拿着已回收的
c尝试写响应 - 正确思路：响应必须由主 handler 写；goroutine 只负责算、只往通道发结果；主 handler 从通道取结果再写
chan AsyncTaskResult 怎么设才不泄露？
通道要按请求粒度创建，用完即弃，不能复用或全局声明。否则多个请求共用一个通道，结果会串、阻塞、漏响应。
- 每次请求都新建通道：
resultChan := make(chan AsyncTaskResult, 1)（带缓冲，避免 goroutine 阻塞） - 绝不能写成全局变量：
var globalChan chan AsyncTaskResult—— 并发下完全不可控 - 不用手动
close()：只要缓冲足够（至少为 1），goroutine 写完就退出，通道自然被 GC 回收 - 如果任务可能失败且不想等，默认给通道加超时：
select { case res :=
如何避免 goroutine 持有 c 导致数据错乱？
所有需要传进 goroutine 的数据，必须在 go 语句之前显式提取并拷贝，禁止闭包捕获 c。
- ❌ 错误写法：
go func() { userID := c.GetString("uid") ... }() - ✅ 正确写法：
uid := c.GetString("uid"); go func(uid string) { ... }(uid) - 结构体也要深拷贝：如果用了
c.MustGet("payload")，确保它是个值类型（如map[string]interface{}或自定义 struct），而不是指针或 slice 引用 - 特别注意：
c.Request.URL.Path、c.Param("id")这些方法调用必须在go前完成，不能放到 goroutine 里再调
通道只是通信管道，不是魔法开关。真正决定是否安全的，是你有没有把上下文数据“摘干净”再扔进 goroutine，以及响应逻辑是否严格留在主 handler 内。多一次变量提取，少十个线上故障。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
