Gin中不能直接在goroutine里用*gin.Context，因其绑定请求生命周期，handler返回后底层资源可能被回收，导致panic或静默失败；必须用c.Copy()获取只读副本，且仅限读操作，写响应需通过channel由主goroutine统一处理。
直接用 chan 在 Gin 里搞异步任务队列，不是不能用，而是很容易掉进“看似跑起来了、其实漏任务/卡主线程/上下文失效”的坑。核心原则就一条：Gin 的 c（*gin.Context）不能跨 goroutine 直接用，channel 只能传数据，不能传上下文本身。
为什么不能在 goroutine 里直接用 c.JSON() 或 c.Request
Gin 的 *gin.Context 是一次性的，绑定到当前 HTTP 请求生命周期。一旦 handler 函数返回，Gin 就可能回收或复用底层连接——此时若异步 goroutine 还在读 c.Request.URL 或调 c.JSON()，轻则 panic，重则写响应失败却无报错，客户端收不到任何东西。
- 常见错误现象：
panic: write on closed connection或静默无响应 - 正确做法：必须用
c.Copy()拷贝一份只读上下文副本，且仅限读取请求参数、Header 等只读字段 - 绝对禁止：在 goroutine 中调用
c.Abort()、c.Set()、c.Next()等会修改上下文状态的方法
taskCh 必须带缓冲，且大小要匹配业务峰值
无缓冲 chan Task 在高并发提交时会立刻阻塞生产者（比如 Gin handler），导致 HTTP 接口超时；而缓冲太小又起不到削峰作用。这不是理论问题，是上线后第一个爆的点。
- 缓冲大小建议按「单秒最大任务量 × 平均处理耗时（秒）」粗略估算，例如峰值 200 QPS、平均处理 0.5s → 缓冲至少 100
- 声明方式必须是
taskCh := make(chan Task, 100)，不是make(chan Task) - 提交任务时建议用
select配合default做降级，避免阻塞主流程：select { case taskCh <- task: // 正常入队 default: // 缓冲满，记录告警或写本地磁盘暂存 }
worker 启动和退出必须可控，不能靠 defer close(taskCh)
worker 是长运行 goroutine，每个都用 for task := range taskCh 消费，但 taskCh 关闭时机必须由主控逻辑决定——比如程序收到 SIGTERM 时才关 channel，而不是在某个 worker 里随便 close。
Colly 是一个用于 Go 语言的快速开源爬取和爬虫框架。它适用于从简单的页面提取到异步爬虫处理大量页面集合，支持请求回调和结构化解析。
立即学习“go语言免费学习笔记（深入）”；
- 错误示范：
go func() { defer close(taskCh); for ... }—— 第一个 worker 退出就关了 channel，其他 worker 全部提前退出 - 正确做法：全局只有一处
close(taskCh)，通常放在main函数退出前，配合sync.WaitGroup等待所有 worker 结束 - worker 内部必须检查
ok：task, ok := ，否则 range 会 panic
结果回传别用 channel 给 Gin handler，改用回调或状态轮询
想让异步任务做完后自动给客户端发响应？别用 resultCh chan<- Result + 另起 goroutine c.JSON()。因为 HTTP 连接早已关闭，这个 c 是无效的。
- 可行方案一：任务提交后立即返回任务 ID，客户端用该 ID 轮询
/tasks/{id}查状态 - 可行方案二：任务完成后写 Redis 或 DB，再通过 WebSocket / SSE 主动推送给前端（Gin 支持
c.Writer直接写流） - 绝对避免：
go func() { res := —— 这行代码大概率什么都不会发生，或者 panic
最常被忽略的一点：channel 不是消息队列，它不保证持久化、不支持重试、不提供任务确认机制。哪怕你加了缓冲、做了 recover，进程一挂，taskCh 里所有未消费任务全丢。真要可靠，得切 Redis（Asynq）或 RabbitMQ——channel 只适合“丢了也无所谓”的内部触发场景，比如日志归档、配置热加载通知。
