std::thread::hardware_concurrency() 经常返回 0 是因标准未强制实现，嵌入式或精简环境（如部分 musl libc）可能 fallback；应优先用平台 API：Linux 用 sysconf(_SC_NPROCESSORS_ONLN)，Windows 用 GetSystemInfo().dwNumberOfProcessors，macOS 用 sysctlbyname("hw.logicalcpu")。
std::thread::hardware_concurrency() 返回值为什么经常是 0？
这个函数本意是返回系统可用的逻辑核心数，但很多场景下返回 0 —— 不是 bug，而是标准未强制要求实现。Windows 和 Linux 上多数编译器（如 MSVC、GCC、Clang）会实际返回正确值，但某些嵌入式或精简环境（比如部分 musl libc 环境、静态链接时缺少 syscall 支持）可能 fallback 到 0。
实操建议：
- 永远不要直接信任
std::thread::hardware_concurrency()的返回值为非零，需做兜底判断 - 若返回 0，应降级使用平台 API 获取真实值，而不是硬编码为 1 或 4
- 它不区分超线程（Hyper-Threading）是否启用，返回的是操作系统报告的“可用逻辑处理器数”，即通常所说的“逻辑核心数”
Linux 下用 sysconf(_SC_NPROCESSORS_ONLN) 最可靠
POSIX 标准接口，无需额外依赖，且始终返回当前在线的逻辑核心数（包括热插拔 CPU 场景）。比读取 /proc/cpuinfo 更轻量、更稳定。
示例代码片段：
立即学习“C++免费学习笔记（深入）”；
#include <unistd.h> int n = sysconf(_SC_NPROCESSORS_ONLN); if (n <= 0) n = 1; // 错误或不可用时保守 fallback
注意点：
-
_SC_NPROCESSORS_ONLN返回的是当前 online 的逻辑核数；_SC_NPROCESSORS_CONF返回的是配置总数（可能包含 offline 核），一般不用 - 该调用是线程安全的，可直接在任意位置调用
- 在容器中运行时（如 Docker），它反映的是 cgroup 限制后的可见核数，符合预期
Windows 下用 GetSystemInfo() 而不是 GetLogicalProcessorInformation()
后者功能强大但复杂：要遍历缓冲区、解析关系掩码、过滤 LOGICAL_PROCESSOR_RELATIONSHIP 类型，还容易漏掉 NUMA 节点或超线程标识。而获取逻辑核心总数，GetSystemInfo() 一步到位。
关键字段是 SYSINFO.dwNumberOfProcessors，它等价于 Windows 任务管理器里“逻辑处理器”数量。
示例：
#include <windows.h> SYSTEM_INFO si; GetSystemInfo(&si); int n = si.dwNumberOfProcessors;
常见误区：
- 误用
GetActiveProcessorCount(NULL)：它受进程组和组策略影响，返回的是当前进程能用的核数，不是系统总数 - 忽略
dwNumberOfProcessors是 DWORD 类型，强制转int前建议检查是否溢出（实际几乎不会） - 不需要管理员权限，普通用户进程可安全调用
跨平台封装时别忽略 macOS 的 sysctlbyname("hw.logicalcpu")
macOS 不支持 sysconf(_SC_NPROCESSORS_ONLN)（返回 -1），必须用 sysctlbyname。参数名是 "hw.logicalcpu"，不是 "hw.ncpu"（后者返回的是 active core 数，可能因节能策略动态变化）。
实操要点：
- 传入的
size参数必须是size_t类型变量地址，不能直接写sizeof(int) - 失败时返回 -1，errno 可能是
ENOTTY或ENOENT，需 fallback - 和 Linux 一样，该值在虚拟机或 Rosetta 2 下也准确反映 guest/translated 视角的逻辑核数
真正麻烦的从来不是“怎么查”，而是“查完信不信”。不同平台、不同内核版本、不同运行环境（容器、VM、Wine）下，同一个接口行为可能有细微差异。最稳妥的做法是：优先用原生 API，fallback 到 std::thread::hardware_concurrency()，最后才考虑读文件（如 /proc/cpuinfo）或硬编码。
