linux通过/sys/devices/system/cpu/cpu*/topology/获取cpu拓扑，windows需调用getlogicalprocessorinformation；两者physical_package_id与relationprocessorpackage语义一致，但core_id无直接对应，应使用(package, core_in_package, thread_in_core)三元组建模，避免依赖hardware_concurrency()。
Linux 下用 /sys/devices/system/cpu 解析物理插槽与核心拓扑
Linux 内核通过 /sys 文件系统暴露了完整的 CPU 拓扑信息，无需 root 权限即可读取。关键路径是 /sys/devices/system/cpu/cpu*/topology/ 下的 symlink 和数值文件。
每个逻辑 CPU（cpu0, cpu1…）目录下：
– topology/physical_package_id 表示物理 CPU 插槽编号（从 0 开始）
– topology/core_id 表示该插槽内核心编号（非全局唯一）
– topology/thread_siblings_list 给出同核心超线程兄弟的逻辑 CPU 列表（如 0,2）
实操建议：
• 遍历 /sys/devices/system/cpu/cpu[0-9]*/topology/physical_package_id 获取所有逻辑 CPU 所属插槽
• 同时读取 topology/core_id，按 (package_id, core_id) 二元组去重，即得实际物理核心数
• 注意：某些 ARM 平台可能无 physical_package_id，改用 topology_die_id 或 fallback 到 cpuid 指令
Windows 上调用 GetLogicalProcessorInformation 构建拓扑树
Windows 不提供类似 Linux 的 sysfs 接口，必须调用 Win32 API。核心函数是 GetLogicalProcessorInformation，它返回一系列 SYSTEM_LOGICAL_PROCESSOR_INFORMATION 结构体，每项含 Relationship 字段区分层级（RelationProcessorCore、RelationNumaNode、RelationProcessorPackage）。
容易踩的坑：
• 返回缓冲区大小需先调用一次获取所需字节数，否则直接传 NULL 可能返回 ERROR_INSUFFICIENT_BUFFER
• RelationProcessorPackage 对应物理插槽，其 ProcessorMask 是位图，需用 _BitScanForward 或手动 bit 运算提取对应逻辑 CPU 索引
• 同一 RelationProcessorCore 下多个逻辑 CPU 共享一个 core_id，但 Windows 不直接暴露该 ID；需按 ProcessorMask 分组后，结合 RelationProcessorPackage 和 RelationProcessorCore 的嵌套关系推导层级
C++ 跨平台封装的关键难点：插槽/核心/线程 ID 的语义对齐
Linux 的 physical_package_id 和 Windows 的 RelationProcessorPackage 语义一致，但 core_id 在两边含义不同：Linux 的 core_id 是插槽内局部编号；Windows 不提供等价字段，只能靠分组推断相对顺序（且无保证连续）。这意味着「同一物理核心的两个超线程」在两系统中无法用相同整数标识。
实操建议：
• 不要试图构造全局唯一的 core_id，而是维护三元组 (package, core_in_package, thread_in_core)
• 在 Linux 下直接读 topology/core_id 和 topology/thread_siblings_list
• 在 Windows 下，对每个 RelationProcessorCore 条目，统计其 ProcessorMask 中 bit 数量作为 thread_in_core，再按首次出现顺序分配 core_in_package
• 注意：Intel 和 AMD 在某些旧型号上对 HTT（超线程）的支持差异可能导致 thread_siblings_list 为空或不完整
避免依赖 std::thread::hardware_concurrency()
std::thread::hardware_concurrency() 只返回可用逻辑 CPU 数量（即 sysconf(_SC_NPROCESSORS_ONLN) 或 GetSystemInfo().dwNumberOfProcessors），完全不反映物理拓扑。它无法区分插槽、核心或超线程，也不能告诉你哪些逻辑 CPU 属于同一物理核心。
典型误用场景：
• 用它做 NUMA 感知内存分配 → 失败，因不知道 NUMA node 映射
• 用它决定线程绑核策略 → 可能跨插槽调度，引发高延迟
• 认为返回值等于物理核心数 → 在启用超线程的机器上必然翻倍
真正需要拓扑信息时，必须绕过标准库，直连 OS 接口。C++23 的 std::execution 也未定义拓扑感知调度器，目前仍需手动绑定。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
