go标准库sync包无信号量，官方推荐使用golang.org/x/sync/semaphore；需用int64初始化newweighted，acquire成功后必须由同goroutine按相同权重release，且须检查error并及时返回。
为什么标准库没有 semaphore，而必须用 golang.org/x/sync/semaphore
Go 标准库 sync 包里压根没有 semaphore 类型——只有 Mutex、WaitGroup、Cond 这些底层原语。有人用 make(chan struct{}, N) 模拟，但它不是信号量：不响应 ctx.Done()、无法超时、TryAcquire 得自己套 select + default，且 panic 后极易漏释放，导致许可永久卡死。官方明确推荐用 golang.org/x/sync/semaphore，它是语义完整、panic 安全、context 友好的唯一正解。
如何正确初始化和使用 semaphore.Weighted
semaphore.NewWeighted 的参数是最大“权重总和”，不是并发 goroutine 数量。传 int 会编译失败（Go 1.21+ 要求 int64），传 0 或负数直接 panic。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
-
sem := semaphore.NewWeighted(5)表示最多允许 5 单位权重被占用 -
sem.Acquire(ctx, 1)是最常用模式；若真需非单位权重（如大任务占 2），必须确保所有路径都严格按权重配对释放 -
sem.CurrentCount()返回的是“已分配权重总和”，不是活跃 goroutine 数——混用权重时监控值会偏离直觉
Acquire 和 Release 的调用契约不能错
Acquire 成功才产生有效租约，Release 必须由同一 goroutine 调用，且参数必须与 Acquire 申请数量完全一致。错配会破坏计数器，且无任何运行时校验。
- 错误：
Acquire(ctx, 3)后拆成三次Release(1)—— 语义错误，虽不 panic，但后续等待逻辑失效 - 危险：跨 goroutine 调用
Release—— 虽线程安全，但租约归属混乱，可能让新请求拿到已被逻辑释放的许可 - 致命：
Acquire返回 error（如context.Canceled）后仍调用Release—— 未定义行为，极大概率引发 panic 或状态错乱 - 推荐写法：
defer sem.Release(n)紧跟在Acquire成功之后，确保 panic 或提前 return 也能释放
HTTP handler 中嵌入信号量的典型坑
信号量实例必须是全局或 server 级生命周期。在 handler 函数内每次新建 semaphore.NewWeighted(5)，等于每请求都初始化一个独立信号量，完全失去限流意义。
- 正确做法：声明为包级变量或注入到 handler 结构体中，复用同一个实例
- 常见翻车：用
select等待sem但没处理ctx.Done()分支，客户端断开后 goroutine 仍卡在 channel 发送，许可持续被占 - 务必检查
Acquire返回的 error：只可能是context.Canceled或context.DeadlineExceeded，失败必须立刻返回（如http.Error(w, "too busy", http.StatusServiceUnavailable)），不能忽略或继续执行
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
