Windows用GetLogicalProcessorInformation获取核心映射，需两次调用获取缓冲区大小并筛选RelationProcessorCore类型；Linux解析/sys/devices/system/cpu/cpu*/topology/core_siblings_list；macOS无法可靠获取映射，仅能获总数。
Windows上用 GetLogicalProcessorInformation 获取核心映射
Windows 提供了最直接的 API： GetLogicalProcessorInformation，它返回一组 SYSTEM_LOGICAL_PROCESSOR_INFORMATION 结构，其中包含物理核心、逻辑处理器（超线程）的拓扑关系。关键不是“有多少核”，而是每个 Mask 对应哪些逻辑处理器属于哪个物理核心或 NUMA 节点。
常见错误是只调用一次不检查返回值——该函数首次调用会返回所需缓冲区大小（ERROR_INSUFFICIENT_BUFFER），必须先分配足够内存再重试。另外，Relationship 字段必须为 RelationProcessorCore 才表示物理核心层级；RelationNumaNode 或 RelationCache 是干扰项，需跳过。
实操建议：
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 先调用
GetLogicalProcessorInformation(NULL, &dwSize)获取缓冲区大小，再malloc或std::vector<byte></byte>分配内存 - 遍历返回的每条记录，只处理
ProcessorCore类型；每个这样的记录含一个Mask（KAFFINITY），其 bit 位代表所属逻辑处理器 ID - 用
_BitScanForward或手动 bit 检查可枚举 mask 中所有 set bit，得到该物理核心对应的逻辑处理器索引列表 - 注意：逻辑处理器 ID（0-based）由 Windows 分配，不一定连续，但
GetSystemInfo().dwNumberOfProcessors给出总数
Linux 上解析 /sys/devices/system/cpu 目录结构
Linux 没有统一 syscall 返回映射表，依赖 sysfs 文件系统暴露的拓扑信息。/sys/devices/system/cpu/cpu*/topology/ 下每个 CPU 目录都有 topology_core_id 和 topology_physical_package_id，而 topology_core_siblings_list 直接给出同属一个物理核心的所有逻辑 CPU 列表（逗号分隔，支持范围如 0-3）。
立即学习“C++免费学习笔记（深入）”；
容易踩的坑是硬编码路径或忽略权限：非 root 用户可读大部分 topology 文件，但某些内核配置（如禁用 CONFIG_SCHED_DEBUG）可能导致 topology_* 文件缺失；此时 fallback 方案是解析 /proc/cpuinfo 的 physical id 和 core id 字段，但字段存在性不保证，且不同架构（ARM vs x86）输出格式略有差异。
实操建议：
- 遍历
/sys/devices/system/cpu/cpu[0-9]*目录，对每个cpuN读取topology/core_id和topology/physical_package_id，组合成唯一键（package_id, core_id） - 更可靠的是读
topology/core_siblings_list：它明确列出“这个物理核心上有哪些逻辑 CPU”，无需自己聚合 - 用
std::regex或简单字符串拆分解析范围表达式（如"0,2-3"→ {0,2,3}） - 避免依赖
/proc/cpuinfo的顺序——它不保证按逻辑 CPU ID 排序，且字段名大小写可能因内核版本浮动（如cpu coresvsCPU cores）
macOS 上没有公开 API，只能靠 sysctl + 猜测
Apple 不提供标准接口获取物理/逻辑核心映射。sysctl 可查到 hw.ncpu（逻辑数）、hw.physicalcpu（物理核心数）、hw.logicalcpu（同 ncpu），但无法知道哪个逻辑 CPU 属于哪个物理核心。
真实情况是：macOS 内核内部使用 processor_set_t 和 Mach API 管理调度域，但这些 API 未向用户态开放；第三方库（如 libcpuid）在 macOS 上基本失效，因为 Apple 禁止访问 MSR（模型特定寄存器）来读取拓扑信息。
实操建议：
- 接受事实：无法可靠获取映射表。最多只能假设超线程开启时，逻辑 CPU 0/1 属于同一物理核心，2/3 属于下一个……但这在 M 系列芯片（无超线程）或混合架构（如 Intel 12th+ Gen）下完全不成立
- 若必须绑定线程到物理核心，用
pthread_setaffinity_np+CPU_SET配合hw.physicalcpu做粗粒度分配（例如把前 N 个线程绑到前 N 个物理核心，不关心具体逻辑 ID） - 不要尝试解析
/usr/sbin/sysctl -a | grep machdep.cpu输出——machdep.cpu.core_count和thread_count只给总数，无映射
跨平台封装时别碰“自动识别”这种需求
试图写一个函数 get_cpu_topology() 在 Windows/Linux/macOS 上返回统一结构，大概率失败。三个平台的数据源、语义、可靠性差距太大：Windows API 精确但仅限 Win；Linux sysfs 明确但依赖内核配置；macOS 根本没出口。
真正可行的路径是分场景设计：
- 性能敏感场景（如线程绑定、NUMA 感知分配）：只在 Windows/Linux 上启用拓扑感知，macOS 降级为均匀轮询或按物理核心数做简单分区
- 监控/展示用途：Windows 和 Linux 可展示完整映射；macOS 只显示
physical: X, logical: Y，不画连线 - 别在构建期硬编码逻辑——比如假设 “logical = physical × 2”，M1/M2/M3 芯片是 8P8E 或 10P4E，Intel 新 CPU 有 2P/3P/4P 混合，AMD Zen4 有 CCX 拓扑，全都不符合倍数关系
最常被忽略的一点：即使拿到映射表，CPU 热插拔、节能状态（C-state）、内核调度策略（如 sched_smt 关闭超线程）都会让运行时实际可用的逻辑 CPU 集合动态变化。映射表只是静态快照，不能替代运行时 GetProcessAffinityMask 或 sysconf(_SC_NPROCESSORS_ONLN)。
