直接用 go func(){} 会因无节制创建协程导致内存暴涨、调度过载甚至栈溢出崩溃；正确做法是用 buffered channel 实现协程池，限制并发数并确保 worker recover panic。
为什么直接用 go func() {} 会出问题
协程（goroutine）开销虽小，但无节制创建仍会导致内存暴涨、调度器过载，甚至 runtime: goroutine stack exceeds 1GB limit 这类崩溃。真实场景中，比如并发拉取 10 万条 API 数据，若每条都起一个 goroutine，瞬间上十万协程，调度器根本来不及切片，CPU 和内存反而被拖垮。
真正需要的不是“无限开”，而是“可控流”：限制同时活跃的协程数，让任务排队等空闲 worker 处理。
常见错误现象包括：
- 程序启动后几秒就卡死或 OOM
-
pprof显示goroutine数量持续 >50k 且不下降 - HTTP 客户端报
too many open files（底层连接没及时复用/关闭）
用 buffered channel 实现最简协程池
不用第三方库，仅靠 Go 原生语法就能搭出可用的池子。核心是用一个带缓冲的 chan struct{} 当“许可证”，控制并发上限；每个 worker 从任务队列（chan func()）取活干。
立即学习“go语言免费学习笔记（深入）”；
实操建议：
- 许可证 channel 缓冲大小即最大并发数，例如
make(chan struct{}, 100)表示最多 100 个任务并行 - 任务 channel 不要设缓冲（或设小缓冲），避免任务积压在内存里不触发执行
- worker 必须用
for range持续读取任务，否则拿完一个就退出 - 记得在所有 worker 启动后 close 任务 channel，否则 range 永远阻塞
pool := make(chan struct{}, 100)
tasks := make(chan func(), 1000) // 缓冲可略大，防生产太快
<p>// 启动 worker
for i := 0; i < cap(pool); i++ {
go func() {
for task := range tasks {
pool <- struct{}{} // 拿许可
task()
<-pool // 还许可
}
}()
}</p><p>// 提交任务
for i := 0; i < 10000; i++ {
tasks <- func() {
// 实际工作，比如 http.Get(...)
}
}
close(tasks)worker 函数必须处理 panic，否则整个池子会静默失效
只要任意一个 worker 内部 panic 且未 recover，该 goroutine 就退出，池子可用 worker 数逐渐减少，最终任务全部堵在 channel 里——没有错误日志，没有崩溃，只有越来越慢。
所以每个 worker 的执行体必须包一层 recover：
- 不要只在最外层 defer recover，要放在
task()调用前后 - panic 信息建议打到日志，至少输出函数名和错误类型，否则排查无从下手
- 别忽略 recover 后的错误，更不要用
_ = recover()掩盖问题
go func() {
defer func() {
if r := recover(); r != nil {
log.Printf("worker panic: %v", r)
}
}()
for task := range tasks {
pool <- struct{}{}
defer func() { <-pool }()
task() // 这里可能 panic
}
}()实际工作中，任务函数常需返回结果或上下文，别硬塞闭包变量
很多人写 for i := range data { go func() { do(i) }() }，结果所有 goroutine 都用到了最后一个 i 值。协程池里同样危险：若把任务参数通过外部变量传进闭包，极易发生数据竞争或错乱。
正确做法是把参数显式传入函数值：
- 定义任务类型为
func(context.Context) error或func() (interface{}, error) - 提交时用
func() { do(data[i]) }立即捕获当前值，而不是共享变量 - 如果需收集结果，用带缓冲的
chan接收，别用全局 slice + mutex —— channel 本身已线程安全 - 注意 context 超时传递，避免某个慢任务拖垮整批处理
容易被忽略的一点：池子 shutdown 时，要等所有正在运行的 task 结束，再 close result channel，否则接收方可能漏数据或 panic on closed channel。
