Windows下最可靠方式是GetSystemInfo，其dwNumberOfProcessors字段返回系统可见逻辑核心总数，不受进程亲和性影响，但热插拔后需重启进程；Linux/macOS应使用sysconf(_SC_NPROCESSORS_ONLN)而非get_nprocs_conf()或/proc/cpuinfo。
Windows下用 GetSystemInfo 获取逻辑核心数最可靠
在 Windows 上，GetSystemInfo 是获取逻辑处理器数量的官方推荐方式，它返回的是当前系统可见的逻辑核心总数（含超线程），且不受进程亲和性掩码影响。很多开发者误用 GetActiveProcessorCount 或直接读注册表，结果在容器、WSL2 或受限策略环境下出错。
-
GetSystemInfo返回的dwNumberOfProcessors字段即为逻辑核心总数，无需额外计算 - 注意：该值是进程启动时确定的，若系统热插拔 CPU（如某些服务器），不会动态更新，需重启进程
- 不要用
GetProcessAffinityMask—— 它只反映当前进程被允许使用的核数，不是系统总量
Linux/macOS 用 sysconf(_SC_NPROCESSORS_ONLN) 而非 get_nprocs_conf()
Linux 和 macOS 都支持 POSIX 的 sysconf 接口，_SC_NPROCESSORS_ONLN 返回当前在线（online）的逻辑核心数，这是运行时真实可用的数量；而 get_nprocs_conf() 返回的是内核编译时配置的最大可能核数，常高于实际值（尤其在 cgroups 限制或 CPU offline 场景下）。
- macOS 同样支持
sysconf(_SC_NPROCESSORS_ONLN)，但不保证返回超线程逻辑核（取决于硬件与系统版本），实测 Intel Mac 返回含超线程数，M 系列默认关闭超线程，返回物理核数 - 避免解析
/proc/cpuinfo行数——processor字段重复出现次数不可靠（例如某些虚拟化环境会伪造） - 如果需要区分物理核/逻辑核，Linux 可查
/sys/devices/system/cpu/online+/sys/devices/system/cpu/topology/core_siblings_list，但跨平台时没必要
C++17 起可用 std::thread::hardware_concurrency()，但有陷阱
std::thread::hardware_concurrency() 本意是返回“推荐并发线程数”，但它在不同标准库实现中行为不一致：libstdc++（GCC）和 libc++（Clang）通常返回逻辑核心数，MSVC 则可能返回 0（尤其在旧版本或嵌入式目标中），且标准明确允许它返回 0 表示“无法确定”。
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 不能当作权威系统信息源，仅适合做线程池初始大小的启发式参考
- 若返回 0，应 fallback 到平台原生 API，而不是硬编码为 1 或 4
- 它不感知当前 cgroup 限制（如 Docker --cpus=2），而
sysconf(_SC_NPROCESSORS_ONLN)在容器内会正确返回受限后的值
跨平台封装建议：优先判断 OS，避免宏滥用
别用一大串 #ifdef _WIN32 / #elif __linux__ 嵌套，容易漏条件。更稳妥的做法是按平台分文件，或用简洁的 inline 函数：
立即学习“C++免费学习笔记（深入）”；
#ifdef _WIN32
#include <windows.h>
int get_logical_cores() {
SYSTEM_INFO si;
GetSystemInfo(&si);
return static_cast<int>(si.dwNumberOfProcessors);
}
#elif defined(__linux__) || defined(__APPLE__)
#include <unistd.h>
int get_logical_cores() {
return static_cast<int>(sysconf(_SC_NPROCESSORS_ONLN));
}
#else
int get_logical_cores() { return 1; } // fallback
}
真正容易被忽略的是：即使你拿到了数字，也不代表你能独占这些核——CPU 亲和性、cgroup 配额、虚拟机 vCPU 预留都会让实际并发能力打折。拿这个数做线程池大小时，最好再结合 std::this_thread::sleep_for 观察调度延迟，而非盲目设满。
