调高 runtime.GOMAXPROCS 反而更慢，因其增加上下文切换和 procresize 开销，且 Go 调度器依赖 M:N 模型自动复用线程，非简单线程池；应保持默认值，仅在 P 长期空闲且 CPU 闲置时调整。
为什么 runtime.GOMAXPROCS 调得越高，并发任务反而更慢？
默认情况下，runtime.GOMAXPROCS 等于 CPU 核心数，盲目调高（比如设为 100）不会提升吞吐，反而加剧调度开销和内存竞争。Go 调度器不是线程池，它依赖 M:N 模型自动复用 OS 线程（M）来运行 goroutine（G），过度增加 P（Processor）数量会导致更多上下文切换和 procresize 开销。
实操建议：
- 保持
runtime.GOMAXPROCS(0)（即默认值），除非你明确观察到 P 长期空闲且系统有大量闲置 CPU 核心 - 用
go tool trace查看Scheduler视图中的P idle和G waiting比例，而非凭直觉调参 - 若程序大量阻塞在 I/O（如 HTTP 请求、DB 查询），瓶颈往往不在 CPU，调
GOMAXPROCS无意义，应优化等待逻辑或连接复用
用 sync.WaitGroup 控制并发任务时，为什么任务没跑完就退出了？
典型错误是 WaitGroup.Add() 在 goroutine 内部调用，导致计数未及时注册，Wait() 提前返回。Go 调度不保证 goroutine 启动顺序，Add 必须在 go 语句之前执行。
实操建议：
-
WaitGroup.Add()必须在启动 goroutine 前调用，且不能被条件分支跳过 - 避免在循环中重复声明
var wg sync.WaitGroup，应在循环外初始化 - 如果任务数量动态变化，可用
chan struct{}+close()替代WaitGroup，尤其适合扇出/扇入场景
错误示例：
for _, job := range jobs {
go func() {
wg.Add(1) // ❌ 晚了，且可能 panic：Add called on already-closed WaitGroup
defer wg.Done()
doWork(job)
}()
}
wg.Wait() // 可能立即返回
如何安全地限制并发请求数量，又不卡死整个 goroutine 池？
用 semaphore（信号量）比手动维护计数器更可靠。Go 标准库没有内置信号量，但可用带缓冲的 chan struct{} 实现轻量级限流，注意别用 chan int 或大结构体，避免内存浪费。
