Go中无原生信号量，推荐用带缓冲的chan struct{}模拟：缓冲长度即最大并发数，发送struct{}获取许可，接收释放；须用select防阻塞，避免mutex+计数器或time.Sleep等错误方式。
Go里没有叫“信号量”的原生类型，别直接搜 semaphore
Go官方标准库不提供 semaphore 类型，也没有 acquire()/release() 这类方法。很多人卡在这一步，以为必须自己手写计数器+互斥锁——其实大可不必。Go推荐用更轻量、更符合其并发模型的方式替代：用带缓冲的 chan struct{} 模拟信号量行为，既安全又无锁竞争。
典型错误是试图用 sync.Mutex + 计数器手动管理，结果写出死锁或竞态；或者误用 time.Sleep 做粗粒度限速，完全偏离“基于信号量”的语义（即资源许可制，非时间片轮转）。
- 缓冲通道长度 = 最大并发数，发送空结构体占位即“获取许可”，接收即“释放”
- 避免用
int类型通道——它可能被意外读写或参与算术，chan struct{}语义清晰且零内存开销 - 务必用
select+default或带超时的select，防止 goroutine 永久阻塞在满通道上
用 buffered channel 实现并发速率控制的最小可行代码
以下是一个控制 HTTP 请求并发数为 3 的真实可用片段，不是玩具示例：
// 控制最大 3 个并发请求
sem := make(chan struct{}, 3)
<p>for _, url := range urls {
sem <- struct{}{} // 获取许可，阻塞直到有空位
go func(u string) {
defer func() { <-sem }() // 必须确保释放，用 defer 最稳妥
resp, err := http.Get(u)
if err != nil {
log.Println("fail:", u, err)
return
}
defer resp.Body.Close()
// 处理响应...
}(url)
}注意：defer func() { 写法比裸写 <code> 更可靠——即使中间 panic 也能释放许可。如果业务逻辑可能 panic（比如 JSON 解析失败），这点很关键。
立即学习“go语言免费学习笔记（深入）”；
- 不要把
sem定义在循环内，否则每个 goroutine 拿到的是不同通道 - 不要用
len(sem)判断剩余容量——它不准确，因为 len 是瞬时快照，且无法反映正在进出的 goroutine - 若需动态调整并发数，得重建通道并迁移等待中的 goroutine，成本高；建议启动前定好值
和 sync.WaitGroup + time.Sleep 混用会破坏信号量语义
有人想“既要并发控制，又要每秒最多 N 次”，于是把 sem 和 time.Sleep 套在一起，结果发现吞吐不稳定、甚至卡死。这是因为：sem 控制的是**同时活跃的 goroutine 数量**，而 time.Sleep 控制的是**发起请求的时间间隔**——两者目标冲突。
真正需要“QPS 限制”时，应该用令牌桶（如 golang.org/x/time/rate.Limiter），而不是硬套信号量。混用会导致：
- goroutine 在
sem上排队时，time.Sleep被跳过或错位 - 短任务快速释放许可，长任务拖住通道，实际并发远低于设定值
- 无法区分“因限速等待”和“因资源耗尽等待”，监控和调试困难
如果必须组合，先用 rate.Limiter 控制请求发起节奏，再用 sem 控制下游服务连接池大小——这是分层设计，不是叠加。
生产环境要注意 channel 关闭和泄漏风险
信号量通道本身不该关闭。一旦对已关闭的 chan struct{} 执行 sem ，会 panic；执行 <code> 则立即返回零值（即 <code>struct{}），导致许可“凭空多出一个”。这在长期运行的服务中极易引发超发。
- 永远不要调用
close(sem)—— 它不是用于通信的通道，而是资源计数器 - 确保每个
都有对应 <code>sem ，尤其注意 error 分支是否遗漏 <code>defer或提前 return - 若需优雅退出（如服务 shutdown），应配合
context.WithCancel中断等待中的 goroutine，而非关闭通道
最隐蔽的问题是：goroutine 启动后还没走到 sem 就 panic 了，导致许可永久丢失。这时唯一办法是用带超时的获取逻辑，或改用封装好的第三方库（如 <code>golang.org/x/sync/semaphore，但它本质仍是 channel 封装）。
