std::thread::hardware_concurrency() 经常返回0，因为其实现可能无法探测系统信息，如旧版libstdc++、嵌入式环境或/proc不可用时会返回0，表示“无法确定”而非“无CPU”。
std::thread::hardware_concurrency() 返回值为什么经常是 0？
std::thread::hardware_concurrency() 是 C++11 起提供的标准接口，用于获取系统建议的并发线程数。但它不保证返回有效值——很多实现（尤其是旧版 libstdc++、某些嵌入式或容器环境）在无法探测时直接返回 0。
- 返回
0并不表示“无 CPU”，而是“实现无法确定”，比如未启用_GLIBCXX_PARALLEL、/proc 不可用、或 Windows 上 GetSystemInfo 失败 - 它反映的是“推荐用于并行任务的线程上限”，不是物理核心数，也不区分超线程（例如 8 逻辑核可能对应 4 物理核 + HT）
- 该函数无副作用、不抛异常、线程安全，但不可靠——不能单独依赖它做线程池大小决策
Linux 下用 sysconf(_SC_NPROCESSORS_ONLN) 获取在线逻辑核数
比 std::thread::hardware_concurrency() 更稳定，且 POSIX 标准，glibc 和 musl 都支持。它读取当前在线（online）的逻辑处理器数量，等价于 getconf _NPROCESSORS_ONLN 命令结果。
int n = sysconf(_SC_NPROCESSORS_ONLN);
if (n < 1) {
n = 1; // fallback
}
-
_SC_NPROCESSORS_ONLN：只统计当前启用的逻辑核（/sys/devices/system/cpu/online），热插拔后会变化 - 若需物理核数，得解析
/sys/devices/system/cpu/cpu*/topology/core_id去重，或调用lscpu解析输出（非标准，不推荐嵌入） - 注意：该函数在 macOS / iOS 上不支持，需分支处理
Windows 上用 GetSystemInfo() 或 GetLogicalProcessorInformation()
Windows 没有 POSIX sysconf，但 GetSystemInfo() 简单可靠，返回的是逻辑处理器数量（含超线程）。
#ifdef _WIN32 #include <windows.h> SYSTEM_INFO si; GetSystemInfo(&si); int n = static_cast<int>(si.dwNumberOfProcessors); #endif
-
dwNumberOfProcessors是逻辑核数，和 Linux 的_SC_NPROCESSORS_ONLN行为一致 - 如需区分物理核/逻辑核，必须用
GetLogicalProcessorInformation()+ 解析RELATIONSHIP，代码量大且易出错，多数场景不需要 - MinGW 和 MSVC 都支持
GetSystemInfo，无需额外链接
跨平台封装建议：fallback 链与编译期检测
别写 “if Linux / else if Windows” 运行时分支。优先用编译宏选路径，再 fallback 到 std::thread::hardware_concurrency()，最后兜底为 1 或 2。
立即学习“C++免费学习笔记（深入）”；
- 避免运行时探测路径差异（比如误把 macOS 当 Linux 走
sysconf） - macOS 应走
sysctlbyname("hw.logicalcpu", ...)，而非sysconf - 所有路径都应加 error check，尤其
sysctlbyname和sysconf可能设errno - 不要缓存结果到全局变量——CPU 热插拔、容器 cgroup 限核都可能导致数值变化，按需调用更稳妥
cpus）下，sysconf(_SC_NPROCESSORS_ONLN) 仍返回宿主机总核数，而非 cgroup 允许的核数。真要适配容器，得读 /sys/fs/cgroup/cpu.max（cgroup v2）或 /sys/fs/cgroup/cpu/cpu.cfs_quota_us（v1），那已是另一个层级的问题了。 
