设为物理核心数而非逻辑线程数更优，因过多P会加剧调度开销、缓存失效和TLB压力；混杂I/O时则不宜盲目降低。
为什么 runtime.GOMAXPROCS 设为 CPU 核心数不一定最优
默认情况下，Go 运行时会将 GOMAXPROCS 设为系统逻辑 CPU 数（如 8 核 16 线程设为 16），但这不等于你的 CPU 密集型任务就该用满全部 P。当 goroutine 都在做纯计算（无 I/O、无 channel 阻塞），过多的 P 会导致调度器频繁切换、缓存失效加剧、TLB 压力上升。
- 实测中，对单一大循环分块并行的场景，
GOMAXPROCS设为物理核心数（而非逻辑线程数）常有 5–15% 性能提升 - 可通过
runtime.NumCPU()获取物理核心数，再手动调用runtime.GOMAXPROCS(n) - 注意：若程序混杂大量 I/O 或 channel 操作，盲目降低
GOMAXPROCS反而会阻塞非计算型 goroutine
用 sync.Pool 缓存高频分配的小对象，但别缓存大结构体
CPU 密集型任务常伴随高频中间计算结果（如 []float64 切片、小 struct 实例）。每次 make 或 new 都触发堆分配，增加 GC 压力和内存访问延迟。
-
sync.Pool对固定尺寸、生命周期短的小对象（如[64]float64数组、struct{ x, y int }）效果显著 - 避免缓存超过几 KB 的对象——Pool 内部无大小限制，大对象会长期驻留，反而污染 L3 缓存，且可能被 GC 误判为活跃
- 务必实现
New函数，且返回值必须是零值初始化（不能带副作用）
var float64Pool = sync.Pool{
New: func() interface{} {
return make([]float64, 0, 256) // 预分配容量，避免 append 扩容
},
}
避免在 hot path 中调用 fmt.Sprintf、strconv.Itoa 等反射/分配型函数
CPU 密集型代码里，哪怕一行日志格式化都可能吃掉 1–2% 的周期。这些函数内部会分配字符串、调用反射或 grow slice，破坏 CPU 流水线连续性。
- 用
fmt.Sprint替代fmt.Sprintf（如果目标是string且参数简单），或直接拼接："id:" + strconv.FormatInt(id, 10) - 对整数转字符串，优先用
strconv.AppendInt(dst, n, 10)，它复用传入的[]byte，零分配 - 调试输出尽量关掉；生产环境用结构化日志库（如
zerolog）并禁用字段反射
内联失败？检查 //go:noinline 和函数复杂度阈值
Go 编译器对小函数自动内联，消除调用开销。但一旦函数体过大、含闭包、或递归，就会放弃内联——这在数学计算循环中很致命，比如一个被调用百万次的 clamp(x, min, max) 若未内联，每次 call/ret 就多出 10+ 周期。
立即学习“go语言免费学习笔记（深入）”；
- 用
go build -gcflags="-m=2"查看内联决策，搜索cannot inline关键字 - 避免在 hot 函数中使用
defer、recover、interface{}参数或 map/slice 操作（它们抬高内联成本） - 必要时加
//go:inline（Go 1.19+），但需确认函数确实满足编译器要求；慎用//go:noinline——除非你在测 baseline
