hostprobe 队列上限 8、4 个 worker，但 100 个请求全部返回 202，goroutine 数涨到约 100

我觉得 go func() { q.jobs <- job }() 就是你的全部答案。channel 本身在正常工作，8 个在缓冲区里，4 个被 worker 拿着，其余的发送都会阻塞。但每个被阻塞的发送都是它自己的一个 goroutine，停在 channel 发送上，而 handler 早就往下走去返回 202 了。所以队列从来没有对任何人施加背压，只是在它后面多了一个由 goroutine 组成的等候室。这就是你在 pprof 里看到的那一大组，也是 1000 个请求会有大约 1000 个 goroutine 的原因。每个 goroutine 都占着一个栈，还拿着 job，所以每次突发之后内存往上爬也对得上。

如果你想让第 9 个开始被拒绝，就在 handler 里用 select 来做发送。

select {
case q.jobs <- job:
	atomic.AddInt64(&q.accepted, 1)
	w.WriteHeader(http.StatusAccepted)
	fmt.Fprintf(w, "queued %s\n", host)
case <-r.Context().Done():
	return
default:
	http.Error(w, "queue full", http.StatusServiceUnavailable)
}

加上 default 就会立刻失败。如果你更希望调用方等着，就去掉 default，context 那个分支会让它在客户端断开时放弃。对 cron 脚本来说，通常的做法是返回 503（想用 429 也行）并带上 Retry-After。

另外我觉得，对旧代码的行为来说，"queued" 这个词有点太大方了。它更像是“答应了会排队，迟早的事”。

就是这个问题。改成带 default 的 select 之后，第 9 个请求起会返回 503。goroutine 稳定在 4 个 worker 加上平时那几个。谢谢！

给之后看到的人补充一下，/debug/pprof/goroutine?debug=1 就是我发现这堆 goroutine 的办法，net/http/pprof 的文档在 https://pkg.go.dev/net/http/pprof 这里。