Linux下获取缓存行大小最可靠的方法是读取/sys/devices/system/cpu/cpu0/cache/index0/coherency_line_size，该路径直接暴露内核探测到的L1数据缓存行大小，通常为64字节；C++17起可使用std::hardware_destructive_interference_size作为编译期近似值，但非运行时真实值。
用 std::hardware_destructive_interference_size 获取缓存行大小（C++17 起）
这是最直接、最标准的方式，编译器在 C++17 中引入了这两个常量，它们基于目标平台的 ABI 和硬件假设推导出推荐的缓存行边界：std::hardware_destructive_interference_size（用于避免伪共享）和 std::hardware_constructive_interference_size（用于鼓励数据局部性）。
注意：它不是运行时探测，而是编译期常量，值由编译器厂商根据主流 CPU（如 x86-64 通常设为 64）预设。若你用 GCC/Clang/MSVC 编译 x86-64 程序，std::hardware_destructive_interference_size 几乎总是 64；ARM64 可能是 64 或 128，取决于 ABI 定义。
实操建议：
- 仅适用于 C++17 及以上，需开启对应标准（如
-std=c++17） - 不能反映当前运行机器的真实值（比如你在 64 字节机器上交叉编译到 128 字节 ARM 板，该常量仍可能是 64）
- 适合写可移植高性能代码，但不适合做硬件诊断
#include <new>
#include <iostream>
<p>int main() {
std::cout << std::hardware_destructive_interference_size << "\n"; // 通常输出 64
}Linux 下读取 /sys/devices/system/cpu/cpu0/cache/index0/coherency_line_size
这是最可靠、最贴近真实硬件的方法——直接从内核缓存信息接口读取。Linux 内核在启动时会枚举 CPU 缓存，并将一级数据缓存（L1d）的缓存行大小暴露在此路径下（多数情况下，L1d 行大小与 L2/L3 一致）。
立即学习“C++免费学习笔记（深入）”；
常见错误现象：路径不存在（比如容器中未挂载 sysfs）、权限不足、或某些精简内核禁用了 cache info 接口。
实操建议：
- 读取前先检查路径是否存在且可读：
access("/sys/devices/system/cpu/cpu0/cache/index0/coherency_line_size", R_OK) - 优先读
index0（通常是 L1 数据缓存），避免依赖index2（L3）在多核系统上可能为空 - 该值以十进制 ASCII 字符串形式存储，需用
std::stoi或strtol解析 - 若失败，可 fallback 到
/proc/cpuinfo中搜索cache_alignment（但该字段在较新内核中已被弃用）
Windows 下调用 GetLogicalProcessorInformationEx 查缓存描述
Windows 没有类似 Linux 的 sysfs 接口，但可通过 GetLogicalProcessorInformationEx + RelationCache 获取每级缓存的详细信息，包括 LineSize 字段。
容易踩的坑：
- 必须传入足够大的缓冲区，首次调用会返回所需大小（
dwReturnLength），否则直接失败并返回ERROR_INSUFFICIENT_BUFFER - 返回结构是嵌套的：
PSYSTEM_LOGICAL_PROCESSOR_INFORMATION_EX→ 多个CACHE_DESCRIPTOR，需遍历找Level == 1 && Type == CacheData的条目 - 某些旧版 Windows（如 Win7 SP1）可能不返回
LineSize，此时应 fallback 到硬编码 64 - 需要链接
kernel32.lib，且最低支持 Windows Vista
关键字段提取逻辑示意：
CACHE_DESCRIPTOR* desc = &cacheInfo->Cache;
if (desc->Level == 1 && desc->Type == CacheData) {
cacheLineSize = desc->LineSize; // 这就是你要的值
}跨平台封装时为什么别信 __builtin_assume 或宏探测
有人试图用编译器内置函数（如 GCC 的 __builtin_assume）或预定义宏（如 __x86_64__）推断缓存行大小，这不可靠。
原因很实在：
- x86-64 架构本身不规定缓存行大小，Intel 和 AMD 当前主流是 64 字节，但 Knights Landing 是 128 字节，某些嵌入式 x86 SoC 可能用 32 字节
-
__aarch64__宏无法区分 Cortex-A53（64B）、Neoverse N2（64B）和某些自研核心（可能 128B） - 编译目标架构 ≠ 运行时硬件 —— 你用 aarch64 工具链编译的程序，完全可能跑在 128B 行大小的 Apple M 系列芯片上（实际仍是 64B，但这个结论只能实测，不能假设）
真正需要运行时确定缓存行大小的场景（如 lock-free ring buffer 对齐、NUMA 感知内存池），必须走 OS 提供的硬件接口，而不是猜。
最后提醒一句：即使读到了正确值，也要注意对齐操作本身是否生效——alignas(N) 在栈上不一定保证地址被 N 整除（取决于栈指针初始状态），堆上用 aligned_alloc 才真正可控。
