Go 的 runtime.NumCPU() 返回的是操作系统报告的逻辑处理器数量（含超线程虚拟核），而非物理核心数；在 Intel 双核四线程 CPU 上返回 4 是正常行为，但实际并行加速比通常受限于物理核心数，尤其在计算密集型无共享任务中。
go 的 `runtime.numcpu()` 返回的是操作系统报告的逻辑处理器数量（含超线程虚拟核），而非物理核心数；在 intel 双核四线程 cpu 上返回 4 是正常行为，但实际并行加速比通常受限于物理核心数，尤其在计算密集型无共享任务中。
runtime.NumCPU() 的设计目标是反映操作系统可调度的并发执行单元总数，而非物理硬件资源本身。它直接调用底层系统 API（如 macOS 的 sysctl hw.ncpu、Linux 的 /proc/cpuinfo 中的 processor 行数），而现代 x86 CPU 普遍启用超线程技术（Hyper-Threading, HT），将单个物理核心模拟为两个逻辑处理器——这正是你 MacBook 上 NumCPU() 返回 4 的原因：2 个物理核心 × 2 逻辑线程/核心 = 4 个逻辑 CPU。
然而，逻辑核心 ≠ 独立计算单元。超线程通过共享同一物理核心的执行单元（ALU、FPU、缓存等）、仅复制寄存器堆和部分调度逻辑来提升吞吐量，其收益高度依赖工作负载特性：
- ✅ 受益场景：当线程频繁遭遇缓存未命中、分支预测失败或 I/O 等待时，超线程可切换执行另一线程，隐藏延迟（如 Web 服务、数据库连接池、混合计算/IO 任务）；
- ⚠️ 收益有限或负向场景：纯 CPU 密集型、无等待、高缓存局部性任务（如你的基准测试）——此时两个逻辑线程竞争同一物理核心的执行资源，反而因上下文切换、缓存冲突和资源争用导致性能不增反降。
你的实测结果（GOMAXPROCS=2 与 GOMAXPROCS=4 性能一致）完全符合预期。Go 调度器会将 goroutine 分配到 GOMAXPROCS 个 OS 线程上并发执行，但最终仍受限于物理核心的并行计算能力。对于无共享、全并行的计算任务，理论加速上限即为物理核心数（此处为 2x），设置超过该值无法突破阿姆达尔定律限制。
package main
import (
"fmt"
"runtime"
"time"
)
func main() {
fmt.Printf("Physical cores (approx): %d\n", runtime.NumCPU()/2) // 启用 HT 时粗略估算
fmt.Printf("Logical CPUs reported: %d\n", runtime.NumCPU()) // 实际返回值
// 推荐做法：对纯计算任务，显式设为物理核心数
physCores := runtime.NumCPU()
if runtime.GOARCH == "amd64" || runtime.GOARCH == "386" {
// 粗略检测 HT（非绝对可靠，生产环境建议读取 /sys/devices/system/cpu/smt/control 或使用第三方库）
if runtime.NumCPU() > 1 && runtime.NumCPU()%2 == 0 {
physCores = runtime.NumCPU() / 2
}
}
runtime.GOMAXPROCS(physCores)
fmt.Printf("GOMAXPROCS set to: %d\n", physCores)
}
⚠️ 注意事项：
- 不要盲目信任 NumCPU() 作为“最优并发度”的唯一依据；
- 生产环境中应结合真实负载压测确定 GOMAXPROCS —— 对 IO 密集型服务常设为 NumCPU() 或更高，对计算密集型则优先尝试物理核心数；
- macOS/Linux 提供更精确的硬件信息查询方式（如 sysctl hw.physicalcpu 或 lscpu | grep 'Core(s) per socket'），可辅助决策；
- Go 1.21+ 已默认启用异步抢占，减少了因长循环导致的调度延迟，但不改变底层硬件并行能力约束。
总之，NumCPU() 是一个系统视图接口，而非性能承诺。理解超线程的本质，结合 workload 特性做针对性调优，才是释放多核性能的关键。
