Linux通过/sys/devices/system/cpu/cpuN/topology/thread_siblings_list精准映射逻辑线程到物理核心，Windows需用GetLogicalProcessorInformation解析RelationProcessorCore的ProcessorMask位图，跨平台不可依赖hardware_concurrency()或sysconf。
Linux下用/sys/devices/system/cpu目录解析物理核心与逻辑线程映射
Linux内核把CPU拓扑信息以文件形式暴露在/sys/devices/system/cpu下，这是最轻量、无需特权、不依赖第三方库的获取方式。关键路径是每个cpuN子目录里的topology/core_id和topology/thread_siblings_list。
常见错误是直接读topology/physical_package_id或topology/core_siblings_list却忽略线程级关联——它们只反映包/核级分组，不能直接得出“哪个逻辑CPU属于哪个物理核心”。真正能定位线程归属的是thread_siblings_list：它列出与当前逻辑CPU共享同一物理核心的所有逻辑CPU编号（包括自己）。
- 遍历
/sys/devices/system/cpu/cpu*目录，跳过非数字后缀（如cpu0、cpu1有效，cpu0/online不是目录） - 对每个
cpuN，读取topology/core_id得到其所属物理核心ID（注意：该ID在单个物理包内唯一，跨包可能重复） - 读取
topology/thread_siblings_list，解析出逗号分隔或连字符范围（如"0,1"或"4-7"），这些数字就是同核超线程伙伴 - 建议同时读
topology/physical_package_id来区分不同CPU插槽，避免误把不同物理CPU上的同编号核心当作一个
Windows上用GetLogicalProcessorInformation获取准确拓扑
Windows没有统一的伪文件系统，必须调用WinAPI。GetLogicalProcessorInformation返回的PSYSTEM_LOGICAL_PROCESSOR_INFORMATION数组按关系类型分组，其中RelationProcessorCore对应物理核心，RelationNumaNode和RelationCache可辅助验证层级，但核心映射靠RelationProcessorCore结构体里的ProcessorMask位图。
容易踩的坑是误以为ProcessorMask中每个置位bit代表一个逻辑CPU编号——实际上它是一个64位掩码，bit位置0~63对应逻辑处理器索引，需用_BitScanForward或手动位运算提取所有置位索引。例如掩码0x3（二进制11）表示逻辑CPU 0 和 1 属于同一个物理核心。
立即学习“C++免费学习笔记（深入）”；
- 调用前先用
GetLogicalProcessorInformation(NULL, &dwSize)获取所需缓冲区大小，再分配内存重试 - 遍历返回数组时，仅处理
Relationship == RelationProcessorCore的条目；其他类型（如RelationCache）的ProcessorMask不能直接用于核心映射 - 每个
RelationProcessorCore条目对应一个物理核心，其ProcessorMask里所有置位bit共同构成该核心上的逻辑线程集合 - 注意：某些旧版Windows（如XP）不支持此函数，需检查
GetLastError()是否为ERROR_INSUFFICIENT_BUFFER而非ERROR_INVALID_FUNCTION
跨平台C++封装要点：别硬编码线程数，也别信std::thread::hardware_concurrency()
std::thread::hardware_concurrency()只返回可用逻辑线程总数，完全不体现拓扑结构。它可能返回0（未知）、或包含禁用的逻辑CPU（如BIOS关闭了超线程但系统未更新计数），更无法区分核心与线程归属。
真实场景中，你需要的是“哪些逻辑CPU共享缓存”或“绑核时避开同一物理核心”，这就必须拿到核心ID到逻辑CPU列表的映射。跨平台实现时，优先判断OS：Linux走/sys，Windows走API，macOS则需用sysctlbyname("hw.logicalcpu")配合hw.physicalcpu和machdep.cpu.thread_count间接推算——但macOS不公开每个逻辑CPU对应的物理核心ID，只能假设超线程配对固定（如CPU0/CPU1同核），该假设在Apple Silicon上不成立（M系列无传统超线程），所以macOS下严格意义上的物理拓扑不可靠。
- 不要用
sysconf(_SC_NPROCESSORS_ONLN)替代拓扑查询：它只返回在线逻辑CPU数，无结构信息 - Linux下若
/sys不可读（如容器被挂载限制），fallback方案极有限：可尝试lscpu命令解析输出，但需shell执行权限且格式易变 - Windows下若
GetLogicalProcessorInformation失败，不要退化到GetSystemInfo().dwNumberOfProcessors——它等价于hardware_concurrency()，仍无拓扑
实际绑定线程前务必验证逻辑CPU是否在线且可用
即使从拓扑接口读到了CPU 3属于核心0，也不能直接用sched_setaffinity或SetThreadGroupAffinity去绑——该逻辑CPU可能已被系统禁用（如热插拔、节能策略关闭）或不在当前进程允许掩码内。
Linux下检查/sys/devices/system/cpu/cpu3/online内容是否为"1"；Windows下用GetProcessAffinityMask确认当前进程能否访问目标逻辑CPU，再用GetThreadAffinityMask确认线程当前掩码是否包含它。否则sched_setaffinity会返回EINVAL，SetThreadGroupAffinity返回FALSE且GetLastError()为ERROR_INVALID_PARAMETER。
- 容器环境（如Docker）中
/sys/devices/system/cpu可能被只读挂载或过滤，导致部分cpuN目录缺失，此时应以sysfs实际可见为准，而非预设CPU数量 - 绑定前用
cpuset（Linux）或Job Object（Windows）限制进程可见CPU集，再在此范围内做拓扑解析，避免查询到进程根本无法使用的CPU - 物理核心ID本身无全局唯一性——不同物理包内的核心0是独立的，必须结合
physical_package_id或Group字段才能唯一标识一个物理核心
