结论：不能靠std::thread::hardware_concurrency()，也不能只读/proc/cpuinfo或单次调用Win32 API——必须分平台用底层接口解析拓扑：Windows需两次调用GetLogicalProcessorInformation筛选RelationProcessorCore并解析ProcessorMask位图；Linux须遍历/sys/devices/system/cpu/cpu[0-9]*/topology/读core_id、physical_package_id和thread_siblings_list；macOS仅能估算总数，无法获取精确映射。
直接说结论：不能靠 std::thread::hardware_concurrency()，也不能只读 /proc/cpuinfo 或调一次 Win32 API —— 必须分平台、用底层系统接口解析拓扑结构，否则拿到的只是逻辑核总数，不是“哪个逻辑核属于哪个物理核心”。
Windows 上必须两次调用 GetLogicalProcessorInformation()
这个函数不返回“映射表”，而是返回扁平数组，每项含 Relationship 和 ProcessorMask。第一次调用传 NULL 是为了获取缓冲区大小，否则数据被截断；第二次才真正填入数据。
- 只保留
Relationship == RelationProcessorCore的条目 —— 每个对应一个物理核心 -
ProcessorMask是位图（KAFFINITY类型），bit 位置0~63对应逻辑 CPU 编号，需用_BitScanForward或手动移位提取所有置位位 - 别把
__popcnt64(ProcessorMask)当作物理核心数 —— 那是该核心上线程数（1 或 2）；物理核心数 =RelationProcessorCore条目总数 - 超过 64 个逻辑核时，
GetLogicalProcessorInformation()会漏高位，必须改用GetLogicalProcessorInformationEx(RelationProcessorCore)
Linux 上必须遍历 /sys/devices/system/cpu/cpu[0-9]*/topology/
没有统一 syscall，/proc/cpuinfo 的 core id 字段在某些内核配置或容器中缺失或伪造，唯一可靠路径是解析 sysfs。
Miller CSV TSV JSON 数据处理器
下载
Miller (mlr) 是一个命令行工具，用于查询、整形和重新格式化名称索引数据，如 CSV、TSV、JSON 和 JSON Lines。它将 awk、sed、cut、join 和 sort 的功能整合到一个专为结构化数据处理而构建的单一工具中。
- 对每个真实目录（跳过软链接如
cpu0→online），读取：topology/core_id、topology/physical_package_id、topology/thread_siblings_list -
thread_siblings_list格式为逗号分隔或范围（如"0,4"或"8-11"），直接给出同物理核心的所有逻辑 CPU 编号 - 不要用
topology/thread_siblings（十六进制掩码），解析易错；也不要依赖lscpu输出，格式随版本变化 - 若
topology/目录不存在，说明内核未启用CONFIG_SCHED_SMT或CONFIG_SCHED_MC，此时只能退回到sysconf(_SC_NPROCESSORS_ONLN)获取逻辑核数，无法构建映射
macOS 上无法获取精确映射，只能估算
系统不暴露物理核心与逻辑线程的绑定关系，sysctl 只能拿到总数：
立即学习“C++免费学习笔记（深入）”；
-
hw.logicalcpu：当前可用逻辑核数（受 cgroup / VM 限制） -
hw.physicalcpu：报告的物理核心数（可能不准，尤其在虚拟化下） -
hw.logicalcpu_max和hw.physicalcpu_max：理论最大值，但无拓扑信息 - 没有等价于 Linux
thread_siblings_list或 WindowsProcessorMask的接口，无法知道逻辑核 0 和 1 是否共享同一物理核心
跨平台封装时最常被忽略的一点：physical_package_id（Linux）和 RelationProcessorPackage（Windows）语义一致，都对应物理插槽；但 core_id 在两边不是同一概念 —— Linux 是插槽内编号，Windows 不提供该 ID，只能靠 ProcessorMask 分组后推断相对顺序，且不保证连续或可比。
