runtime.GOMAXPROCS(1) 使并发变慢，因强制所有 goroutine 在单个 P 上轮转，丧失多核并行能力；默认值为 CPU 核心数，仅在明确资源受限时调低。
为什么 runtime.GOMAXPROCS(1) 反而让并发任务更慢
Go 的调度器默认利用多核，runtime.GOMAXPROCS 控制的是可同时执行用户代码的操作系统线程数（P 的数量），不是 goroutine 数量。设为 1 会强制所有 goroutine 在单个逻辑处理器上轮转，失去并行能力——哪怕任务是 CPU 密集型，也只用上一个核。
常见误判场景：有人看到 goroutine 创建快、切换快，就以为“少开线程更轻量”，结果把 GOMAXPROCS 锁死为 1，实际吞吐直接腰斩。
- 默认值是机器 CPU 核心数（Go 1.5+），一般无需修改
- 仅在明确受外部资源限制时才调低（如容器内存受限，或与 C 代码共用线程导致阻塞）
- 调高不会提升性能，超过物理核数只会增加调度开销和缓存抖动
channel 缓冲区大小怎么选：0、1 还是 N？
无缓冲 channel（make(chan T)）要求发送与接收必须同步完成，适合做信号通知或严格配对的协作；但若 sender 和 receiver 节奏不一致，就会频繁挂起/唤醒，增加调度延迟。
缓冲 channel（make(chan T, N)）能解耦生产与消费节奏，但过大缓冲会掩盖背压问题，甚至导致 OOM；过小则退化为无缓冲行为。
立即学习“go语言免费学习笔记（深入）”；
- CPU 密集型任务（如批量计算）：用
1或2就够，避免 goroutine 空等 - I/O 密集型（如 HTTP 请求分发）：根据平均并发请求数 × 1.5 设置，例如峰值 QPS 1000，worker 数 20 → 缓冲约
75 - 绝对不要用
make(chan T, math.MaxInt)模拟“无限队列”，这是内存泄漏高发点
sync.Pool 用错反而拖慢 goroutine 启动速度
sync.Pool 本意是复用临时对象、减少 GC 压力，但它的 Get/Put 操作本身有锁和原子操作开销。如果对象构造成本极低（比如 &bytes.Buffer{}），或者生命周期短于一次 GC 周期，用 Pool 反而增加调度负担。
典型错误：在每秒百万级 goroutine 启动的场景中，给每个 goroutine 分配一个从 sync.Pool 获取的结构体，结果 Pool 内部的 shard 锁成了瓶颈。
- 适用场景：对象分配频次高 + 构造开销大（如
*json.Decoder、自定义大结构体） - 必须配合
pool.Put显式归还，且不能归还已逃逸到堆外或被闭包捕获的对象 - Go 1.21+ 引入
sync.Pool.New回调，但不要在里面做任何阻塞操作（如 channel send、网络调用）
var bufPool = sync.Pool{
New: func() interface{} {
// ✅ 正确：只做轻量初始化
return new(bytes.Buffer)
},
}time.After 和 ticker 在高并发调度中为何成隐性瓶颈
time.After(d) 每次调用都会启动一个独立的 goroutine 来等待并发送时间信号；time.Ticker 虽复用 goroutine，但其 channel 是无缓冲的，若接收不及时，会堆积定时事件，触发大量唤醒。
在每秒启动数千 goroutine 并各自调用 time.After(5 * time.Second) 的场景下，调度器要维护同等数量的定时器 goroutine，CPU 时间大量消耗在 timer heap 维护和 goroutine 切换上。
- 高频超时控制：改用
context.WithTimeout，它复用父 context 的 timer，不新增 goroutine - 周期性任务：用
time.NewTicker+ 单 goroutine 分发，而非每个任务启一个 ticker - 绝对避免在 hot path（如 HTTP handler 内）反复调用
time.After
Go 的并发调度效率不取决于“怎么开更多 goroutine”，而在于让调度器少做无谓工作：别锁住 P、别让 channel 成堵点、别滥用池子、别放任 timer 泛滥。这些地方一松动，QPS 就可能翻倍——不是因为加了什么，而是去掉了什么。
