能用，够快，但一漏释放就卡死，生产环境不建议裸写；用 make(chan struct{}, 10) 实现限流，写入占位、读出归还，满则阻塞，必须用 struct{} 避免语义不清和内存浪费。
用 chan struct{} 控制并发数：最轻量但最易翻车
直接上结论：能用，够快，但一漏释放就卡死，生产环境不建议裸写。
原理很简单：make(chan struct{}, 10) 创建一个容量为 10 的缓冲通道，每次 goroutine 启动前往里写一个 struct{}{}（占位），执行完再读一个（归还）。满时写操作自动阻塞，天然限流。
- 必须用
struct{}，别用chan int—— 后者容易误判 0 值、多占内存，且语义不清 defer func() { 必须写在 goroutine 内部，且显式传参；匿名函数里闭包 <code>sem没问题，但闭包item很可能出错- 别在
select里只写case 就开干 —— 如果任务 panic，<code>defer还没注册就退出，令牌永远丢失 -
len(sem)不是“剩余可用数”，是“已占未放”的数量；真要查可用槽位得用cap(sem) - len(sem)，但一般没必要
改用 golang.org/x/sync/semaphore：官方推荐，安全有保障
这是目前 Go 生态最稳妥的选择，由 Go 官方维护，支持上下文超时、权重、非阻塞尝试，panic 时也能保证释放。
初始化：sem := semaphore.NewWeighted(5)，参数是 int64，别传负数或 0。
立即学习“go语言免费学习笔记（深入）”；
-
sem.Acquire(ctx, 1)必须检查返回 error —— 若 ctx 超时或取消，会立刻返回context.DeadlineExceeded或context.Canceled，此时不能继续执行业务逻辑 - 务必配
defer sem.Release(1)，哪怕 handler panic，Go runtime 也会执行 defer，令牌不会泄漏 - 如果想快速失败（比如限流后直接返回 429），用
sem.TryAcquire(1)，它不阻塞、不等、不看 context，成功返回 true，否则 false - 别在每个 HTTP handler 里
new一个 semaphore —— 它该是全局单例，生命周期和 server 一致
什么时候该换 worker pool，而不是只做信号量？
信号量只管“同时跑几个”，不管“谁来跑”“跑几次”“失败了怎么办”。一旦你遇到这些情况，就得升维到 worker pool：
- 任务需要复用资源（如 DB 连接、HTTP client、TLS session）
- 要控制排队行为（比如任务积压时拒绝新请求，而非无限等待）
- 需统计指标（当前运行数、排队数、平均耗时）
- 任务执行时间差异大，某些长期 hang 住（比如第三方接口不响应），光靠信号量无法主动熔断
这时候推荐 github.com/panjf2000/ants：它预启固定数量 goroutine 持续消费任务队列，支持 panic 捕获、超时控制、动态伸缩。注意别把任务队列设成无缓冲 channel —— 容易 OOM；也别让 worker 数远小于任务量又不设缓冲，会导致任务被丢弃。
别混淆 runtime.GOMAXPROCS 和并发控制
runtime.GOMAXPROCS 控的是 OS 线程（P）数量，不是 goroutine 并发数。设成 1，1000 个 goroutine 仍会调度执行，只是不能并行利用多核 —— 它们全挤在一个 P 上快速切换。
真正影响并发上限的，只有你写的信号量、worker pool 或第三方库的配置项。
常见错误是看到 CPU 利用率低，就盲目调高 GOMAXPROCS，结果发现 HTTP 超时更多、DB 连接池打满 —— 因为问题根本不在 P 数，而在没控好 goroutine 数量本身。
最常被忽略的一点：限流之后，一定要有兜底观测。比如加个 pprof endpoint，定期看 goroutines 数是否缓慢上涨；或者用 semaphore 的 CurrentCount()（需自己封装）暴露指标。没有监控的限流，就像没刹车的车。
