调高 runtime.GOMAXPROCS 反而更慢，因其增加上下文切换和 procresize 开销，且 Go 调度器依赖 M:N 模型自动复用线程，非简单线程池；应保持默认值，仅在 P 长期空闲且 CPU 闲置时调整。
为什么 runtime.GOMAXPROCS 调得越高，并发任务反而更慢？
默认情况下，runtime.GOMAXPROCS 等于 CPU 核心数，盲目调高（比如设为 100）不会提升吞吐，反而加剧调度开销和内存竞争。Go 调度器不是线程池，它依赖 M:N 模型自动复用 OS 线程（M）来运行 goroutine（G），过度增加 P（Processor）数量会导致更多上下文切换和 procresize 开销。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 保持
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 语句之前执行。
实操建议：
立即学习“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 或大结构体，避免内存浪费。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 缓冲通道大小即最大并发数，
make(chan struct{}, 10)表示最多 10 个任务同时执行 - 获取许可用
sem ，释放用，务必用defer保证释放 - 不要把信号量 channel 传给可能 panic 的函数，panic 会跳过
defer，导致死锁；可加recover或用封装好的Acquire/Release方法
为什么用 context.WithTimeout 后，goroutine 还没收到取消信号就卡住了？
context 取消是协作式的，仅设置 Done() channel 关闭，不会强制终止 goroutine。如果任务内部没检查 ctx.Done() 或阻塞在不可中断的系统调用（如 time.Sleep 未结合 select），就会无视超时。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 所有阻塞操作（HTTP client、DB query、
time.Sleep）必须配合select监听ctx.Done() - HTTP 客户端要显式设置
ctx：用http.NewRequestWithContext(ctx, ...)，而非先创建再赋值 - 自定义 long-running 函数里，定期插入
if ctx.Err() != nil { return ctx.Err() }检查点
真正卡住并发调度的，往往不是 goroutine 数量，而是未暴露的阻塞点——比如一个没设超时的 http.Client、一个忘了 close() 的 channel、或一段没响应 ctx.Done() 的循环。这些地方不修复，调再高的 GOMAXPROCS 也没用。
