Go 官方标准库不提供 semaphore 类型，应使用 golang.org/x/sync/semaphore；Acquire 阻塞等待许可，TryAcquire 立即返回；必须严格配对申请与释放，且由同一 goroutine 执行；适用于 I/O 密集型资源限流，非任务调度。
Go 里没有 semaphore 类型，别直接搜 “Go semaphore”
Go 官方标准库不提供信号量（semaphore）类型，sync 包里只有 Mutex、RWMutex、WaitGroup、Cond 这些基础同步原语。有人误以为 channel 做带缓冲的“令牌桶”就是信号量——它能模拟，但行为和语义不等价，尤其在取消、超时、公平性上容易出问题。
实操建议：
- 用
golang.org/x/sync/semaphore—— 这是 Go 官方维护的扩展包，语义正确、支持上下文取消、可计数、线程安全 - 别自己用
chan struct{}手写“伪信号量”，除非你明确知道它不支持TryAcquire、无法响应ctx.Done()、且在高并发下可能饿死 - 安装命令：
go get golang.org/x/sync/semaphore
semaphore.Weighted 的 Acquire 和 TryAcquire 怎么选
核心区别：是否阻塞。不是“要不要等”，而是“等不等得及”——前者会挂起 goroutine 直到拿到许可或上下文取消；后者立刻返回成功/失败，不阻塞。
常见错误现象：Acquire 在无上下文或 timeout 场景下永久阻塞，导致 goroutine 泄漏；TryAcquire 被当成“轻量版 Acquire”，结果业务逻辑没处理失败分支，直接 panic 或跳过关键步骤。
立即学习“go语言免费学习笔记（深入）”；
使用场景与参数差异：
- 限流 HTTP handler：用
Acquire(ctx, 1)，配合http.Request.Context()，客户端断连时自动释放 - 后台批量任务调度：用
TryAcquire(1)快速判断能否执行，失败则退避重试或丢弃 - 注意
Acquire第二个参数是int64，支持一次申请多个单位（比如一个任务占 2 个许可），而TryAcquire只接受int64，不接受 context
释放许可必须配对，且只能由获取者调用
这是最容易被忽略的坑：许可不是“全局资源”，而是跟具体 goroutine 绑定的租约。忘记 Release、重复 Release、跨 goroutine Release 都会导致状态错乱——计数器溢出、死锁、或后续 Acquire 永远拿不到许可。
实操建议：
- 用
defer sem.Release(1)包裹临界区，确保无论函数如何退出都释放 -
Release参数必须和Acquire申请的数量一致，Acquire(ctx, 3)后必须Release(3)，不能拆成三次Release(1)（虽然不会 panic，但语义已错） - 不要把
*semaphore.Weighted当成可共享的“连接池管理器”传给多个 goroutine 并随意释放——它本身是线程安全的，但业务逻辑仍需保证“谁申请谁释放”的契约
性能和兼容性：比 channel 实现快，但别滥用
官方 semaphore.Weighted 底层用 sync.Mutex + runtime_Semacquire，比纯 channel 实现平均快 2–3 倍（尤其在争抢激烈时），且内存占用更可控。但它仍是同步原语，不是魔法。
容易踩的坑：
- 设太小（如
semaphore.NewWeighted(1)）等于串行化，吞吐掉到单核水平；设太大（如10000）失去限流意义，还浪费内存 - 在 CPU 密集型任务中用信号量控制并发，不如用 worker pool + channel 分发；信号量适合 I/O 密集型资源保护（如数据库连接、文件句柄、外部 API 配额）
- Go 1.19+ 支持
runtime/debug.SetMaxThreads，但信号量不感知该限制——它只管自己计数，不管系统线程是否耗尽
复杂点在于：信号量解决的是“资源可用性”问题，不是“任务调度”问题。真要控并发，往往得组合 semaphore + context + errgroup，而不是指望一个 Acquire 调用搞定所有边界。
