Go标准库无内置Semaphore，需用带缓冲的chan struct{}手动实现：如make(chan struct{}, 5)限制最大5并发，发送空结构体获取许可，天然支持select超时。
Go里没有内置的Semaphore类型，得自己造
Go标准库不提供 Semaphore 类型，sync 包里只有 Mutex、WaitGroup、Cond 这类基础同步原语。想限制对外部依赖（比如HTTP下游、数据库连接、第三方API）的并发调用数，必须基于 chan 或 sync.Mutex + 计数器手写一个轻量信号量。
推荐用带缓冲的 chan struct{} 实现：它天然阻塞、无内存分配、性能好，且能直接参与 select 超时控制。
- 缓冲大小即为最大并发数，例如
make(chan struct{}, 5)表示最多5个goroutine同时进入临界区 - 获取许可：向 channel 发送一个空结构体 ——
sem - 释放许可：从 channel 接收一次 ——
<-sem - 别用
close(sem)，会导致后续发送 panic；也不要用len(sem)判断剩余容量，它不反映实时可用数（因发送/接收非原子）
用信号量包装HTTP客户端调用时要注意超时和上下文传播
微服务调用外部依赖时，不能只靠信号量限流，还得结合 context.Context 控制单次请求生命周期。否则一旦下游卡住，goroutine 就会永久阻塞在 sem 或 <code>http.Do() 上。
正确做法是把信号量获取和 HTTP 请求都放进同一个 select 块，共享超时或取消信号：
select {
case sem <- struct{}{}:
// 获取到许可，发起请求
resp, err := client.Do(req.WithContext(ctx))
<-sem // 释放
return resp, err
case <-ctx.Done():
return nil, ctx.Err()
}- 不要先获取信号量再启动
http.Client调用 —— 这样ctx对信号量等待无效 - 如果使用
http.DefaultClient，记得设置Timeout或用context.WithTimeout，否则信号量可能被长期占用 - 信号量 channel 本身不感知 context，所以必须显式用
select把等待和 context 绑定
多个下游服务该共用一个信号量还是各自独立？
取决于下游的稳定性、错误传播影响和业务隔离要求。共用信号量看似省资源，但实际风险高：
- 如果 A 下游出问题导致信号量耗尽，B 下游的健康请求也会被拒 —— 违反故障隔离原则
- 不同下游的合理并发阈值不同（比如 Redis 可能设 20，而某个慢 API 只能设 3），硬塞进同一个 channel 会误伤
- 监控维度模糊：无法区分是哪个依赖拖垮了整体并发能力
建议按下游域名、服务名或用途划分信号量实例，例如：
redisSem := make(chan struct{}, 20)
paymentApiSem := make(chan struct{}, 3)
notificationSem := make(chan struct{}, 10)这样既能精准控流，也方便后续接入 metrics（比如暴露 len(paymentApiSem) 当前占用数）。
别忽略信号量初始化和生命周期管理
信号量本身是值类型，但作为限流器必须全局唯一、长期存活。常见错误包括：
- 在 handler 函数里每次新建
make(chan, N)—— 每次调用都重置，完全失去限流意义 - 把信号量放在 struct 里却没做 sync.Once 初始化，导致并发创建多个实例
- 用完不回收或未测试 panic 场景下的释放逻辑（比如 HTTP 请求中途 panic，
<-sem没执行）
稳妥做法是定义包级变量 + init() 或首次访问时初始化，并用 defer 确保释放：
func callExternal(ctx context.Context) error {
select {
case sem <- struct{}{}:
defer func() { <-sem }()
case <-ctx.Done():
return ctx.Err()
}
// ... 实际调用
}真正难的不是实现信号量，而是判断每个下游该设多少并发数——这得靠压测、错误率观察和熔断反馈反复调优，代码只是执行层。
