std::thread::hardware_concurrency()常返回0是因为标准不强制实现返回真实值，旧版msvc或嵌入式工具链可能直接返回0；应视其为“无法可靠获取”而非“无核心”，需用平台特定api兜底：windows用getsysteminfo()，linux/macos用sysconf(_sc_nprocessors_onln)，并考虑超线程与cgroup限制。
std::thread::hardware_concurrency() 返回值为什么经常是 0？
这个函数本意是返回系统可用的逻辑核心数，但标准不强制要求实现必须返回真实值——某些编译器（尤其是旧版 MSVC 或嵌入式工具链）会直接返回 0。遇到 std::thread::hardware_concurrency() == 0 时，不能当作“没有核心”，而是“无法通过该接口可靠获取”。
- Linux/macOS 下通常返回正确值（依赖
sysconf(_SC_NPROCESSORS_ONLN)或sysctl） - Windows 上 MSVC 2015+ 多数情况正常，但 MinGW-w64 某些版本仍可能返回
0 - 如果后续要用它做线程池大小决策，必须加兜底逻辑
Windows 下用 GetSystemInfo() 获取逻辑核心数最稳
这是 Windows API 中最轻量、最可靠的方案，不依赖 WMI 或 PowerShell，也不需要管理员权限。
#include <windows.h>
int get_logical_core_count_windows() {
SYSTEM_INFO si;
GetSystemInfo(&si);
return static_cast<int>(si.dwNumberOfProcessors);
}</int></windows.h>
-
dwNumberOfProcessors是逻辑核心总数（含超线程），不是物理核心数 - 该值在进程生命周期内恒定，无需缓存或重复调用
- 注意：不要和
GetNativeSystemInfo()混用——后者对 WOW64 进程返回的是宿主系统信息，而GetSystemInfo()返回当前进程视图
Linux/macOS 下用 sysconf(_SC_NPROCESSORS_ONLN) 更准确
sysconf(_SC_NPROCESSORS_ONLN) 返回当前在线的逻辑 CPU 数，比 sysconf(_SC_NPROCESSORS_CONF) 更贴近实际可用值（后者返回配置总数，可能包含被热拔出的核）。
#include <unistd.h>
int get_logical_core_count_unix() {
long n = sysconf(_SC_NPROCESSORS_ONLN);
return (n > 0) ? static_cast<int>(n) : 1;
}</int></unistd.h>
- 返回
-1表示出错（比如内核不支持），需 fallback 到 1 - macOS 上同样有效，
_SC_NPROCESSORS_ONLN是 POSIX 标准接口 - 避免用
/proc/cpuinfo解析——不同架构字段名不统一（ARM 可能无processor字段），且开销大
跨平台封装时别忽略超线程与容器限制
即使拿到逻辑核心数，也不等于你能安全创建等量线程——现代 CPU 的超线程（Hyper-Threading）会让 hardware_concurrency() 返回 2× 物理核数，而某些场景（如 CPU 密集型计算）反而因资源争抢导致性能下降；更麻烦的是容器环境（Docker/K8s），cgroups 可能已限制了可用 CPU 配额。
- Linux 容器中，优先读取
/sys/fs/cgroup/cpu.max（cgroup v2）或/sys/fs/cgroup/cpu/cpu.cfs_quota_us（v1）判断是否受限 - 若检测到 cgroup 限频（如
cpu.cfs_quota_us = 50000，cpu.cfs_period_us = 100000），应按配额折算等效核心数：quota / period - 对纯计算任务，常把线程数设为物理核数而非逻辑核数，可减少上下文切换开销
真正难的不是读一个数字，而是判断这个数字在当前运行环境中是否可信、是否可用、是否最优——尤其当二进制要部署到混合环境（裸机/VM/容器）时，单一接口永远不够。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
