Go标准库无原生信号量，推荐使用golang.org/x/sync/semaphore而非chan struct{}模拟，因其支持上下文取消、超时、TryAcquire及panic安全释放；chan struct{}无法响应ctx.Done()、易漏释放致卡死，且不具权重与公平调度能力。
Go 标准库没有 semaphore 类型，必须用 golang.org/x/sync/semaphore —— 自己用 chan struct{} 模拟看似简单，但超时、取消、panic 安全、权重语义全得自己补，极易出错。
为什么不能直接用 chan struct{} 代替 semaphore.Weighted
它能“看起来像”信号量，但不是：不响应 ctx.Done()，TryAcquire 无法实现，高并发下可能饿死，且 panic 后容易漏释放导致永久卡死。最典型翻车是 HTTP handler 中用了 select 等待 channel，却没处理客户端断开，结果请求已丢、许可还在占用。
实操建议：
-
sem := make(chan struct{}, 10)初始化后，sem 是获取，<code><-sem是释放 —— 顺序写反或漏 defer 就死锁 - 别用
len(sem)判断是否可进：它返回已占用数，可用数是cap(sem) - len(sem) - 关闭该 channel 会导致后续接收 panic，永远不要
close(sem) - 如果需要超时或取消，必须手动套
select+time.After或ctx.Done()，逻辑膨胀且易漏
semaphore.NewWeighted 初始化和参数陷阱
初始化容量是最大并发“权重总和”，不是“goroutine 数量”。传 0 或负数会 panic；传 int(3) 而非 int64(3) 在 Go 1.21+ 会编译失败（sync.Semaphore 已入标库，但 x/sync 仍广泛兼容）。
立即学习“go语言免费学习笔记（深入）”；
常见错误现象：semaphore.NewWeighted(3) 后调用 Acquire(ctx, 5) 立即返回 semaphore.ErrNoResources，因为单次申请超过总容量。
实操建议：
- 绝大多数限流场景坚持用
Acquire(ctx, 1)和Release(1)，避免引入权重复杂度 - 若真需非单位权重（如大任务占 2 单位），务必确保所有业务路径都按权重配对释放，否则计数器失准
- 监控时用
sem.CurrentCount()得到的是“已分配权重总和”，不是活跃 goroutine 数 —— 一个Acquire(ctx, 3)和三个Acquire(ctx, 1)对该值影响相同
Acquire 和 Release 的调用契约
许可是“租约”，不是全局资源：Acquire 成功才产生有效租约，Release 只能由同一 goroutine 调用，且参数必须与 Acquire 申请数量严格一致。多放、少放、跨 goroutine 放、没拿到就放，都会破坏状态。
常见错误现象：Acquire 返回 context.Canceled 后仍调用 Release(1)，触发 panic；或 Acquire(ctx, 3) 后拆成三次 Release(1)，语义上已错（虽不 panic，但后续统计和等待逻辑失效）。
实操建议：
- 一律用
defer sem.Release(n)包裹临界区，确保 panic 也释放 -
Acquire返回非nilerror 时，**绝对不可调用Release** —— 没租约，何来释放 - 不要把
*semaphore.Weighted当连接池管理器到处传并随意释放；线程安全 ≠ 业务逻辑无约束 - HTTP handler 示例中，
ctx必须带 deadline：ctx, cancel := context.WithTimeout(r.Context(), 500*time.Millisecond)，传context.Background()等于主动放弃超时控制
性能与线上踩坑重点
官方 semaphore.Weighted 底层用 sync.Mutex + runtime_Semacquire，比纯 channel 实现快 2–3 倍，尤其在高竞争场景。但它不是银弹：滥用权重、忽略错误分支、误判 CurrentCount() 含义，会让监控失真、问题难定位。
最容易被忽略的点是：信号量只控制“并发请求数”，不等于“TCP 连接数”或“下游服务吞吐”。比如你设了 semaphore.NewWeighted(10)，但每个请求平均耗时 2 秒，那实际 QPS ≈ 5；若下游接口抖动到 10 秒，QPS 就跌到 1 —— 此时信号量本身没坏，但业务 SLA 已崩。真正要调的，往往是 timeout、重试策略、以及和 http.Transport.MaxConnsPerHost 的协同。
