标准C++无直接获取CPU信息接口，唯一标准库方法是std::thread::hardware_concurrency()，仅返回建议并发线程数，不区分物理/逻辑核心，可能为0需兜底；跨平台应优先选用libcpuid或hwloc等成熟库。
没有标准 C++ 接口能直接获取 CPU 信息；跨平台获取硬件信息必须依赖系统 API 或第三方库，自己封装时要特别注意 ABI 兼容性和权限问题。
用 std::thread::hardware_concurrency() 获取逻辑核心数（最轻量）
这是唯一标准库提供的、与 CPU 相关的接口，但它只返回「建议的并发线程数」，不等于物理核心数，也不反映超线程状态或当前亲和性限制。
- Windows/Linux/macOS 均支持，无需额外链接
- 返回值可能为 0（探测失败），需做兜底处理
- 它不区分物理/逻辑核心，也不提供型号、频率、缓存等任何其他信息
int n = std::thread::hardware_concurrency();
if (n == 0) {
// fallback: e.g., assume 4
}
Linux 下读取 /proc/cpuinfo（简单但不可靠）
这是 Linux 最常用方式，但属于解析文本文件，不是系统调用，容易被容器、chroot 或 cgroups 干扰，且字段格式无严格规范。
-
model name字段通常含 CPU 型号，但不同内核版本可能用cpu model或Processor -
cpu MHz是当前运行频率，非标称主频；max MHz更接近设计值，但需 root 权限才能稳定读取 - 物理核心数需统计
physical id+core id组合去重，逻辑核心数看processor行数
// 示例：粗略提取核心数（仅作示意）
#include <fstream>
#include <string>
#include <unordered_set>
std::ifstream f("/proc/cpuinfo");
std::string line;
std::unordered_set<std::string> cores;
while (std::getline(f, line)) {
if (line.rfind("physical id", 0) == 0 || line.rfind("core id", 0) == 0) {
cores.insert(line.substr(line.find(':') + 1));
}
}
Windows 用 __cpuidex() 和 Win32_Processor WMI（需权衡精度与开销）
__cpuidex() 是 x86/x64 内建指令封装，可读取 CPU 厂商 ID、型号、缓存拓扑等底层信息，但仅限 Intel/AMD，且需手动解析 CPUID 功能位；WMI 查询更通用，但启动慢、依赖 COM 初始化、可能被策略禁用。
Docker Image Puller
下载
使用 Python 脚本下载 Docker 镜像并打包为 tar 文件。用户说“下载镜像”“拉取镜像”“pull xxx”“帮我下载 nginx 镜像”等时触发。支持 SOCKS5 代理直连（推荐）和国内镜像站加速两种模式。
立即学习“C++免费学习笔记（深入）”；
-
__cpuidex(&info, 0x80000002, 0)开始的四次调用可拼出brand_string（如 "Intel(R) Core(TM) i7-9750H"） - WMI 中
Win32_Processor.Name字段最可靠，但查询耗时约 10–50ms，首次调用还可能触发 COM 初始化延迟 - 两者都需要管理员权限才能获取准确的 TDP、最大频率等字段
推荐方案：用 libcpuid 或 hwloc 封装跨平台逻辑
硬编码多套系统 API 维护成本极高；libcpuid 专注 CPU 识别（支持 x86/ARM，含微架构推断），hwloc 更重拓扑（NUMA、cache、binding），二者都已处理了 Windows/Linux/macOS 的 syscall 差异和权限降级逻辑。
-
libcpuid需静态链接，头文件少，cpu_id_t结构体字段命名直白（如data->num_cores,data->brand_str） -
hwloc默认动态加载，支持 Docker 容器内拓扑感知，但编译依赖较多（libxml2、pciutils） - 二者都不提供实时频率——那是 OS 调度器和电源管理的事，C++ 层不该越界
真正难的不是“怎么拿到字符串”，而是判断该信哪个值：容器里看到的 /proc/cpuinfo 是宿主机的还是被 cgroups 限制后的？WMI 返回的 MaxClockSpeed 是 BIOS 设置值还是当前 P-state 上限？这些边界情况比调用本身更消耗调试时间。
