应降级到系统API：Linux用sysconf(_SC_NPROCESSORS_ONLN)，macOS/BSD用sysctlbyname("hw.ncpu")，Windows用GetSystemInfo()；需运行时探测+回退链，避免预处理器误判，且不可将0当作1处理。
std::thread::hardware_concurrency() 返回值为 0 怎么办
这个函数本意是返回系统可用的硬件线程数（比如 8 核 16 线程就可能返回 16），但标准只要求它“尽力而为”，std::thread::hardware_concurrency() 在某些平台（尤其是嵌入式、交叉编译环境或旧版 libc 实现）可能直接返回 0，不代表没核，只代表无法探测。
遇到 0 时别直接 fallback 到 1——这会让并行任务严重欠载。应主动降级到更底层的系统接口：
- Linux：读取
/proc/sys/kernel/ngroups_max不对，正确路径是/sys/devices/system/cpu/online或用sysconf(_SC_NPROCESSORS_ONLN) - macOS / BSD：调用
sysctlbyname("hw.ncpu", ...) - Windows：用
GetSystemInfo()填充SYSTEM_INFO.dwNumberOfProcessors
跨平台封装时为什么不能只靠预处理器判断
光写 #ifdef __linux__ 容易翻车：WSL2 下是 Linux 内核但运行在 Windows 主机上；Android NDK 编译的二进制可能跑在 ARM Linux 设备，但 sysconf 行为和桌面 glibc 不完全一致；MinGW 编译的程序在 Windows 上又不支持 sysctlbyname。
更稳妥的做法是运行时探测 + 回退链：
立即学习“C++免费学习笔记（深入）”；
- 先调
std::thread::hardware_concurrency()，非零就用 - 否则尝试
sysconf(_SC_NPROCESSORS_ONLN)（POSIX 兼容路径） - 再失败则查
sysctlbyname（仅 macOS/BSD） - 最后 Windows API 分支兜底
注意：sysconf(_SC_NPROCESSORS_ONLN) 在 musl libc（如 Alpine Linux）上可靠，但在某些旧 Android Bionic 版本中可能未实现，需加 #ifdef _SC_NPROCESSORS_ONLN 守卫。
std::thread::hardware_concurrency() 和逻辑 CPU 数的区别
它返回的是「操作系统报告的可用硬件线程数」，不是物理核心数，也不等于 nproc 命令输出（后者可能受 cgroup 限制）。例如容器里 docker run --cpus=2 启动的进程，std::thread::hardware_concurrency() 仍可能返回宿主机总核数——它不感知资源限制。
若业务需要感知 cgroup 或容器配额，得手动解析：
-
/sys/fs/cgroup/cpu.max（cgroup v2）里的max字段（如200000 100000表示 2 核） -
/sys/fs/cgroup/cpu.cfs_quota_us（v1）与cpu.cfs_period_us相除
这些路径不存在或读取失败时，才应回到硬件并发度原始值。别把 cgroup 逻辑硬塞进通用并发度函数里。
避免 std::thread 构造时隐式依赖 hardware_concurrency
常见错误是写 std::vector<:thread> threads(hardware_concurrency());</:thread> 然后循环 emplace_back，但若 hardware_concurrency() 返回 0，vector 就为空，后续 join() 前没检查 size，直接崩溃。
安全写法必须带校验：
int hw_threads = std::thread::hardware_concurrency();
if (hw_threads == 0) {
hw_threads = 1; // 至少保证能跑，但建议用上面的跨平台 fallback
}
std::vector<std::thread> workers;
workers.reserve(hw_threads);
for (int i = 0; i < hw_threads; ++i) {
workers.emplace_back([]{ /* work */ });
}
for (auto& t : workers) t.join();
真正容易被忽略的是：这个值在程序生命周期内不会动态更新。CPU 热插拔、cgroup 配额变更、容器 resize 都不会触发重探，业务层若需响应式调整线程池规模，得自己监听对应事件或定期重查。
