不能直接在goroutine里用gin.context，因其为request-scoped临时对象，handler返回后可能被回收或复用，导致读取空值、脏数据或panic；必须提前提取所需字段传入。
为什么不能直接在 goroutine 里用 c？
因为 gin.Context 是 request-scoped 的临时对象，handler 函数返回后，底层的 *http.Request 和 http.ResponseWriter 可能被回收或复用。你在 goroutine 里调用 c.Param()、c.GetHeader() 或读取 c.Keys，轻则返回空值或脏数据，重则 panic。
- 必须在启动 goroutine 前提取所需字段：比如
c.GetString("user_id")、c.PostForm("email")、c.MustGet("payload")，然后作为参数传入 -
c.Copy()仅适用于极简单场景（如只读 URL 路径），它不复制请求体、表单、JSON 解析结果等，且无法防止后续中间件修改上下文 - 如果需要传递结构体，务必深拷贝；若含指针或 map/slice，直接赋值可能引发竞态
如何让客户端秒回，又确保后台任务真执行了？
核心是两件事：立刻写出响应 + 独立 goroutine 承担后续逻辑。Gin 不会等 goroutine 结束，所以只要 handler 函数返回，连接就可关闭（HTTP/1.1 keep-alive 下由客户端决定是否复用）。
- 用
c.String(200, "ok")或c.JSON(202, gin.H{"status": "accepted"})明确告诉客户端“已收下”，别等结果 - goroutine 内部要自己处理错误：失败不抛出，必须打日志、发告警、或写入失败队列，否则无声丢任务
- 避免 goroutine 持久占用资源：HTTP client 要设
Timeout，数据库连接要用context.WithTimeout包裹，防止泄漏
什么时候该用消息队列，而不是裸 goroutine？
裸 goroutine 适合单机、低频、可丢失的任务（如埋点上报、非关键通知）。一旦任务量上升、需要重试、跨服务或要求可靠性，就必须上消息队列。
- 典型信号：任务失败需人工干预、要保证至少一次投递、多个服务消费同一类事件、高峰期 QPS > 1000
- RabbitMQ/Kafka 不是银弹：部署运维成本高，本地开发调试麻烦；但
github.com/streadway/amqp+ Gin 集成只需 10 行代码发消息，比自己实现持久化队列靠谱得多 - 不要在 goroutine 里连 RabbitMQ 再重试——应由消费者端负责幂等和重试，生产者只管发
定时任务和调度要不要塞进 Gin？
可以，但别让它变成 Gin 的负担。Gin 是 HTTP 路由器，不是调度中心。
- 用
github.com/robfig/cron/v3启一个独立 cron 实例，在main()里 start，和路由注册平行，别挂到r.GET下 - 避免在定时任务里调用
gin.Context：没有请求上下文，就别硬造；需要写日志或发通知，直接用全局 logger 或 client - 如果任务需动态启停（比如运营后台开关某导出任务），用内存 flag + channel 控制，而非重启服务
