semaphore.Weighted.Acquire(ctx, n) 中 n 是硬扣的许可单位数，非比例值；必须与后续 Release(n) 严格匹配，否则计数错乱；剩余许可不足时阻塞等待或因 context 取消返回错误。
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)会永久阻塞（除非有其他 goroutineRelease） - 如果函数可能多次调用
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 权重？
立即学习“go语言免费学习笔记（深入）”；
- 纯固定并发上限（如“最多 5 个 HTTP 请求同时发”）：用
make(chan struct{}, 5)更轻量，无依赖，行为透明，性能略优 - 需要带超时或取消（如“最多等 300ms 拿到许可”）：必须用
semaphore.Weighted，因为裸 channel 无法响应ctx.Done() - 需要混合权重（大任务占 3、小任务占 1）：只能用
semaphore.Weighted；但注意，这不是“优先级调度”，只是计数器加减，等待队列不保证 FIFO - 别把
chan struct{}封装成带TryAcquire的结构体——它天然不支持非阻塞尝试，硬加select+default会破坏语义一致性
监控和调试时最容易误读的指标
sem.CurrentCount() 返回的是“已分配权重总和”，不是“正在运行的 goroutine 数量”。如果你混合用了 Acquire(ctx, 1) 和 Acquire(ctx, 3)，这个数字完全无法对应到真实请求粒度。
- 想看实时并发数？别依赖
CurrentCount()，改用外部计数器 + mutex，或者用 pprof label 标记 goroutine 类型 - 想查谁卡住了？
runtime.Stack()里搜semaphore.*Acquire调用栈，但注意：它只显示阻塞点，不显示已持有者是谁 - 日志里记
Acquire成功时的n值，比只记“获取成功”有用得多——能快速定位是不是某些大请求把槽位吃死了
