goroutine暴增是资源失控而非语法错误：未设并发边界会导致内存溢出、超时和429错误，单个goroutine约2kb栈开销，10万并发即200mb内存，且下游限流常先于本地cpu被打穿。
goroutine暴增不是语法错，是资源失控
直接 for range tasks { go process(t) } 启动成百上千个 goroutine，大概率不会报编译错误，但会立刻触发 runtime: out of memory、大量 context.DeadlineExceeded 或下游返回 429 Too Many Requests。这不是代码写错了，而是没设边界——内存、文件描述符、数据库连接、HTTP 客户端连接池全被撑爆。
- 别依赖“Go 轻量所以随便开”：单个 goroutine 开销约 2KB 栈，10 万并发就是 200MB 内存，还没算堆分配
- 下游服务（如 API、DB）的限流阈值往往远低于本地 CPU 能力，先被打穿的是它，不是你
- panic 或提前 return 时若没释放信号量，后续所有任务永久阻塞在
sem 上
用 semaphore.NewWeighted 控制并发，别手写 channel
Go 1.21+ 推荐直接用官方 golang.org/x/sync/semaphore，比 chan struct{} 更安全，尤其适合微服务这种需长期稳定运行的场景。
- 初始化必须传
int64：sem := semaphore.NewWeighted(int64(8))，传8（int）会编译失败 -
Acquire(ctx, 1)必须在 goroutine 内部调用，并检查 error；若 ctx 已取消，应直接跳过任务，不要硬塞Release -
defer sem.Release(1)必须放在函数最开头，确保 panic 也能归还——这是唯一能防泄漏的位置 - 不支持动态调整容量，扩容需重建信号量，所以初始值要结合压测定（常见值：4–16，取决于下游瓶颈）
任务耗时差异大时，光靠信号量不够
如果一批任务里有的 100ms 完成，有的要 5s（比如混合了本地计算和远程 HTTP 请求），仅靠信号量会让快任务等慢任务腾出 slot，吞吐率断崖下跌。
- 加一层缓冲队列：
jobs := make(chan Task, 100)，容量按峰值流量 × 平均处理时间估算 - 启动固定 worker 数（如
runtime.NumCPU() * 2），每个 worker 循环select { case t := - 提交任务时用
select防阻塞：select { case jobs - 务必在所有任务发完后
close(jobs)，否则for range jobs永不退出
用 errgroup.Group 统一生命周期，别只靠 sync.WaitGroup
sync.WaitGroup 只能等完成，无法传播错误或响应取消；微服务里需要的是“任一失败即停、超时即退、错误可捕获”。
- 初始化：
g, ctx := errgroup.WithContext(context.WithTimeout(parentCtx, 30*time.Second)) - 提交任务：
g.Go(func() error { return process(ctx, task) })，内部必须检查ctx.Err()（如用http.NewRequestWithContext） -
g.Wait()返回第一个非 nil error，但其他 goroutine 不会自动停——得靠 ctx 通知它们主动退出 - 别在
g.Go里调用log.Fatal，它会 kill 整个进程，绕过 errgroup 的 cancel 机制
真正容易被忽略的，是任务内部对 ctx.Done() 的响应深度：HTTP client、database driver、自定义 I/O 都得显式传入 context，否则信号量释放了、errgroup 等完了，goroutine 还卡在 read tcp 上不动。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
