getlogicalprocessorinformation是windows下获取核心/线程拓扑的唯一可靠方式，通过解析system_logical_processor_information数组中relationprocessorcore类型的processormask位图统计每物理核线程数；linux则需解析/sys/devices/system/cpu/cpu*/topology/{core_id,thread_siblings_list}文件构建映射。
Windows下用GetLogicalProcessorInformation获取核心/线程拓扑
Windows原生支持物理核心与逻辑处理器（超线程）的映射关系，GetLogicalProcessorInformation 是唯一可靠方式。它返回SYSTEM_LOGICAL_PROCESSOR_INFORMATION数组，每个元素带Relationship字段标识类型（RelationProcessorCore、RelationNumaNode等），关键在ProcessorMask——一个64位整数，每位对应一个逻辑处理器ID，置1表示该逻辑核属于当前物理核。
常见错误是直接把ProcessorMask当核心数：它只告诉你“哪些逻辑核绑在同一物理核上”，不是编号。例如双核四线程机器，可能返回两个RelationProcessorCore条目，每个ProcessorMask含2个bit（如0b0011和0b1100），需用__popcnt64()统计bit数得出每核线程数。
- 必须用
GetLogicalProcessorInformation，GetSystemInfo只返回总逻辑数（dwNumberOfProcessors），无拓扑信息 - 调用前需两次分配内存：第一次传
NULL获所需缓冲区大小，第二次再分配并填入数据 - 返回数组顺序不保证，需遍历过滤
Relationship == RelationProcessorCore的项 - 注意
DWORD_PTR在32/64位下的宽度差异，ProcessorMask始终是ULONG_PTR类型
Linux下解析/sys/devices/system/cpu/目录结构
Linux不提供统一API，依赖/sysfs虚拟文件系统。物理核心由/sys/devices/system/cpu/cpu*/topology/core_id定义，逻辑线程由/sys/devices/system/cpu/cpu*/topology/thread_siblings_list列出同属一个物理核的所有逻辑CPU ID。
典型误操作是只读physical_package_id或core_siblings_list：前者标封装（socket），后者是同一物理核所有线程的掩码（十六进制），不如thread_siblings_list直观。例如cpu0的thread_siblings_list内容为0,4，说明逻辑核0和4共享同一物理核。
- 遍历
/sys/devices/system/cpu/cpu[0-9]*/目录，跳过软链接（如cpu0可能是cpu0的符号链接） - 对每个
cpuN，读取topology/core_id和topology/thread_siblings_list，按core_id分组即可得映射 -
thread_siblings_list格式为逗号分隔的数字列表（如"0,4"），而thread_siblings是十六进制掩码（如"0x11"），优先用前者 - 需检查
topology/core_id是否存在——某些老内核或容器环境可能缺失，此时可退化为用physical_package_id + core_id联合判重
跨平台封装时避免硬编码拓扑假设
没有“通用C++标准函数”能直接返回映射关系，std::thread::hardware_concurrency()只返回逻辑处理器总数，完全不反映物理结构。强行跨平台抽象容易出错：比如认为“前N个逻辑核必属不同物理核”，但NUMA架构或BIOS关闭超线程时，逻辑核ID和物理核绑定无固定规律。
- 不要用
std::thread::hardware_concurrency()推导物理核数——它可能返回0（实现未定义），且不区分物理/逻辑 - 避免基于
pthread_setaffinity_np反向探测：设置亲和性后测性能差异不可靠，受调度器干扰大 - 若需最小化跨平台代码，可封装为两个独立实现，对外暴露统一结构体：
struct CoreMapping { int physical_core_id; std::vector<int> logical_ids; };</int> - 注意ARM平台（如Apple Silicon）无传统超线程，但有性能核（P-core）/能效核（E-core）之分，
topology/core_type文件存在，需额外处理
实际使用中容易忽略的边界情况
真实环境远比文档示例复杂：虚拟机可能伪造拓扑、容器可能限制可见CPU、Windows Server的Group机制会让逻辑核ID超过64（此时ProcessorMask需配合GROUP_AFFINITY）。这些场景下，单纯看bit位或/sysfs路径会漏判或误判。
- Windows上逻辑核数＞64时，
GetLogicalProcessorInformation不返回完整信息，必须改用GetLogicalProcessorInformationEx配合RelationGroup - Docker默认只暴露部分CPU，
/sys/devices/system/cpu/下cpu*目录数量 ≠nproc输出，需结合/sys/fs/cgroup/cpuset/cpuset.cpus判断可用逻辑核 - 某些BIOS设置“同步多线程=禁用”后，
thread_siblings_list会显示单个数字（如"0"），此时物理核数=逻辑核数，但不能据此认为所有机器都如此 - 即使获取到映射，也不能假设线程绑核后性能一定提升——现代调度器已很智能，盲目
pthread_setaffinity_np反而可能降低缓存命中率
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
