不能直接在goroutine里传*gin.context，因其request-scoped特性导致复用后panic或读脏数据；必须提前提取所需值显式传入，并用带缓冲通道+context.withtimeout管控goroutine生命周期。
为什么不能直接在 goroutine 里用 c 传参
因为 *gin.Context 是 request-scoped 的临时对象，底层的 http.ResponseWriter 和 *http.Request 在 handler 返回后会被复用或回收。一旦你在 goroutine 中调用 c.Param()、c.PostForm() 或 c.MustGet()，极大概率 panic 或读到脏数据（比如其他请求的参数）。这不是“偶尔出错”，而是确定性风险。
必须在启动 goroutine 前把需要的值提取出来，显式传入：
userID := c.GetString("user_id")-
payload := c.MustGet("parsed_payload")（确保中间件已注入） - 不要传
c，也不要传c.Request或c.Writer
用通道替代裸 goroutine 控制计算生命周期
裸 go func() { ... }() 容易失控：没超时、没取消、没结果反馈、无法等待完成。高能耗计算尤其危险——CPU 占满、内存暴涨、goroutine 泄漏都可能发生。
推荐用带缓冲的通道 + context.WithTimeout 封装任务：
- 定义通道类型：
type ComputeResult struct { Data interface{}; Err error } - 启动 goroutine 时传入
ctx，并在计算中定期检查ctx.Err() - 结果写入通道：
resultCh - 主 handler 用
select等待通道或超时，避免阻塞
示例关键片段：
resultCh := make(chan ComputeResult, 1)
go func(ctx context.Context) {
defer close(resultCh)
res, err := heavyComputation(ctx, userID, payload)
resultCh select {
case r := <h3>通道缓冲大小设为 1 的真实原因</h3><p>缓冲大小不是随便选的。设为 <code>1</code> 是为了匹配“单次任务 → 单次结果”的语义，同时防止 goroutine 挂起阻塞：</p>
- 缓冲为 0（无缓冲）：goroutine 写入时会卡住，直到有人读 —— 如果 handler 因错误提前返回，没人读，goroutine 永久泄漏
- 缓冲 > 1：可能堆积多个未消费结果，掩盖任务重复提交或逻辑错误
- 缓冲 = 1：写入立即返回，goroutine 可安全退出；handler 读取时要么拿到结果，要么超时，行为可预测
别为了“看起来更健壮”盲目加大缓冲，那只会把问题拖到内存耗尽才暴露。
高能耗计算必须自带上下文取消检查
哪怕用了通道，如果计算函数内部不响应 cancel，通道就永远等不到结果。常见陷阱包括：
- 调用
http.Client.Do但没传ctx—— 请求卡住，goroutine 不死 - 循环遍历大数据集时没加
if ctx.Err() != nil { return } - 调用第三方库（如图像处理）没提供 context 接口，需封装超时逻辑
正确做法：所有 I/O 和长循环都必须主动轮询 ctx.Done()，并用 select 替代阻塞调用。否则通道只是个漂亮外壳，底下仍是定时炸弹。
通道本身不解决高能耗问题，它只提供可控的通信契约。真正决定是否“优雅”的，是你有没有在计算路径每一层都尊重 context 的信号 —— 这一点，比选什么通道模式重要得多。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
