go中goroutine泄漏比误用sync.pool更常见，主因是任务卡住、panic未recover、channel关闭不当；应使用buffered channel+waitgroup实现固定大小协程池，worker数需按io/cpu密集型区分设置。
goroutine 泄漏比池子没用好更常见
Go 里没有内置的 goroutine 池，直接用 sync.Pool 管理 goroutine 是错的——它只适合复用对象，不负责调度或生命周期控制。真正要防的是：任务提交后 goroutine 卡住、panic 未 recover、channel 关闭不及时，导致 goroutine 永远挂起。
常见错误现象：runtime.GOMAXPROCS(1) 下跑着跑着卡死；pprof 查 goroutine 数持续上涨；日志里反复出现 fatal error: all goroutines are asleep - deadlock!。
- 永远在 worker goroutine 里加
recover()，尤其处理用户传入的函数时 - 用带缓冲的
chan *task（比如make(chan *task, 100)），避免 submit 阻塞导致调用方协程堆积 - 池关闭时，先关 input channel，再
waitGroup.Wait()，最后关 result channel —— 顺序反了就漏 goroutine
用 buffered channel + waitGroup 实现最小可行池
不需要引入第三方库，15 行内能写出生产可用的固定大小池。核心是把“任务分发”和“worker 生命周期”拆开：channel 负责排队，sync.WaitGroup 负责等待退出，sync.Once 控制关闭幂等性。
使用场景：HTTP handler 中批量调第三方 API、日志异步刷盘、定时任务批量重试。
示例关键结构：
type Pool struct {
tasks chan *task
workers int
wg sync.WaitGroup
once sync.Once
}
func (p *Pool) Submit(f func()) {
p.tasks <h3>worker 数设成 runtime.NumCPU() 多数时候是错的</h3><p>CPU 密集型任务才该对齐 CPU 核数；IO 密集型（HTTP、DB、文件）反而需要更大池子，否则大量 goroutine 在 sysmon 里等网络就绪，实际并发度上不去。</p><div class="aritcle_card flexRow artxards">
<div class="artcardd flexRow">
<a class="aritcle_card_img" rel="nofollow" href="/xiazai/skill6460" title="Golang Naming"><img
src="https://img.php.cn/upload/skill/000/000/081/179094616043400.jpg" alt="Golang Naming" onerror="this.onerror='';this.src='/static/lhimages/moren/morentu.png'" ></a>
<div class="aritcle_card_info flexColumn">
<a rel="nofollow" href="/xiazai/skill6460" title="Golang Naming" class="overflowclass">Golang Naming</a>
<p class="overflowclass">Go（Golang）命名规范 — 包括包、构造函数、结构体、接口、常量、枚举、错误、布尔值、接收器、getter/setter、函数等。</p>
</div>
<a rel="nofollow" href="/xiazai/skill6460" title="Golang Naming" class="aritcle_card_btn flexRow flexcenter"><b></b><span>下载</span>
</a>
</div>
</div><p>参数差异：</p>
-
runtime.GOMAXPROCS(n)控制 P 的数量，影响调度器吞吐，和 worker 数无关 - 池大小建议从
50起调，压测时看go tool pprof <binary><profile></profile></binary>里 goroutine block 和 syscall wait 时间占比 - 超过 500 个 worker 且任务轻量（sync.Map 分片任务队列
别让 context.WithTimeout 包裹整个 Submit 调用
常见错误是把超时套在 pool.Submit(...) 外层，结果任务进队列成功，但还没执行就超时返回——用户以为任务丢了，其实它还在池里排队。
正确做法：超时控制必须下沉到 task 内部，或者用带 deadline 的 channel select：
select {
case p.tasks <p>性能影响：每次 Submit 做 timeout select 有微小开销，但比丢任务或阻塞调用方强得多。如果池满是常态，说明任务处理不过来，该扩容或降级，而不是掩盖问题。</p><p>容易被忽略的是：worker 里执行的函数如果自己没接 <code>context.Context</code>，timeout 就完全无效——池子只管调度，不管业务逻辑怎么跑。</p>golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
