go大规模任务并发控制核心是稳与可维护，需防goroutine暴增和下游过载；常用channel struct{}实现硬限流，如sem := make(chan struct{}, 10)作许可证池，发送占位、接收释放。
Go 处理大规模任务时，并发量控制不是选“要不要做”，而是“怎么做得稳、不崩、可维护”。核心目标就两个：一是不让 goroutine 数无节制暴涨，二是不让下游（API、DB、文件系统）被瞬间打垮。策略选择取决于任务类型、Go 版本、是否需要取消/超时、是否要返回错误等实际需求。
用 channel struct{} 实现轻量硬限流
这是最经典、最 Go 风格、兼容所有版本的做法。本质是把带缓冲的 channel 当作“许可证池”——容量就是最大并发数，发送即占用，接收即释放。
- 初始化：
sem := make(chan struct{}, 10)表示最多 10 个任务同时执行 - 每个 goroutine 开始前必须写入：
sem （阻塞直到有空位） - 务必在函数最外层用
defer func() { 归还，否则 panic 或提前 return 会导致许可证泄漏，后续所有任务永久卡住 - 别用
len(sem)判断可用数——它返回已占用数；剩余容量是cap(sem) - len(sem)，但一般不需要主动查 - 切忌 close(sem)，关闭后继续 send 会 panic，recv 会立即返回零值，彻底破坏限流逻辑
用 semaphore.NewWeighted 做安全可控的信号量（Go 1.21+ 推荐）
标准库原生支持，比手写 channel 更健壮，尤其适合对可靠性要求高的服务。
- 初始化必须传
int64：如限 8 并发，写semaphore.NewWeighted(int64(8))，传8会编译失败 -
Acquire(ctx, 1)必须在 goroutine 内调用，且必须检查 error；若 ctx 已取消或超时，应直接跳过任务，不要硬塞Release -
Release(1)一定要用defer放在函数入口处，确保 panic 后也能归还 - 支持权重：大任务可占 3 单位，小任务占 1 单位，但 Acquire 和 Release 的 weight 值必须严格一致，语义由业务自己定义
- 天然支持 context 取消、panic 安全、超时等待，无需额外封装
用 errgroup.Group + SetLimit 管理批量任务生命周期
当你的一批任务需要统一超时、响应 cancel、收集错误、并等待全部结束时，errgroup 是比裸信号量更省心的选择。它的 SetLimit 底层就是封装了 semaphore.NewWeighted。
- 启用限流：
g.SetLimit(8)，之后所有g.Go(...)调用都会受控 - 必须搭配带 timeout 的 context 使用：
eg, _ := errgroup.WithContext(ctx)，否则运行中无法中断 -
g.Wait()返回第一个非 nil error，但其他 goroutine 仍会继续运行；如需强中断，得靠 context 通知内部逻辑主动退出 - 别在
g.Go函数里用log.Fatal，它会终止整个进程，绕过 errgroup 的错误聚合和清理流程 - 注意：Go 1.21+ 才支持
SetLimit；旧版本需手动 wrap 或换方案
避免踩坑：常见误用与替代误区
有些做法看起来像限流，其实完全无效或南辕北辙。
- 别用 runtime.GOMAXPROCS 控制并发数：它只影响可运行的 OS 线程数（P 数），不是 goroutine 并发上限。设成 1 不代表任务串行，只是调度器一次只让一个 P 工作，上万个 goroutine 依然会排队、吃内存、压垮下游
-
rate.Limiter 不是并发控制器：它是令牌桶，管的是 QPS（单位时间请求数），不是“同时跑几个 goroutine”。100 个 goroutine 同时调
Allow()，前 burst 个全过，瞬时并发照样爆表 - 别用 time.Sleep 模拟耗时任务来测试限流：它不释放 OS 线程，可能掩盖真实 I/O 阻塞问题，导致压测结果失真
- 工作池（Worker Pool）更适合长期稳定任务：比如文件上传、日志处理。预启动固定数量 worker，共享输入 channel，天然形成“固定并发 + 无泄漏 + 易终止”的模型，比每个任务起 goroutine 更可控
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
