最可靠方式是组合使用sysconf()和/proc/cpuinfo（Linux）、GetLogicalProcessorInformation()（Windows）或sysctlbyname()（macOS），而非依赖std::thread::hardware_concurrency()——它仅返回逻辑线程数提示，不反映物理拓扑、cgroup限制或虚拟化遮蔽。
Linux下用sysconf()和/proc/cpuinfo获取物理核心与逻辑线程数
最可靠的方式是组合使用系统调用和文件解析，而非只依赖std::thread::hardware_concurrency()——它返回的是逻辑处理器数（含超线程），且在某些环境下可能返回0或不准确。
关键判断依据：sysconf(_SC_NPROCESSORS_ONLN)给出当前在线逻辑CPU数；而物理核心数需结合/proc/cpuinfo中的core id和physical id字段去重统计。
-
sysconf(_SC_NPROCESSORS_CONF)返回配置的逻辑CPU总数（含离线） - 读取
/proc/cpuinfo时，每条记录对应一个逻辑CPU；相同physical id+ 相同core id视为同一物理核心 - 注意：ARM平台可能无
core id字段，此时应依赖topology_core_id或/sys/devices/system/cpu/下的拓扑目录
Windows上用GetLogicalProcessorInformation()解析拓扑结构
这是Windows原生支持物理拓扑查询的唯一稳定接口，返回包含RELATIONSHIP类型的数组，能区分RelationProcessorCore、RelationNumaNode等层级。
常见错误：直接用GetSystemInfo()的dwNumberOfProcessors——它只给逻辑数，无法区分核心与超线程。
立即学习“C++免费学习笔记（深入）”；
- 必须循环遍历
GetLogicalProcessorInformation()返回的PSYSTEM_LOGICAL_PROCESSOR_INFORMATION数组 - 对每个
RelationProcessorCore项，用GroupMask和Count计算该核心下的逻辑处理器数（即是否开启超线程） - 若
GROUP_AFFINITY中Group> 0，需配合GetLogicalProcessorInformationEx(RelationGroup, ...)处理多NUMA组场景
C++跨平台封装时绕不开的陷阱：超线程误判与虚拟化干扰
在VMware、KVM或WSL2中，/proc/cpuinfo可能伪造ht标志或缺失core id，导致物理核心数被高估；Windows Hyper-V则可能隐藏RelationProcessorCore细节。
实际建议不是“写一次跑 everywhere”，而是分路径检测：
- Linux：优先读
/sys/devices/system/cpu/topology/core_siblings_list，每行对应一个物理核心的逻辑CPU列表，行数即物理核心数 - Windows：必须检查
dwActiveProcessorMask是否全1，否则GetLogicalProcessorInformation()可能漏掉离线核心 - macOS：没有标准API，只能用
sysctlbyname("hw.physicalcpu")和"hw.logicalcpu"，但M系列芯片会把性能核/能效核都计入physicalcpu，需额外查sysctlbyname("hw.optional.arm64")辅助判断
别信std::thread::hardware_concurrency()返回值
它只是提示“推荐并发线程数”，标准未规定必须等于逻辑CPU数，glibc实现里甚至可能返回0（如容器内cgroup限制未正确暴露）。
真实项目中，如果你看到这个函数返回8，但/proc/cpuinfo显示有4个物理核心+8个逻辑线程，那说明超线程已启用——但你无法从该返回值反推物理核心数。
- 它不区分物理/逻辑，也不反映当前cgroup限制（Docker默认不限制，但Kubernetes Pod可能设
cpu: "2"） - 在嵌入式或实时系统中，它可能被编译器优化掉或返回硬编码值
- 真正需要拓扑信息时，必须走系统级接口，而不是依赖C++标准库的模糊提示
/sys或调GetLogicalProcessorInformation()拿到的。最容易被忽略的，是容器、虚拟机和cgroup对CPU拓扑的遮蔽——同一段代码，在宿主机跑和在Pod里跑，physical id数量可能完全不同。 
