一、cat /proc/cpuinfo 的问题在哪
先说说为什么看起来好用的东西，在程序里反而不好用。
第一，输出格式是给人看的，不是给机器看的。
/proc/cpuinfo 的内容是纯文本，每一行都是"键: 值"的形式。你需要自己写逻辑去分割字符串、去匹配关键字、去做类型转换。一旦某一行的格式变了（比如内核升级后多了一个字段），你的解析逻辑就可能出错。
第二，信息分散，关联困难。
/proc/cpuinfo 里的信息是按逻辑字段组织的，但同一个 CPU 核心的各项属性被拆在了不同的行里。比如一个核心的型号在某一行，它的缓存信息在另一块区域，它的拓扑关系又在别的地方。你要把这些信息拼成一个完整的 CPU 核心对象，需要写不少 glue code。
第三，它是一个快照，不是实时的。
/proc/cpuinfo 读取的是内核在某个时刻维护的数据。如果你的程序在运行过程中 CPU 频率发生了变化（比如因为节能策略降频了），/proc/cpuinfo 里显示的可能还是之前的值。
第四，不适合做精细化查询。
如果你只想知道某个特定核心的频率，用 cat 命令就得把整个文件读一遍再过滤。这在性能敏感的场景下是一种浪费。
所以，与其解析文本，不如直接走内核提供的编程接口。
二、两条路：libproc 和 sysfs
在 Linux 上获取 CPU 信息，本质上有两条路可以走。
第一条路是走 libproc。这是一个专门用来读取 /proc 文件系统的库，它把 /proc 下各种文件的解析逻辑都封装好了，你只需要调用几个函数，就能拿到结构化的数据。
第二条路是直接读 sysfs。sysfs 是 /sys 目录下的虚拟文件系统，它把内核中的设备、驱动、拓扑等信息以文件的形式暴露给用户空间。CPU 的大量详细信息，在 sysfs 里都有对应的文件。
两条路各有优劣，下面分别展开讲。
三、用 libproc 获取 CPU 信息
libproc 是一个轻量级的 C 库，专门用于解析 /proc 文件系统中的内容。它在很多 Linux 发行版的软件仓库里都能找到。
使用 libproc 的好处是：你不需要自己去解析 /proc/cpuinfo 的文本，库已经帮你做好了。
libproc 提供了一组函数，可以直接获取 CPU 的总数、在线 CPU 的数量、每个核心的在线状态、以及每个核心的各种属性。调用这些函数后，你拿到的是已经解析好的结构化数据，不需要再做字符串处理。
具体来说，libproc 可以帮你拿到以下几类信息：
- CPU 核心的基本信息：型号名称、厂商 ID、系列、型号编号、步进修订号。这些信息对应 /proc/cpuinfo 里的那些字段，但不需要你自己去匹配。
- CPU 的在线状态：哪些核心是在线的，哪些是离线的。这在做 CPU 亲和性绑定时非常有用。
- CPU 的频率信息：当前频率、最小频率、最大频率。
- CPU 的拓扑信息：物理核心和逻辑核心的映射关系。
使用 libproc 的另一个优势是跨版本兼容。/proc/cpuinfo 的输出格式在不同内核版本之间可能有细微变化，但 libproc 内部已经处理了这些差异。你的代码不需要因为内核升级就重写解析逻辑。
不过 libproc 也有局限性。它主要覆盖的是 /proc/cpuinfo 和 /proc/stat 里的信息，对于一些更底层或者更细粒度的 CPU 数据（比如每个核心的功耗、温度、微架构细节），它就无能为力了。这时候就需要转向 sysfs。
四、用 sysfs 获取 CPU 信息
sysfs 是 Linux 内核暴露硬件拓扑和设备信息的主要接口。CPU 相关的信息，在 /sys/devices/system/cpu/ 这个目录下有非常完整的呈现。
sysfs 的结构是按目录组织的。每个 CPU 核心都有一个对应的子目录，名字就是 cpu0、cpu1、cpu2 这样的编号。在每个核心的目录下，又有一系列文件和子目录，分别对应不同的属性。
来看看 sysfs 里能拿到哪些 /proc/cpuinfo 给不了的东西：
CPU 拓扑信息。 在每个核心目录下的 topology 子目录里，有 physical_package_id、core_id、thread_siblings_list 等文件。这些文件精确地描述了这个核心属于哪个物理处理器、哪个物理核心、以及它和哪些兄弟核心共享同一个物理核心。这些信息对于做高性能计算、任务调度、NUMA 感知的程序来说，极其重要。
缓存信息。 /proc/cpuinfo 里的缓存信息比较简略，但在 sysfs 里，每个核心目录下有 cache 子目录，里面按照缓存级别（L1、L2、L3）分别列出了每个缓存的大小、行大小、关联度、共享方式等详细属性。
节能策略和频率控制。 在 cpufreq 子目录下，你可以拿到当前的频率、可用的频率列表、以及节能策略的相关参数。这比 /proc/cpuinfo 里的频率信息要详细得多。
微架构特性。 在 cpu 子目录下，有一些文件暴露了 CPU 的微架构级别的特性，比如支持的指令集扩展、页面大小、TLB 信息等。这些信息对于做运行时 CPU 特性检测的程序来说非常有价值。
使用 sysfs 的方式很直接：打开对应的文件，读取内容，做类型转换。由于 sysfs 里的文件内容也是文本，所以本质上还是在读文本。但好处是，sysfs 的文件结构非常稳定，几乎不会因为内核版本变化而改变格式。而且每个文件只包含一个值，不需要做复杂的解析。
五、两种方案的对比
说了这么多，来做一个对比，帮你在实际项目中做选择。
| 维度 | libproc | sysfs |
|---|---|---|
| 上手难度 | 较低，有现成的函数封装 | 中等，需要自己读文件解析 |
| 信息覆盖 | 覆盖 /proc 下的主要 CPU 信息 | 覆盖更细粒度的拓扑、缓存、频率策略 |
| 跨版本兼容 | 好，库内部处理了格式变化 | 极好，sysfs 结构非常稳定 |
| 依赖 | 需要链接 libproc 库 | 无额外依赖，直接读文件即可 |
| 适用场景 | 快速获取 CPU 基本信息 | 需要精确拓扑、缓存、频率控制等详细信息 |
我的建议是：如果你只需要 CPU 型号、核心数、频率这些基本信息，用 libproc，省心。如果你需要做 CPU 亲和性调度、缓存感知的内存分配、或者运行时的频率调整，直接读 sysfs，信息更全。
当然，两者也可以结合使用。用 libproc 拿基本信息，用 sysfs 拿拓扑和缓存信息，各取所长。
六、实际开发中的注意事项
在实际写代码获取 CPU 信息时，有几个坑需要特别留意。
第一个坑：在线 CPU 数量不等于物理核心数量。
很多人拿到 CPU 总数后就直接当物理核心数用，这是错的。一个物理核心可能对应多个逻辑核心（超线程）。你需要通过拓扑信息来区分物理核心和逻辑核心的数量。在 libproc 里有专门的函数可以拿到这个信息，在 sysfs 里需要读取 topology 目录下的相关文件。
第二个坑：频率信息可能有多个来源。
/proc/cpuinfo 里的频率、sysfs 里 cpufreq 下的频率、以及 /sys/devices/system/cpu/cpuX/cpufreq/scaling_cur_freq，这几个地方的值可能不一致。原因是内核在不同的地方维护了不同层级的频率数据。一般来说，scaling_cur_freq 是当前实际运行的频率，比较准确。而 /proc/cpuinfo 里的可能是标称频率或者最大频率。根据你的需求选择合适的来源。
第三个坑：离线核心的处理。
在做 CPU 遍历的时候，不要假设所有编号的核心都是在线的。有些核心可能被操作系统离线了（比如为了节能）。如果你直接遍历 cpu0 到 cpuN，然后去读取每个核心的信息，读离线核心的 sysfs 文件可能会失败或者返回空。正确的做法是先获取在线核心的列表，只遍历在线的核心。
第四个坑：多路处理器的编号问题。
在多路服务器上，物理处理器的编号和核心编号之间的对应关系比较复杂。同一个物理处理器上的核心，它们的 physical_package_id 是一样的，但 core_id 不同。如果你需要按物理处理器来分组处理任务，一定要正确解析这些 ID。
七、一个推荐的实现思路
如果让我来写一个获取 CPU 信息的模块，我会这样设计：
首先，用 libproc 获取 CPU 的总数、在线 CPU 的数量、每个核心的基本型号信息。这一步快速、简单，能拿到大部分需要的数据。
然后，遍历每个在线核心，从 sysfs 的 topology 目录读取物理拓扑信息，构建一个完整的 CPU 拓扑树。这棵树能告诉你：有几个物理处理器，每个物理处理器有几个核心，每个核心有几个逻辑线程。
接着，从 sysfs 的 cache 目录读取缓存信息，构建每个核心的缓存层级关系。这对于后续做缓存亲和的内存分配非常有用。
最后，把这些信息封装成一个统一的数据结构，对外提供查询接口。上层业务代码不需要关心数据是从 libproc 还是 sysfs 来的，只需要调用接口就能拿到需要的信息。
这种分层获取、统一封装的方式，既保证了信息的完整性，又隔离了底层实现的变化。即使将来内核调整了 /proc 或者 sysfs 的布局，你也只需要修改底层的获取逻辑，上层代码不受影响。
写在最后
cat /proc/cpuinfo 是一个好用的调试工具，但不是一个好的编程接口。它给人看的，不是给程序用的。
当你的程序需要获取 CPU 信息时，请优先考虑 libproc 或者直接读取 sysfs。前者让你快速拿到结构化数据，后者让你拿到最细粒度的硬件信息。两条路都比解析文本要靠谱得多。
Linux 内核其实已经把硬件信息整理得很好了，就差你去用对的方式读取它。
