Go 并发限流用 channel 还是 semaphore：取消、阻塞与公平性怎么选

批量抓取商品详情的时候，最容易碰到的问题从来不是“goroutine 跑的不够快”，而是瞬间涌来的大量任务直接打满下游连接池，把第三方接口直接冲垮。Go 里常用的两种限流实现分别是 buffered channel 和 golang.org/x/sync/semaphore，二者都能把并发数稳稳控制在设定的上限里，但在取消响应、加权资源分配和不同任务模型下的表现差异很大。

只需要限制“同时运行的同类任务总数”，优先选 buffered channel；需要响应 context.Context 取消、支持按权重占用资源，或者不想额外维护一组常驻 worker 的场景，选 semaphore.Weighted。

先把限流问题拆成三个约束条件

假设你写的服务一次要处理 500 个商品 ID，每个任务都要调用外部 HTTP 接口再写入数据库。真正需要管控的通常是三层逻辑：同时在途的请求总数、单个任务占用的资源量、上游发起取消后正在排队等待的任务能不能及时退出。

如果每个任务的资源消耗差不多，直接限制“最多 20 个并发”就足够了；如果图片下载任务的资源消耗是普通 JSON 接口的 3 倍，单纯用固定并发数做限流就会出现明显偏差。先别急着找第三方库，先把要管控的资源单位定义清楚。

buffered channel：简单场景好用的任务闸门

Go 官方文档本身就把 buffered channel 作为限制资源使用的直接方案。channel 的容量就是你设定的并发额度，执行任务前往里面发一个空结构体，任务执行完再把值读出来归还槽位就行。

type Limit struct {
    slots chan struct{}
}

func NewLimit(n int) *Limit {
    return &Limit{slots: make(chan struct{}, n)}
}

func (l *Limit) Run(task func()) {
    l.slots 

这个实现的好处是逻辑边界特别清晰：容量设成20，最多就有20个任务能穿过闸门。它也很适合对接固定worker池的场景：channel本身就是天然的任务队列，后续做关闭和资源回收的逻辑也很容易集中维护。

但它有个很容易被忽略的漏洞：如果发送操作正在等待空余容量，而上游调用方已经超时，普通写法没有对应的取消分支。批量任务被中止的时候，这些goroutine可能会一直挂在发送操作上无法退出。

func (l *Limit) RunContext(ctx context.Context, task func()) error {
    select {
    case l.slots 

加上 select 的判断逻辑后，channel 限流也能实现可取消等待。但代价是每个调用点都要遵守同一套约定，任务本身能不能响应取消，最终还是要看 task 的内部逻辑有没有做对应的兼容。

Weighted 信号量：当一个任务不等于一个配额时的解决方案

semaphore.Weighted 把“任务要占用多少资源”作为 Acquire 方法的入参。等待配额的过程中可以传入 context 对象，如果上下文提前结束，Acquire 会直接返回错误，不会改动信号量的当前状态。

sem := semaphore.NewWeighted(12)

func fetch(ctx context.Context, weight int64, id string) error {
    if err := sem.Acquire(ctx, weight); err != nil {
        return err
    }
    defer sem.Release(weight)

    return loadProduct(ctx, id)
}

举个实际例子：普通商品详情请求占1个配额，需要同步拉取大图的任务占3个配额，全局总配额预算设成12。这种方式管控的是下游接口的实际压力，而不是单纯的goroutine数量。

它的另一个优势是调用方不需要提前维护一组常驻 worker。官方示例里的写法就是直接启动任务，调用 Acquire 拿到配额，执行逻辑，最后调用 Release 归还资源，等所有任务跑完再做收尾就行。不过如果一次性启动大量goroutine让它们卡在信号量等待，还是会产生额外的调度和内存开销；任务量级特别大的场景，搭配队列模型会更合适。

取消、阻塞与公平性：这几点才是两者真正拉开差距的地方

两种方案都有可能产生阻塞，区别只在于阻塞点暴露的位置不同。channel的发送方会阻塞在发送操作上，Weighted信号量的调用方会阻塞在Acquire方法上。只要你把取消分支的逻辑写全，二者都能正常结束等待，但没有任何一种实现会自动帮你处理任务取消后的业务回滚逻辑。

公平性这块也不要想当然。多个goroutine同时等待配额的时候，Go内部调度顺序和任务到达时机都会影响谁先拿到可用名额。更麻烦的是Weighted模式下的大权重请求，可能要等多个小权重任务全部释放后才能拿到足够的总额度；如果业务要求绝对不能让小任务长期插队，应该在上层单独实现明确的FIFO队列，不要直接把信号量当成完整的任务调度器来用。

验收的时候可以设计一个总配额为12的测试用例：提交8个权重为1的任务和2个权重为3的任务，记录每个任务Acquire成功的时间、上下文取消的时间、Release之后的剩余在途任务数。校验的重点不是谁“看起来更公平”，而是取消操作执行后有没有出现配额泄漏的问题。

按实际场景做选择，不要单纯按API数量选方案

• 固定数量的同质任务场景：直接用buffered channel就可以，尤其是你项目里已经有现成的worker队列的情况。
• 请求必须支持被上游超时打断：两种方案都能实现，但要记得把context传递到等待点和实际I/O操作的内部。
• 不同任务的资源消耗差异很大：选Weighted信号量，并且把权重定义成和下游资源消耗对应的可解释单位。
• 任务数量特别大的场景：先给队列加上长度限制，再搭配信号量做限流，不要无限制的启动goroutine。

// 选择 Weighted 的最小判断
// 1. 是否需要等待时响应 ctx.Done？
// 2. 是否存在 weight > 1 的任务？
// 3. 是否能保证每次成功占用后都 defer Release？
// 三个问题只要有两个答案为“是”，优先评估 Weighted。

常见坑点与上线前检查清单

最常见的资源泄漏问题都来自“拿到配额后提前return没释放资源”，所以占用资源成功后要立刻写下 defer Release 逻辑，或者及时归还channel的空槽位。另一个常见坑是只在外层任务做了限流，却允许任务内部再启动无界goroutine，这种写法看起来有闸门控流，实际压力已经直接绕过去了。

1. 用计数器或者链路追踪记录同时在途的任务数，确认峰值不会超过设定的容量或者总权重上限。
2. 让一批正在等待的任务统一触发超时，检查返回值是不是 context deadline exceeded，同时确认等待队列里的任务数量正常下降。
3. 人为构造任务拿到配额后直接报错的场景，确认defer路径仍然能正常归还资源。
4. 压测结束后等一个完整的清理窗口，检查goroutine数量、连接池使用量和队列长度全部回到初始基线。

相关问题

channel 限流是不是一定比 semaphore 快？

不能直接下这个定论。固定配额下两者的性能差异通常远小于任务本身的I/O开销，应该用实际的目标负载来测量等待延迟、资源分配情况和goroutine数量表现。

Acquire 成功后可以不调用 Release 吗？

肯定不行。成功占用配额之后要立刻安排Release逻辑，否则剩余可用容量会持续变小，到最后所有新任务都会卡在等待队列里完全无法执行。

需要严格实现先进先出的调度效果该怎么做？

把排队逻辑交给单独的FIFO worker或者专用任务队列，信号量只负责管控资源预算。不要指望靠goroutine的到达顺序来实现业务层面的绝对公平。

把最终判断落到代码审查环节

如果代码逻辑只是控制同类任务的最大并发数，buffered channel的写法已经足够清晰易懂；如果等待过程必须支持取消，或者不同任务要消耗不同的下游资源预算，semaphore.Weighted 会更贴合实际需求。不管选哪种方案，上线的核心门槛都是三个要求：取消逻辑可见、资源能正常归还、峰值并发可测量，异常场景执行完后整个服务的状态还能回到基线。