Go channel 作为 semaphore 时为什么容量判断失效

结论先说：cap(sem) 只能告诉你许可池的固定上限，len(sem) 只能告诉你某一瞬间缓冲区里排队了多少个令牌。把两者读出来，再决定是否发送，判断和发送之间存在竞态；真正可靠的上限应由带缓冲 channel 的发送直接承担。发送成功就是拿到许可，接收就是归还许可。

很多“容量判断失效”并不是 Go 没有限制住 channel，而是代码把观察值当成了预留结果。并发场景下，观察值很快就可能过期。

先看懂 channel 的两个数字

对 sem := make(chan struct{}, 3) 来说，cap(sem) 永远是 3，表示缓冲区最多容纳三个元素；len(sem) 表示此刻已经放进去、但尚未取出的元素个数。若当前 len(sem)==2，只能说明现在看见两个槽位被占用，不能承诺下一次发送一定不会阻塞。

为什么先判断容量会失效

问题通常长这样：

if len(sem) 

假设容量为 3，G1 和 G2 几乎同时读到 len(sem)==2，两者都会认为还有空间。G1 先发送成功后，G2 的发送就可能阻塞；如果代码把“判断通过”当作“已经拿到许可”，还会出现计数与实际工作不一致的问题。即使先读到的是 0，也不能保证后续发送必定立即成功，因为其他 goroutine 可能在这段时间占用最后一个槽位。

这也是为什么不要用 len(sem)==cap(sem) 轮询“满不满”，更不要用 len(sem) 推断“我可以安全发送”。channel 的同步点是通信本身，不是对长度的读取。

用发送获取、接收释放消除预判

把许可模型写成两个对称动作即可。发送放在真正开始受限工作之前，释放放在工作完成之后；用 defer 可以覆盖返回和错误路径：

var sem = make(chan struct{}, 3)

func handle(job Job) error {
    sem 

这里的关键不是把 struct{}{} 当成计数器，而是让 channel 的阻塞语义成为原子边界：发送要么完成并占用一个槽位，要么尚未完成，代码不会误以为已经获得许可。容量为 3 时，最多只有三个已经获取许可且尚未释放的工作。

不想等待时，用 select 表达策略

如果业务要求“没有空位就立即返回”，不要再用长度判断，而是用非阻塞 select：

func tryHandle(job Job) error {
    select {
    case sem 

最后检查四个边界：零容量 channel 会让发送等待接收者，不适合作为这种缓冲许可池；nil channel 的发送和接收会永久阻塞；释放必须和成功获取一一对应，不能在未获取时执行；不要关闭仍可能被发送的 semaphore channel，生命周期通常由持有者管理。

相关问题

为什么日志里的 len 看起来超过了预期？ len 反映的是采样瞬间的排队数，日志打印和其他 goroutine 的发送、接收没有绑定成一个业务动作，应该观察获取成功数和释放成功数，而不是拿两次长度做差。

channel semaphore 能保证任务一定按顺序执行吗？ 不能。它只限制同时持有许可的数量；多个发送者的调度顺序仍由运行时和具体阻塞时机决定，需要顺序语义时应另行设计。