Go语言无内置信号量，推荐轻量场景用chan struct{}（如sem := make(chan struct{}, 5)），通用生产场景必用golang.org/x/sync/semaphore。
Go 语言没有内置 semaphore 类型，直接搜 “Go semaphore” 会踩进一堆用 chan int 或手写 sync.Mutex + counter 的坑里——这些实现要么语义错、要么不响应 cancel、要么在高并发下饿死。真正该用的只有两个选择：轻量场景用 chan struct{}，通用生产场景必须用 golang.org/x/sync/semaphore。
用 chan struct{} 实现最简信号量
这是最 Go 风格、零依赖、性能最好的方式，适合固定粒度（每次占 1 单位）、无需超时/取消的场景。
- 初始化：
sem := make(chan struct{}, 5)表示最多 5 个 goroutine 并发 - 获取许可：
sem —— 阻塞直到有空槽；别写成 <code>sem 或 <code>sem ，<code>struct{}零内存、语义唯一 - 释放许可：
—— 必须和 acquire 成对；千万别在 <code>defer外提前写，否则 panic: recv on closed channel - 常见错误：
close(sem)是致命操作，信号量 channel 永远不该 close - 封装建议：包一层
Semaphore结构体，把Acquire()和Release()方法收口，避免裸 channel 被误用
golang.org/x/sync/semaphore.Weighted 的正确调用姿势
这是官方维护的扩展包，支持 context、权重、可中断等待，是 IO 密集型服务（如 HTTP client 限流、DB 连接池）的唯一推荐方案。
- 安装：
go get golang.org/x/sync/semaphore（Go 1.19+ 默认可用） - 创建：
sem := semaphore.NewWeighted(10)，注意参数是int64 -
Acquire(ctx, n)：阻塞获取 n 单位许可；若 ctx 已 cancel 或 timeout，返回ctx.Err()，此时**不占用许可，也不用 Release** -
TryAcquire(n)：立刻返回 bool；别把它当“轻量 Acquire”用——失败时必须显式处理退避、丢弃或重试逻辑，否则业务直接跳过关键步骤 - 释放必须严格配对：
Acquire(ctx, 3)后只能Release(3)，不能拆成三次Release(1)；重复 Release 或跨 goroutine Release 会导致计数器溢出、后续永久阻塞
为什么不能用 sync.Mutex + int 手写信号量
它看起来简单，但破坏了 Go 运行时的调度契约，实际项目中几乎必然出问题。
立即学习“go语言免费学习笔记（深入）”；
- 无法响应
context.Context：超时或 cancel 时，等待 goroutine 仍卡在for !available { time.Sleep(...) }里忙等 - 唤醒不保证公平：channel 的等待队列由 runtime 统一管理，而手写锁+条件变量容易漏掉
Cond.Broadcast()或陷入虚假唤醒循环 - panic 风险高：忘记加锁、解锁顺序错、或在 panic 恢复路径里漏掉 unlock，都会导致整个程序锁死
- 性能更差：每次 acquire/release 都要走 mutex 加锁路径；而
chan struct{}在无竞争时接近原子操作
最容易被忽略的释放陷阱
90% 的信号量卡死问题，不是 channel 本身的问题，而是许可没归还。这不是理论风险，是高频线上事故。
- 函数有多个
return分支？defer sem.Release(1)必须紧跟在sem.Acquire()后面，且不能包裹在 if/else 里 - 函数可能 panic？
defer是唯一能覆盖 panic 路径的机制；裸写sem.Release(1)在 panic 时根本不会执行 - 用了
TryAcquire却没检查返回值？失败时调用Release会 panic: negative semaphore count - 动态调整并发数？别试图改 channel 缓冲大小（不可变），也不要关旧 channel 开新 channel —— 没有原子切换，必竞态
真正的难点从来不在“怎么写”，而在“怎么确保每一次 acquire 都有且仅有一次对应 release”。哪怕用了 x/sync/semaphore，只要漏掉一个 defer，整个服务的并发能力就会随时间线性衰减——这点比语法细节重要得多。
