用 chan struct{} 做信号量是最直接、最轻量的限流方式：通过带缓冲的 chan struct{} 模拟信号量，初始化时设置容量为最大并发数，goroutine 需先获取令牌（写入）才能执行，抢不到则阻塞。
用 chan struct{} 做信号量是最直接、最轻量的限流方式
Go 没有内置“最大 goroutine 数”开关，但用带缓冲的 chan struct{} 模拟信号量，是控制并发数最常用且零依赖的方案。它不干预调度器，也不引入第三方，本质是让 goroutine 在进入执行前“抢一个令牌”，抢不到就阻塞。
-
sem := make(chan struct{}, maxWorkers)初始化：容量即最大并发数，比如设为10就最多 10 个同时跑 - 启动前写入：
sem —— 若通道已满，goroutine 会在此处挂起，直到有空位 - 结束后必须释放：
（推荐放在 <code>defer中），否则令牌永久丢失，后续任务全卡住 - 别用
len(sem)判断剩余容量——它返回的是当前已写入但未读出的数量，不是“还能写几个”；可用cap(sem) - len(sem)算可用槽位，但通常没必要
为什么不能只靠 sync.WaitGroup 或 runtime.GOMAXPROCS
sync.WaitGroup 只负责等待完成，不控制并发；runtime.GOMAXPROCS 控制的是 OS 线程（P）数量，和 goroutine 并发数完全无关。设成 1 不会让 1000 个 goroutine 串行执行，它们仍会在单个 P 上快速切换，只是无法并行利用多核。
- 只用
WaitGroup而不加信号量 → 可能瞬间拉起几千 goroutine，内存暴涨、HTTP 连接池打满、文件描述符耗尽 - 误调
GOMAXPROCS(1)试图“限并发” → 实际吞吐反而下降，调度延迟升高，且对 I/O 密集型任务几乎无影响 - 正确组合是：
WaitGroup+sem：前者等全部结束，后者控实时并发
遇到卡死、超时或 panic 怎么办？必须配 context.Context
纯信号量无法应对 goroutine 卡死场景。比如某个 HTTP 请求 hang 住，它占着令牌不放，后续所有任务都在 sem 处无限等待——整个限流机制就瘫了。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 用
golang.org/x/sync/semaphore替代手写 channel：它支持Acquire(ctx, 1)，可传入带超时或取消的context - 例如：
ctx, cancel := context.WithTimeout(context.Background(), 5*time.Second)，超时后Acquire返回 error，不会阻塞 -
Release是安全的：即使任务 panic，defer s.Release(1)仍会执行，令牌不会泄漏 - 注意：不要在
Acquire失败后漏掉wg.Done()，否则wg.Wait()永远不返回
什么时候该用 Worker Pool 而不是动态启 goroutine？
当任务轻量、频次高、需要复用执行环境（如复用 DB 连接、HTTP client、TLS session）时，预启固定 worker 的池模型更合适；而信号量模式适合“一次一任务、无需状态共享”的场景，比如批量发请求、遍历处理文件。
立即学习“go语言免费学习笔记（深入）”；
- Worker Pool 核心是：
tasks chan Task（有缓冲任务队列）+ 固定数量的 for-range 消费 goroutine - 提交任务用
pool.Submit(func() { ... })，不直接启 goroutine，天然限流 - 要优雅关闭，必须监听
done chan struct{}或检查ok值，避免 worker 在通道关闭后 panic - 简单信号量适合 80% 的限流需求；Worker Pool 更重，但适合长期运行、需精细资源管理的服务
最容易被忽略的一点：底层资源（如 http.Transport）默认不限流。即使你用 sem 控制了 goroutine 数，若没设 MaxIdleConnsPerHost，仍可能瞬间打出上千 TCP 连接。限流必须端到端考虑——上层控 goroutine，并发下层控连接、文件句柄、DB 连接池。
