Linux通过/sys/devices/system/cpu/cpu*/topology/提供底层CPU拓扑信息，Windows需多次调用GetLogicalProcessorInformation并按关系类型拼合，跨平台封装应分层抽象Socket/Core/SMT索引，避免直接映射OS原生ID。
Linux下用lscpu和/sys/devices/system/cpu/解析物理拓扑
Linux内核通过/sys文件系统暴露了完整的CPU拓扑信息，比lscpu输出更底层、更可靠，且无需额外依赖。关键路径是/sys/devices/system/cpu/cpu*/topology/下的软链接：
-
topology_core_siblings_list：本核心所属的同物理核超线程列表（如0,4表示逻辑CPU 0和4共享同一物理核） -
topology_physical_package_id：Socket ID（从0开始） -
topology_core_id：该逻辑CPU在所属物理核内的编号（非全局唯一） -
topology_thread_siblings_list：同一线程组（即超线程对）的逻辑CPU列表
注意：topology_core_id仅在同一个topology_physical_package_id内有意义；跨Socket时值可能重复。读取时需遍历所有cpu*目录，按physical_package_id分组，再按core_id聚合逻辑CPU。
Windows下用GetLogicalProcessorInformation获取关系映射
Windows不提供直接的Socket/Core编号，而是返回LOGICAL_PROCESSOR_RELATIONSHIP枚举类型的拓扑关系。必须调用多次，分别传入RelationProcessorCore、RelationNumaNode、RelationProcessorPackage才能拼出完整层级：
- 先调用一次获取所需缓冲区大小，再分配内存并重调用
-
RelationProcessorPackage对应Socket（每个PROCESSOR_RELATIONSHIP结构体的GroupMask字段含该Socket下所有逻辑CPU掩码） -
RelationProcessorCore中，每个结构体的Flags字段若含LCPU_FLAG_SMT，说明该核心支持超线程，其GroupMask包含该物理核上所有逻辑线程 - 无法直接获得“Core ID”数值，只能靠位图计算相对位置（例如在某个Socket内，第几个非重叠的
GroupMask就可视为Core序号）
容易忽略的是：多NUMA节点系统中，RelationNumaNode返回的节点ID与Socket ID无固定对应关系，不能假设1:1。
立即学习“C++免费学习笔记（深入）”；
C++跨平台封装的关键难点：如何统一Socket/Core标识
Linux和Windows对“核心编号”的抽象完全不同：Linux用整数ID（topology_physical_package_id），Windows只给位图掩码。强行统一编号会引入歧义，建议按用途分层设计：
- 对外暴露三个层级：Socket、Core、SMT（逻辑线程），每层用独立索引（如
socket_idx,core_idx_in_socket,smt_idx_in_core） - 不暴露原始OS ID，避免用户误用（例如把Linux的
topology_core_id当全局Core序号） - 缓存首次探测结果，因为
/sys文件读取或GetLogicalProcessorInformation调用开销较大，且运行时拓扑几乎不变 - Windows下若进程被绑核（
SetThreadGroupAffinity），GetLogicalProcessorInformation仍返回全系统拓扑，不代表当前可用范围
最易踩的坑是试图用std::thread::hardware_concurrency()反推拓扑——它只返回逻辑CPU总数，完全不反映物理结构。
验证拓扑是否正确的简单方法
仅靠API返回数据无法100%确认映射正确，需交叉验证：
- 检查总逻辑CPU数是否等于
sum(socket_count × cores_per_socket × threads_per_core) - 在Linux下，对比
lscpu | grep -E "(Socket|Core|Thread)"输出与程序解析/sys的结果是否一致 - 在Windows下，用
coreinfo -s（Sysinternals工具）输出的“*”标记位置，对照程序中每个逻辑CPU的(socket_idx, core_idx, smt_idx)三元组是否空间连续 - 若发现某Socket下core数为奇数（如3），大概率是BIOS禁用了部分核心，此时应以
/sys或GetLogicalProcessorInformation为准，而非CPU型号标称值
真实环境里，虚拟机、容器、云实例常隐藏部分拓扑细节（比如vCPU不暴露Socket），这时/sys可能只有单个physical_package_id，而GetLogicalProcessorInformation返回的RelationProcessorPackage数量也可能少于物理硬件——这不是代码bug，是运行环境限制。
