用带缓冲的chan struct{}模拟信号量可精准控制goroutine并发数；初始化sem := make(chan struct{}, maxWorkers)，发送空结构体占位、接收释放，避免用chan int或close()引发panic。
用 semaphore 控制 goroutine 并发数最直接
Go 没有内置的“最大 goroutine 数”开关，但用带缓冲的 chan struct{} 模拟信号量是最轻量、最可控的方式。它本质是限制同时进入临界区的 goroutine 数量，不阻塞调度器，也不依赖第三方库。
常见错误是把 chan int 当计数器用，或误用 close() 导致 panic；正确做法是只用它作令牌桶：发送空结构体占位，接收即释放。
- 初始化：
sem := make(chan struct{}, maxWorkers)，maxWorkers即最大并发数 - 启动任务前：
sem （若满则阻塞） - 任务结束时：
（必须在 defer 或结尾显式调用） - 不要用
len(sem)判断剩余容量——它只反映当前缓冲中元素个数，不是可用槽位数
sync.WaitGroup + semaphore 组合才能安全等全部完成
只靠信号量无法知道所有任务是否结束，必须配 sync.WaitGroup。漏掉 wg.Done() 或提前 wg.Wait() 都会导致死锁或 panic。
典型场景是批量 HTTP 请求、文件处理、数据库批量写入——既要限流，又要等结果汇总。
立即学习“go语言免费学习笔记（深入）”；
func processItems(items []string, maxWorkers int) {
sem := make(chan struct{}, maxWorkers)
var wg sync.WaitGroup
for _, item := range items {
wg.Add(1)
go func(s string) {
defer wg.Done()
sem <- struct{}{} // 获取令牌
defer func() { zuojiankuohaophpcn-sem }() // 释放令牌
// 实际工作，比如 http.Get(s)
fmt.Println("processing:", s)
}(item)
}
wg.Wait() // 等所有 goroutine 完成}
别用 runtime.GOMAXPROCS 控制并发数量
runtime.GOMAXPROCS 控制的是**OS 线程数上限**（即 P 的数量），不是 goroutine 并发数。设成 1 不会让 1000 个 goroutine 串行执行——它们仍会排队在单个 P 上快速切换，只是无法并行利用多核。
真正影响吞吐的是 I/O 阻塞、锁竞争、内存分配压力，而不是 P 的数量。盲目调小 GOMAXPROCS 可能反而加剧调度延迟。
- 默认值已是
NumCPU()，通常无需修改 - 仅当程序大量绑定系统线程（如 CGO 调用）且出现线程耗尽时才考虑调整
- goroutine 数量由业务逻辑和 channel 阻塞行为决定，和
GOMAXPROCS无直接关系
超时与取消必须配合 context.Context
仅限流还不够。如果某个 goroutine 卡死（比如网络 hang 住、死循环），整个信号量池可能被占满，后续任务永久等待。必须为每个任务设置超时或可取消机制。
不能只在主 goroutine 里用 time.After，要将 ctx 传入子 goroutine，并在 I/O 操作中显式检查 ctx.Err()。
func fetchWithTimeout(url string, ctx context.Context) error {
req, _ := http.NewRequestWithContext(ctx, "GET", url, nil)
resp, err := http.DefaultClient.Do(req)
if err != nil {
return err // 自动包含 context.Canceled 或 context.DeadlineExceeded
}
defer resp.Body.Close()
return nil
}注意：context.WithTimeout 返回的 cancel 函数要在 goroutine 启动后立即 defer 调用，否则可能泄漏 timer。
