worker池优于直接go f()：能复用协程、控并发、减内存与调度压力；需用sync.waitgroup+context.context确保正确退出，channel宜设无缓冲或小缓冲。
为什么直接开一堆 go f() 不如用 Worker 池
因为任务量波动大时，无节制启协程会快速耗尽内存和调度器压力；而 Worker 池能复用固定数量的协程，避免频繁创建销毁开销，也便于控制并发上限。Go 的 runtime.GOMAXPROCS 和调度器对几千个空闲协程并不友好——它们仍占栈内存、被扫描、参与抢占调度。
- 典型误用：
for _, task := range tasks { go process(task) }—— 任务数一过千，goroutine数就失控 - Worker 池本质是「生产者-消费者」模型：一个或多个 goroutine 往
chan Task塞任务，N 个固定 worker 从该 channel 拿任务执行 - channel 容量建议设为
0（无缓冲）或小缓冲（如16），避免任务积压掩盖处理瓶颈
workerPool 结构体怎么设计才不漏信号
核心是用 sync.WaitGroup 等待所有 worker 退出，同时用 context.Context 支持提前取消；不能只靠 close(ch) 就认为 worker 全结束了——channel 关闭后，worker 可能还在处理最后一个任务。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 必须在启动每个 worker 前调用
wg.Add(1)，在 worker 函数末尾调用wg.Done() - worker 循环应基于
select+ctx.Done()判断退出，而非单纯读 channel 是否 closed - 向任务 channel 发送任务前，确保它没被关闭；发送完应调用
wg.Wait()等待全部 worker 处理完毕 - 示例关键片段：
for { select { case task, ok :=
任务 channel 类型选 chan Task 还是 chan *Task
取决于 Task 大小和是否需要修改原值。小结构体（如含 2–3 个 int/string）传值更安全；大结构体或需在 worker 中改字段，则传指针，但要注意数据竞争。
- 传值：避免意外共享状态，适合只读或简单计算类任务，如
type Task struct{ ID int; Payload []byte }（若Payload小） - 传指针：减少内存拷贝，适合大对象或需回调更新状态的任务，但必须确保没有其他 goroutine 同时访问同一实例
- 常见坑：
for i := range tasks { go func() { process(tasks[i]) }() }—— 闭包捕获的是循环变量i，最终全取到tasks[len-1]；正确写法是go func(t Task) { process(t) }(tasks[i])
如何安全关闭 Worker 池并等任务跑完
关闭不是「立刻停」，而是「不再收新任务 + 等旧任务自然结束」。强行 close(channel) 并不能让正在运行的 goroutine 中断，反而可能引发 panic（如再往已关 channel 发送）。
- 不要用
close(tasks)当作 shutdown 信号——它只影响接收端，且只能 close 一次 - 推荐做法：用
context.WithCancel创建可取消 ctx，worker 监听ctx.Done()；主流程调用cancel()后，再调用wg.Wait() - 如果任务本身阻塞（如 HTTP 请求），需给
task.Do()传入子 context 并设超时，否则wg.Wait()会永远卡住 - 关闭后不要再往
taskschannel 发送，否则 panic：send on closed channel
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
