不能裸用make(chan struct{}, N)，因其仅为带缓冲通道，无自动释放、panic防护和WaitGroup协同机制，漏释放、panic未recover或WaitGroup错位均会导致卡死或泄漏。
直接用 make(chan struct{}, N) 控制并发上限最常用，但漏掉释放、panic 未 recover、sync.WaitGroup 配合错位，三者任一都会让程序卡死或资源泄漏——这不是偶发问题，是裸写信号量的必然风险。
为什么不能只靠 make(chan struct{}, N) 裸用
它本质是计数器 + 阻塞，不是“调度器”。满时写操作阻塞，空时读操作阻塞，仅此而已。常见翻车点：
sem 写在 goroutine 外部（比如循环里先写再启 goroutine），导致多个 goroutine 竞争同一槽位，<code>sync.WaitGroup.Add(1)可能被重复调用- 任务 panic 后没
defer func() { ，令牌永久丢失，后续所有 goroutine 在 <code>sem 处无限等待 - 用
len(sem)判断“还剩几个可用”，其实它返回的是已占未放数量，真正剩余是cap(sem) - len(sem)，但一般没必要查——你只要确保每次获取后必释放就行 - 把
sem声明在 for 循环内，每个 goroutine 拿到的其实是不同实例，完全失效
怎么安全地用 golang.org/x/sync/semaphore
这是 Go 官方维护的信号量实现，比裸 channel 多三样关键能力：支持 context.Context、可非阻塞尝试、panic 时仍能释放。初始化和使用必须严格按顺序：
- 全局单例创建：
sem := semaphore.NewWeighted(5)，参数必须是正整数，别传 0 或负数 - 每次获取前检查上下文：
if err := sem.Acquire(ctx, 1); err != nil { return }，若 ctx 已取消，立刻退出，不执行业务逻辑 - 释放必须用
defer sem.Release(1)，且 defer 要写在 goroutine 最开头，哪怕中间 panic，Go runtime 也会执行 - 想快速失败（如 HTTP 429）就用
sem.TryAcquire(1)，它不等、不看 context，成功返回 true，否则 false
什么时候该换 worker pool 而不是只加信号量
信号量只回答“能不能启动”，不解决“谁来跑”“跑几次”“失败了怎么办”。一旦出现以下任意一种情况，就得升维：
立即学习“go语言免费学习笔记（深入）”；
- 任务含外部调用（HTTP/DB），需要复用连接池或 client 实例，避免反复建连
- 要控制排队行为：比如积压超 1000 个任务就拒绝新请求，而不是让它们一直等着
- 某些任务长期 hang（如第三方接口无响应），光靠信号量无法主动熔断或超时 kill
- 需要统计指标：当前运行数、排队中数量、平均耗时、失败率
这时候推荐 github.com/panjf2000/ants，它预启固定数量 goroutine 持续消费任务队列，内置 panic 捕获、超时控制、动态伸缩，但注意别把任务 channel 设成无缓冲——否则 submit 会立刻阻塞，失去背压缓冲能力。
