答案是：因为 struct{} 通道仅靠缓冲区长度表示可用许可数，获取需发送（填充缓冲区）、释放需接收（腾出槽位），若漏掉一次
用 make(chan struct{}, N) 实现并发限制时，为什么一漏释放就卡死
因为 struct{} 通道没有值、不占内存，只靠缓冲区长度做“令牌桶”，但它的释放完全依赖手动 `len(sem) 永远比 cap(sem) 小 1，后续所有新任务都会在 `
常见错误写法：
- 把 `
- 在匿名函数中闭包捕获循环变量，导致多个 goroutine 共享同一个 `
- 用 `select { case
正确做法必须是：每个 goroutine 内部最外层加 defer func() { ，且显式传参或避免闭包引用。
semaphore.NewWeighted 初始化和使用要注意什么
Go 1.21+ 官方推荐用 golang.org/x/sync/semaphore，它本质是带权重的信号量，panic 时 defer sem.Release(1) 仍会执行，令牌不泄漏。
初始化和调用关键点：
- 参数必须是
int64类型，别传0或负数，否则 panic -
sem.Acquire(ctx, 1)必须检查返回error；若 ctx 超时或取消，会立刻返回context.DeadlineExceeded，此时业务逻辑必须中止，不能继续执行 -
sem.Release(1)必须放在 goroutine 内部最外层defer，不能写在 handler 函数结尾——否则 panic 时不会触发 - 全局单例：不要每次 HTTP 请求都 new 一个，应随 server 生命周期初始化一次
什么时候该放弃信号量，改用 worker pool
信号量只回答“现在能跑几个”，不负责“谁来跑”“挂了怎么办”“积压了怎么拒”。一旦遇到这些情况，就得升维：
- 任务积压时想主动拒绝（而非让调用方无限等待），需要带缓冲的任务队列 + 显式拒绝逻辑，比如
select { case jobs - 要监控当前运行数、排队长度、平均耗时，得暴露
len(pool.tasks)和cap(pool.tasks)等指标，信号量本身不提供这些 - 某些任务可能长期 hang（如第三方接口无响应），光靠信号量无法熔断，必须结合
context.WithTimeout在任务内部控制 - goroutine panic 后需自动 recover 并释放资源，否则 worker 退出，池子实际容量持续缩水
推荐用 github.com/panjf2000/ants，它预启固定数量 goroutine 持续消费任务队列，支持 panic 捕获、超时、动态伸缩；但注意别把任务队列设成无缓冲 channel（make(chan func())），那等于没缓冲，一满就阻塞提交方。
并发数设多少才算合理
不是越大越好，得对齐真实瓶颈：
- IO 密集型（HTTP/DB）：估算目标服务吞吐上限 × 单次平均耗时。例如对方 API QPS 上限 300，平均延迟 150ms → 理论并发 ≈ 45，建议从 40–60 开始压测
- CPU 密集型（加解密、图像处理）：一般不超过
runtime.NumCPU()，再多只会增加调度开销 - 混合型或不确定场景：先设 10，用
go tool pprof观察 goroutines 数量曲线和 scheduler latency，再逐步上调 - 特别注意：文件句柄、数据库连接池、HTTP client 的
MaxIdleConns等底层资源，往往比 goroutine 数更早成为瓶颈
真正容易被忽略的是：并发控制必须和任务生命周期绑定。信号量或 worker pool 若脱离 context、不处理 panic、不配超时，迟早卡死或泄漏。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
