应优先使用lscpu命令查看CPU信息，因其从内核缓存聚合数据、字段语义明确，可准确获取Socket(s)、Core(s) per socket、Thread(s) per core和CPU(s)四项关键拓扑参数，避免/proc/cpuinfo解析误差。
直接用 lscpu 看最稳，别先翻 /proc/cpuinfo
lscpu 从内核缓存统一聚合数据，字段语义明确、不依赖文本解析，虚拟化环境和旧内核下也基本不失效。打开终端输一行就出结果：
lscpu重点盯这四行： -
Socket(s): —— 物理 CPU 插槽数（即几颗物理芯片）
- Core(s) per socket: —— 每颗物理 CPU 的真实核心数（不是超线程后的逻辑核）
- Thread(s) per core: —— 是否启用超线程（1 = 关，2 = 开）
- CPU(s): —— 逻辑处理器总数（= Socket × Core × Thread）
比如看到 Socket(s): 2、Core(s) per socket: 16、Thread(s) per core: 2，那就表示：2 颗物理 CPU，共 32 个物理核心，64 个逻辑线程。
grep "physical id" 容易漏掉 sort -u 导致结果翻倍
很多人写 cat /proc/cpuinfo | grep "physical id" | wc -l，结果得到的是逻辑 CPU 数，不是物理颗数。因为每条逻辑 CPU 记录都带一个 physical id 字段，没去重就直接计数，等于统计了所有逻辑核。
正确写法必须加 sort -u 去重：
cat /proc/cpuinfo | grep "physical id" | sort -u | wc -l但要注意： - VMware、KVM 等虚拟化环境可能把所有
physical id 都设为 0，导致结果恒为 1
- ARM 服务器或某些容器镜像里，/proc/cpuinfo 可能被精简，physical id 字段压根不出现
- 即使命令跑通，也得和 lscpu 的 Socket(s): 行交叉验证，不能单信一条命令
nproc 和 getconf _NPROCESSORS_ONLN 只返回逻辑线程数
这两个命令输出的数字（比如 48）只代表当前进程可见的在线逻辑 CPU 数，完全不体现物理拓扑：
- 不告诉你有几颗 CPU
- 不区分物理核与超线程线程
- 在 cgroups 限制、CPU pinning 或容器中，它返回的是被限制后的值，不是硬件真实能力
典型误判场景：
-
nproc输出 16，你以为是 16 核物理 CPU，实际可能是Socket(s): 2×Core(s) per socket: 4×Thread(s) per core: 2→ 仅 8 物理核 - 绑核（
taskset）或 NUMA 调优时，靠nproc选核，容易跨 socket 访存，性能掉一截
查型号别只信 lscpu 的 Model name
lscpu 的 Model name 字段常被截断或带冗余括号（如 Intel(R) Xeon(R) CPU @ 2.30GHz），缺具体型号后缀。更准的做法是：
grep "model name" /proc/cpuinfo | head -n1 | cut -d: -f2 | xargs注意两点： - 用
head -n1 而非 uniq，因为 uniq 要求相邻才去重，而 /proc/cpuinfo 里不同逻辑核的 model name 字段虽然相同，但不一定相邻
- 这个字符串是运行时识别名，不是 BIOS 中登记的官方型号；要验厂商标识，得用 sudo dmidecode -t processor 看 Version 字段
物理 CPU 数和核心数这种信息，关键不在“怎么查”，而在“查完敢不敢信”。lscpu 是第一道防线，/proc/cpuinfo 是第二道交叉验证手段，而 dmesg | grep -i "cpu|smp" 才是启动时最原始的拓扑依据——尤其当两者对不上时，得回这里看内核到底枚举出了什么。
