std::thread::hardware_concurrency() 返回 0 是因实现无法探测硬件并发能力，并非无并发能力，需降级使用系统 API：Linux 读 /proc/cpuinfo 的 processor 行数，Windows 调用 GetSystemInfo()，macOS 用 sysconf(_SC_NPROCESSORS_ONLN)，最后才 fallback 到该函数。
std::thread::hardware_concurrency() 返回值为什么经常是 0
这个函数本意是返回系统支持的并发线程数（通常是逻辑核心数），但标准不强制要求它必须返回有效值——实现可以返回 0，尤其在无法探测硬件时（如某些嵌入式环境、容器中未暴露 CPU topology、或旧版 libc 实现）。遇到 std::thread::hardware_concurrency() 返回 0，不能当作“无并发能力”，而是“探测失败”，需 fallback。
Linux 下读取 /proc/cpuinfo 获取逻辑 CPU 数量
这是最可靠、跨发行版通用的做法。关键不是看 processor 行数（它可能含超线程重复），而是统计唯一 core id + physical id 组合数，或直接用 nproc 命令结果。C++ 中可安全调用：
int get_logical_cpu_count() {
FILE* f = std::fopen("/proc/cpuinfo", "r");
if (!f) return 1;
int count = 0;
char line[256];
while (std::fgets(line, sizeof(line), f)) {
if (std::strncmp(line, "processor", 9) == 0) count++;
}
std::fclose(f);
return count > 0 ? count : 1;
}- 注意：仅适用于 Linux，
/proc/cpuinfo是内核虚拟文件，无需 root 权限 - 不要依赖
cpu cores字段——它只反映物理核心数，不含超线程 - 若程序运行在 Docker 容器中，且启用了
--cpus=2等限制，/proc/cpuinfo仍显示宿主机全部逻辑 CPU；此时应优先读/sys/fs/cgroup/cpu.max或/sys/fs/cgroup/cpu/cpu.cfs_quota_us配合cpu.cfs_period_us
Windows 上用 GetSystemInfo() 和 GetLogicalProcessorInformation()
GetSystemInfo() 返回的 dwNumberOfProcessors 是最常用且足够准确的逻辑处理器数量，适用于绝大多数场景；而 GetLogicalProcessorInformation() 更底层，能区分核心/超线程/NUMA 节点，但代码复杂、易出错，一般没必要。
- 推荐直接用：
SYSTEM_INFO si; GetSystemInfo(&si); int n = si.dwNumberOfProcessors; - 注意：该值在 Windows Server 容器或 Hyper-V 隔离模式下会正确反映分配的 vCPU 数，比
hardware_concurrency()更可信 - 若需区分物理核心与逻辑线程，必须用
GetLogicalProcessorInformation()并遍历RelationProcessorCore类型，但多数并发任务（如线程池大小设定）只需逻辑数
跨平台封装建议：优先系统 API，fallback 到 hardware_concurrency()
别把 std::thread::hardware_concurrency() 当主力。一个健壮的封装应按顺序尝试：
立即学习“C++免费学习笔记（深入）”；
- Linux：读
/proc/cpuinfo的processor行数 - Windows：调用
GetSystemInfo() - macOS：用
sysconf(_SC_NPROCESSORS_ONLN) - 最后 fallback：
std::thread::hardware_concurrency()，并检查是否为 0
真正容易被忽略的是：容器或云环境下的 CPU 配额限制（如 Kubernetes resources.limits.cpu）会让操作系统报告的逻辑数失效——此时应解析 cgroup v1/v2 接口，否则线程池可能过度创建，引发调度抖动。这层适配不在标准库职责内，得自己动手。
