直接用 go 关键字无法胜任任务调度，因其启动的 goroutine 无管理、无生命周期控制，不能限速、排队、重试或超时，易导致内存溢出或服务崩溃；需用 semaphore 控制并发、channel 缓冲队列、context 实现超时重试。
为什么直接用 go 关键字无法胜任任务调度？
因为 go 启动的是无管理、无生命周期控制的 goroutine，任务一扔就不管了——既不能限速、也不能排队、更没法重试或超时。一旦并发量突增（比如 1000 个 HTTP 请求同时进来），全丢给 go f()，很容易打爆内存或压垮下游服务。
真正需要的是带“水闸”和“队列”的调度层：控制并发数、缓冲待执行任务、统一处理失败逻辑。
- 典型错误现象：
runtime: out of memory或大量context.DeadlineExceeded错误，但日志里看不到哪批任务失控 - 核心约束不是“能不能并发”，而是“该并发多少、谁先谁后、失败了怎么办”
- 不要自己手写带锁的全局计数器——用
semaphore.Weighted或带缓冲的 channel 更可靠
用 golang.org/x/sync/semaphore 控制并发上限
这是官方维护的信号量实现，比自己用 chan struct{} 更安全（支持带上下文的获取、可中断、可超时）。
示例场景：最多同时拉取 5 个远程配置，其余排队等待：
立即学习“go语言免费学习笔记（深入）”；
sem := semaphore.NewWeighted(5)
var wg sync.WaitGroup
for _, url := range urls {
wg.Add(1)
go func(u string) {
defer wg.Done()
// 阻塞直到拿到许可，或上下文取消
if err := sem.Acquire(context.Background(), 1); err != nil {
log.Printf("acquire failed: %v", err)
return
}
defer sem.Release(1) // 必须确保释放！建议 defer
fetchAndProcess(u)
}(url)
}
wg.Wait()
- 别把
sem.Acquire放在 goroutine 外面——那就退化成串行了 -
sem.Release(1)必须成对出现；panic 时容易漏掉，所以优先defer - 如果任务耗时差异大，单纯限流不够，还需加队列缓冲（见下一条）
用带缓冲 channel + worker pool 实现任务排队与复用
信号量只管“放行数量”，不存任务本身。当突发流量远超处理能力时，你需要一个缓冲区暂存请求，避免调用方阻塞或丢弃。
典型结构：一个输入 channel 接收任务，N 个常驻 goroutine 从 channel 取任务执行：
type Task struct {
ID string
Fn func()
Done chan error // 可选：通知调用方结果
}
<p>tasks := make(chan Task, 100) // 缓冲 100 个待处理任务
for i := 0; i < 4; i++ { // 启动 4 个 worker
go func() {
for t := range tasks {
t.Fn()
if t.Done != nil {
t.Done <- nil
}
}
}()
}</p><p>// 提交任务（非阻塞，满则丢弃或返回错误）
select {
case tasks <- Task{ID: "cfg-1", Fn: fetchConfig}:
default:
log.Println("task queue full, dropped")
}
- 缓冲大小不是越大越好：
make(chan Task, 10000)可能导致 OOM，应结合平均处理时长和吞吐预估 - worker 数量 ≠ CPU 核心数——IO 密集型任务（如 HTTP 调用）设为 4~16 更合理
- 别让 worker 直接 panic：加
recover()，否则整个 channel 会关闭，后续任务全丢
如何让调度器支持超时、重试与上下文传递？
真实业务中，单次任务失败不等于最终失败，且必须响应用户请求时限。关键不是“启动 goroutine”，而是“启动一个可取消、可重试、有 deadline 的执行单元”。
推荐组合：context.WithTimeout + 封装任务函数 + 显式重试逻辑：
func runWithRetry(ctx context.Context, task func(context.Context) error, maxRetries int) error {
var lastErr error
for i := 0; i <= maxRetries; i++ {
retryCtx, cancel := context.WithTimeout(ctx, 2*time.Second)
lastErr = task(retryCtx)
cancel()
if lastErr == nil {
return nil
}
if i < maxRetries {
time.Sleep(time.Second * time.Duration(i+1)) // 指数退避
}
}
return lastErr
}
<p>// 使用时传入 context 和重试策略，而非裸函数
tasks <- Task{
Fn: func() {
runWithRetry(context.Background(), doHTTPCall, 2)
},
}
- 永远不要在 goroutine 内部硬编码
time.Sleep——它不响应 cancel，会浪费资源 - 重试次数要限制，否则雪崩；指数退避比固定间隔更友好
- 如果任务本身已接收
context.Context，直接透传即可，无需二次封装
调度器最易被忽略的点是“拒绝策略”和“可观测性”：缓冲满时是阻塞、丢弃还是返回错误？每个任务的执行耗时、成功率有没有埋点？这些不写进核心逻辑，后期排查会极其被动。
