高并发队列接口必须严格控制并发、带超时、防泄漏、可降级；用ants.Pool替代裸go，初始化需早于服务启动，worker数设为NumCPU()*5~10，任务提交需非阻塞+缓冲通道+派生context。
高并发队列接口不是“能跑就行”，而是必须在入口就卡死并发数、带超时、防泄漏、可降级——否则上线三天，OOM或context.DeadlineExceeded就会批量报错。
用 ants.Pool 替代裸 go 启动，控制 goroutine 总量
直接在 HTTP handler 里写 go handleTask() 是最常见也最危险的做法。goroutine 看似轻量，但每万级并发会吃掉数百 MB 内存，且调度器压力陡增。
-
ants.Pool初始化要早于服务启动（比如放在init()或main()开头），避免运行时 panic - 最大 worker 数建议设为
runtime.NumCPU() * 5 ~ 10：IO 密集型取上限，CPU 密集型取下限 - 提交任务时注意
ants.WithNonblocking(true)的语义：true 会丢任务并返回ErrPoolOverload，false 会阻塞等待空闲 worker —— 支付类接口选 false + 降级逻辑，日志类选 true - 别把
*gin.Context直接传进池子；要用ctx, cancel := context.WithTimeout(c.Request.Context(), 3*time.Second)派生，并defer cancel()
任务通道必须带缓冲 + 非阻塞提交
无缓冲 chan 在消费者来不及消费时会立刻阻塞生产者，导致 HTTP 请求 hang 住；而无限大缓冲又等于把内存当队列用，迟早 OOM。
- 缓冲大小按「峰值 QPS × 平均处理耗时 × 1.5」粗估，例如 2000 QPS × 0.2s × 1.5 ≈ 600，设
make(chan *Task, 600) - 提交时务必用
select { case q.taskChan ，不能裸写q.taskChan - channel 关闭前确保所有 worker 已退出（靠
sync.WaitGroup等待），否则range会 panic
任务结构体必须复用，避免 GC 压力
高频入队场景下，每秒几百次 &Task{...} 会频繁触发 GC，延迟毛刺明显。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 定义全局
var taskPool = sync.Pool{New: func() interface{} { return &Task{} }} - 获取：
t := taskPool.Get().(*Task)；使用完立刻归还：taskPool.Put(t) - 注意：不要在
Put后继续读写该结构体字段，Pool 不保证对象清零，建议每次Get后重置关键字段（如t.ID = 0; t.Fn = nil）
所有下游调用必须套 context.WithTimeout 并监听 Done()
一个没设超时的 http.Do() 或 db.QueryRow() 就足以拖垮整个 worker 池——它不返回，worker 就卡死，新任务全排队。
- 每个任务执行函数开头就做：
ctx, cancel := context.WithTimeout(parentCtx, 2*time.Second)，结尾必defer cancel() - 下游调用统一用
ctx，例如http.NewRequestWithContext(ctx, ...)、db.QueryRowContext(ctx, ...) - 遇到
ctx.Err() == context.DeadlineExceeded或context.Canceled，立刻返回错误，不重试、不 log.Fatal - 别用
c.Request.Context()直接传给异步 goroutine，它随请求结束自动 cancel，可能导致任务中途被杀
最容易被忽略的是 defer cancel() 忘写，或者 channel 关闭后 worker 还在 range —— 这两类问题不会立刻报错，但会在压测时集中爆发 goroutine 泄漏。上线前务必用 pprof/goroutines 对比空载和满载下的协程数量曲线。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
