Go语言semaphore加权信号量_Golang并发数量控制详解-Golang-PHP中文网

semaphore.weighted.acquire(ctx, n) 中 n 是硬扣的许可单位数，非比例值；必须与后续 release(n) 严格匹配，否则计数错乱；剩余许可不足时阻塞等待或因 context 取消返回错误。

go语言semaphore加权信号量_golang并发数量控制详解

Go 里没有“加权信号量”这个独立概念，semaphore.Weighted 的 “Weighted” 指的是支持传入非 1 的 n 参数做单次申请/释放，并不是能动态拆分、按需调度的“智能权重”。它本质仍是整数计数器，Acquire 和 Release 的 weight 必须严格相等，否则状态立即错乱。

`semaphore.Weighted` 的 `Acquire(ctx, n)` 怎么用才不出错

这是最常写错的一环：以为 n 是“请求资源比例”，实际它是“硬扣 n 个单位许可”。只要当前剩余许可 ，就阻塞；扣完不拆分、不找零。

n 必须 ≥ 1，传 0 或负数直接 panic
初始化容量为 10 时，Acquire(ctx, 5) 成功后，剩余可用是 5；再 Acquire(ctx, 6) 会永久阻塞（除非有其他 goroutine Release）
如果函数可能多次调用 Acquire（比如重试逻辑），必须自己维护已申请总量，sem 不记录 per-goroutine 状态
context 取消时 Acquire 返回 ctx.Err()，此时没占用任何许可，绝不能 调用 Release

为什么 `Release(n)` 必须和 `Acquire` 的 `n` 完全一致

底层只是原子增减一个 int64 计数器，没有任何校验逻辑。Release 多了，计数器溢出变负，后续所有 Acquire 都立刻成功（许可数虚高）；Release 少了，计数器卡死在低值，新请求永远阻塞。

Golang Spf13 Viper

Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。

下载

Acquire(ctx, 3) 后写 Release(1) ×3 —— 行为合法但语义错误：你承诺还 3，却分三次还，中间若 panic 或 return，极易漏掉某次 Release
多个 goroutine 对同一 *semaphore.Weighted 实例混用不同 n 值 Release —— 不 panic，但计数器彻底不可信
正确姿势：用 defer sem.Release(3)，且只在 Acquire 成功后注册

`chan struct{}` 手写 vs `x/sync/semaphore`：什么时候该选哪个

两者都能控并发，但适用边界很清晰：要不要响应 context 取消？要不要超时等待？是否需要精确到非 1 权重？

纯固定并发上限（如“最多 5 个 HTTP 请求同时发”）：用 make(chan struct{}, 5) 更轻量，无依赖，行为透明，性能略优
需要带超时或取消（如“最多等 300ms 拿到许可”）：必须用 semaphore.Weighted，因为裸 channel 无法响应 ctx.Done()
需要混合权重（大任务占 3、小任务占 1）：只能用 semaphore.Weighted；但注意，这不是“优先级调度”，只是计数器加减，等待队列不保证 FIFO
别把 chan struct{} 封装成带 TryAcquire 的结构体——它天然不支持非阻塞尝试，硬加 select + default 会破坏语义一致性