Linux需解析/sys/devices/system/cpu/下topology文件获取精确CPU拓扑，Windows用GetLogicalProcessorInformation两次调用获取核心隶属关系，macOS仅能通过sysctl估算逻辑与物理核数且无法精确映射。
Linux下用lscpu和/sys/devices/system/cpu/读取拓扑
Linux没有标准C++ API能直接跨发行版获取CPU拓扑，得靠解析系统文件或调用外部命令。最稳的方式是读/sys/devices/system/cpu/下的目录结构——每个cpuN子目录里有topology/core_id、topology/thread_siblings_list等文件，它们真实反映物理核心与逻辑线程的绑定关系。
注意thread_siblings_list内容是逗号分隔的CPU编号（如0,4），表示这些逻辑核共享同一个物理核心；而core_id对同一物理核心下的所有超线程都一样。别依赖lscpu输出的“Core(s) per socket”字段——它只给汇总值，没法反推单个线程归属。
- 先遍历
/sys/devices/system/cpu/下所有cpu[0-9]*目录 - 对每个CPU，读
topology/core_id和topology/physical_package_id，构建core_id → {logical_cpus}映射 - 用
std::ifstream逐行读，别用system("lscpu")——后者输出格式随版本变化，解析易崩 - 记得检查文件是否存在：某些内核配置下
topology/目录可能缺失，此时应降级为仅用sysconf(_SC_NPROCESSORS_ONLN)获逻辑核数
Windows上用GetLogicalProcessorInformation获取关系
Windows提供GetLogicalProcessorInformation函数，返回SYSTEM_LOGICAL_PROCESSOR_INFORMATION数组，其中Relationship字段区分RelationProcessorCore、RelationNumaNode等类型，能准确提取核心与线程隶属关系。
关键陷阱是：该API返回的缓冲区大小不固定，必须先调用一次传nullptr获取所需字节数，再分配内存重试。返回结构体里的ProcessorMask是位图，需用BitScanForward或手动移位遍历置位位来提取对应逻辑CPU编号。
立即学习“C++免费学习笔记（深入）”；
- 两次调用
GetLogicalProcessorInformation：第一次查缓冲区大小，第二次填数据 - 遍历返回数组时，只处理
Relationship == RelationProcessorCore的项 -
ProcessorMask类型是ULONG_PTR，32位系统最多支持32个逻辑核，64位系统最多64个——超出需用GetLogicalProcessorInformationEx - 别把
RelationGroup当成核心拓扑用，那是为NUMA组设计的，和物理核心无关
macOS只能靠sysctl拼凑有限信息
macOS没暴露完整的拓扑视图，sysctl能拿到hw.logicalcpu、hw.physicalcpu、hw.logicalcpu_max等键值，但无法知道哪个逻辑核属于哪个物理核。Apple Silicon（M1/M2）甚至不保证hw.physicalcpu反映真实大核/小核数量——它只是调度器可见的“性能核心”数。
唯一可行的间接方式是结合host_processor_info（需mach/mach_host.h）获取每个处理器的cpu_type和cpu_subtype，但仅适用于旧Intel Mac，且需要root权限，在SIP启用时大概率失败。
- 优先读
sysctlbyname("hw.logicalcpu", ...)和sysctlbyname("hw.physicalcpu", ...) - 若两者相等，说明无超线程；若
logicalcpu > physicalcpu，可推测存在超线程，但无法确定配对关系 - 不要尝试解析
/proc或/sys路径——macOS根本没有这些目录 - 在Apple Silicon上，接受“无法精确映射”的事实，业务层按逻辑核数做负载均衡更实际
跨平台封装要注意线程亲和力与缓存层级
即使正确解析出拓扑，std::thread::hardware_concurrency()返回的只是逻辑核总数，不体现物理分布。真正影响性能的是线程是否绑到同一物理核心的超线程上——这会导致L1/L2缓存争用。所以拓扑数据必须配合pthread_setaffinity_np（Linux/macOS）或SetThreadAffinityMask（Windows）使用。
另一个常被忽略的点是：L3缓存通常按物理Package（Socket）划分，而非Core。若程序有大量跨核通信，应优先把协作线程绑在同一个Package内的不同Core上，而不是跨Package——后者延迟高得多。
- 拓扑解析结果建议缓存一次，避免重复读文件或调系统API
- 绑定线程前，确认目标CPU在线：
sysfs里online文件或Windows的GetActiveProcessorCount - macOS上
pthread_setaffinity_np效果有限，Apple推荐用dispatch_queue_attr_make_with_qos_class控制QoS，而非硬绑核 - 别假设拓扑静态不变——热插拔CPU、节能策略动态关闭核心都会改变实际可用拓扑
