通道信号量最稳，因其基于带缓冲channel实现硬限流，写入阻塞即生效，天然配对无竞态，不依赖defer或外部逻辑，panic时仍能确保许可释放，避免资源泄漏。
热路径必须硬限制 goroutine 并发数，不能靠 runtime.GOMAXPROCS 或手写计数器，否则会瞬间打垮下游或触发 OOM。
为什么热路径用 channel 信号量最稳
热路径（比如 HTTP handler、消息消费循环、高频定时任务）特点是：单位时间触发频次高、goroutine 启动不可控、一旦失控就雪崩。这时候用 make(chan struct{}, N) 是最轻量且可靠的硬限流方式——它天然配对、无竞态、不依赖 defer 外部逻辑。
- 缓冲大小
N就是并发上限，写入阻塞即限流，不用额外判断 - panic 不影响释放：只要
写在 defer 里，哪怕业务 panic，channel 接收仍会执行 - 不要把
sem声明在循环内，否则每个 goroutine 拿到的是独立实例，完全失效 - 若热路径需响应取消（如超时退出），别只传
context.Background()给Acquire，要把同一ctx透传进业务逻辑
Go 1.21+ 热路径优先用 sync.Semaphore
标准库 sync.Semaphore 在热路径中比 channel 更适合——它支持带权重、可取消、能统计当前占用数，且底层基于 CAS，无内存分配压力。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 初始化必须用
semaphore.NewWeighted(int64(n))，注意参数类型是int64，传int会隐式转换但易出错 -
sem.Acquire(ctx, 1)必须检查返回 error；ctx.Err() != nil时直接跳过，别起 goroutine -
sem.Release(1)务必放在函数最外层defer，不是 goroutine 内部嵌套 defer - 别在热路径里调
sem.CurrentCount()做条件分支——它非原子，且频繁调用有性能损耗
热路径千万别碰的三个坑
这些做法在压测或流量突增时一定会暴露：
- 用
sync.Mutex+ 计数器：漏Unlock、panic 后未恢复、取消不感知，三者任一都会导致 goroutine 泄漏 - 设
runtime.GOMAXPROCS(2)以为能限并发：这只是调度器线程数，10 万个 goroutine 仍会排队跑满 CPU - 任务 channel 缓冲设太大（如
make(chan Job, 10000)）：掩盖 worker 处理慢问题，内存先爆，下游后崩
真正难的不是写对第一版限流，而是确保 panic、cancel、timeout、重试这四类边界都被覆盖——尤其热路径里一个没兜住，整条链路就卡死。建议所有 worker 函数开头加 defer func() { if r := recover(); r != nil { log.Printf("panic in hot path: %v", r) } }()，再配合 sem.Release。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
