最准确方式是读取/sys/devices/system/cpu/cpu0/cache/index0/coherency_line_size，x86-64通常为64字节，arm64可能为64或128；lscpu仅提供min/max范围，对齐必须依据最小值，且结构体需整体对齐而非单字段。
直接读 /sys 是最准的方式
别信 lscpu 里模糊的 “Cache line sizes” 字段，它只给 min/max 范围，而硬件实际按最小值做一致性操作。真正要对齐缓存行（比如避免 false sharing），必须拿到确切数值。
-
cat /sys/devices/system/cpu/cpu0/cache/index0/coherency_line_size—— 这是 L1 数据缓存的行大小，x86-64 几乎总是64，ARM64 可能是64或128 - 所有逻辑 CPU 的 L1d 行大小一致，查
cpu0就够了；index0对应 L1d，index1是 L1i（通常相同） - 如果路径不存在（老内核、嵌入式或容器没挂载 sysfs），说明该接口未启用，得换方法
lscpu 只能辅助验证
lscpu | grep "Cache line" 输出像 Cache line sizes: min: 64 bytes, max: 64 bytes 或 min: 64, max: 128，这时你必须用 min 值——哪怕实际 L3 行大小是 128，只要最小是 64，对齐就必须按 64 字节来。
- 某些 ARM 平台（如 ThunderX）会显示
min: 64, max: 128，填128对齐反而浪费空间，且不解决 false sharing -
lscpu读的是内核缓存的拓扑信息，重启或微码更新后可能滞后，/sys才是实时暴露的硬件属性 - 容器里若没装
util-linux，lscpu命令可能根本不可用
代码里怎么用这个值
结构体对齐不是为了“好看”，是为了让不同线程访问的字段不落在同一缓存行里。单字段对齐（比如只给 uint64_t hits 加 aligned(64)）完全无效。
- 用
alignas(64)修饰整个结构体：struct alignas(64) counter_t { uint64_t hits; uint64_t misses; }; - GCC/Clang 写法：
struct counter_t { ... } __attribute__((aligned(64))); - 对齐值必须是 2 的幂，且 ≥ 实际缓存行大小；填
64最安全（兼容 128 场景），填32或128都可能出问题
为什么不能只看 /proc/cpuinfo 的 clflushsize
/proc/cpuinfo 里的 clflushsize 和 cache_alignment 字段常被误当作缓存行大小，但它只是 clflush 指令的操作粒度，不等于硬件一致性协议使用的缓存行大小。
- 在绝大多数 x86-64 系统上二者碰巧相等（都是 64），但 ARM64 上
clflushsize可能为 0（不支持该指令），而coherency_line_size依然有效 - 有些旧平台或虚拟化环境里，
clflushsize缺失或为 0，但/sys/.../coherency_line_size仍可读 - 依赖
clflushsize写对齐逻辑，会在 ARM 或某些 Xen/KVM 场景下静默失效
