CPUID指令仅能判断硬件是否支持超线程（查EAX=1时EDX bit28），不能确认是否启用；启用状态需结合lscpu中“Thread(s) per core”值（为2表示启用）或/proc/cpuinfo中相同physical id与core id的processor条目数是否大于1来验证。
怎么用CPUID指令判断超线程是否启用
仅靠 CPUID 指令本身不能直接告诉你“超线程已启用”，它只告诉你 CPU **是否支持**超线程（HT）。是否启用，取决于 BIOS 设置和操作系统调度策略。真正能确认启用状态的，是运行时的逻辑处理器拓扑信息。
执行 CPUID 时传入 EAX = 1，检查返回的 EDX 寄存器第 28 位（bit 28）：若为 1，说明硬件支持 HT；若为 0，则不支持（如早期 Pentium M 或某些嵌入式 CPU）。
-
IsHyperThreading()这类函数名容易误导——它实际检测的是htflag 是否存在，不是当前系统是否启用了超线程 - 即使 bit 28 = 1，Linux 下仍需验证
/proc/cpuinfo中相同physical id+ 相同core id的条目是否多于 1 个 - Windows 下可调用
GetLogicalProcessorInformation()，比手动解析CPUID更可靠
为什么 std::thread::hardware_concurrency() 不能代替超线程检测
这个函数返回的是当前环境可见的逻辑处理器总数（含超线程虚拟核），但它不区分物理核心与超线程线程，也不反映 BIOS 中 HT 是开是关。它可能返回 0（比如 musl libc 环境或容器被 cgroup 限制 CPU 后），也可能在 WSL2 中返回宿主机值而非真实可用数。
- 若
std::thread::hardware_concurrency() == 8，你无法知道这是 4 核 × 2 线程（HT 开），还是 8 核 × 1 线程（HT 关） - 它不读取 CPUID，也不访问
/proc/cpuinfo，纯属运行时环境探测，和硬件能力无关 - 跨平台项目中，建议用
sysconf(_SC_NPROCESSORS_ONLN)（Linux/macOS）或GetSystemInfo()（Windows）兜底，再结合CPUID判断 HT 支持
Linux 下验证超线程是否启用的三步法
别只信 flags 字段里的 ht ——那只是支持声明。启用与否，得看调度器看到的拓扑结构。
立即学习“C++免费学习笔记（深入）”；
- 运行
lscpu | grep "Thread(s) per core"：输出为2表示启用；1表示禁用或不支持 - 检查
/proc/cpuinfo：grep -E "^(processor|physical id|core id)" /proc/cpuinfo | head -12，找两个processor编号，若它们的physical id和core id完全一致，就是超线程启用的铁证 - 对比
grep "siblings" /proc/cpuinfo | head -1和grep "cpu cores" /proc/cpuinfo | head -1：若前者是后者的整数倍（通常是 2 倍），且大于 1，则 HT 已启用
C++26 新增的 set_affinity 能否反推超线程状态
不能。虽然 std::this_thread::set_affinity({0, 1}) 允许你把线程绑到两个逻辑核上，但无法得知它们是否属于同一物理核心。C++26 的 std::execution::available_parallelism() 返回的是“可用并行单元数”，它不暴露底层拓扑关系。
-
is_hyperthread()这个方法目前仅存在于部分提案草案或实验性实现中，标准库尚未提供 - 即便你能拿到每个核心的
numa_node()和core_id()，仍需额外查询硬件拓扑数据（如 Linux 的/sys/devices/system/cpu/cpu*/topology/）才能交叉验证 - 生产代码中，应把超线程状态视为部署环境配置项，而非运行时动态探测项——尤其在容器或云环境中，
/proc/cpuinfo可能被虚拟化层截断或伪造
超线程检测真正的难点不在指令层面，而在如何把 CPUID 的静态能力、内核暴露的拓扑、以及容器/虚拟化层的运行时限制三者对齐。别指望一个函数调用就得出确定结论。
