最准确方式是读/sys/devices/system/cpu/cpu0/cache/index0/coherency_line_size，x86-64通常为64字节，ARM64可能为64或128；若路径不存在则需回退至lscpu | grep "Cache line"并取min值，因缓存一致性协议按最小行粒度操作。
直接读 /sys/devices/system/cpu/cpu0/cache/index0/coherency_line_size
这是最准、最快、无需 root 的方式。Linux 内核从 2.6.32 起就把 L1 数据缓存行大小暴露在 sysfs 里，coherency_line_size 就是硬件实际使用的缓存行字节数。
执行：
cat /sys/devices/system/cpu/cpu0/cache/index0/coherency_line_size
- x86-64 机器绝大多数返回
64（单位：字节） - ARM64 可能是
64或128，取决于芯片微架构（如某些 ThunderX 平台） - 只查
cpu0即可，多核系统中所有逻辑 CPU 的 L1d 缓存行大小一致 - 如果路径不存在，说明内核未启用该接口（常见于嵌入式或老内核），需换方法
lscpu 输出里的 Cache line sizes 怎么看
lscpu 是次选方案，它读的是内核缓存的拓扑信息，比 sysfs 略滞后，但胜在兼容性好、输出易读。
执行：
lscpu | grep "Cache line"
典型输出：
Zynq Linux Hardware Debug
下载
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
Cache line sizes: min: 64 bytes, max: 64 bytes
或：
Cache line sizes: min: 64 bytes, max: 128 bytes
- 必须取
min值作为对齐依据——因为 cache coherency 协议按最小粒度操作 - 即使
max是 128，填 64 对齐也完全安全；填 128 却可能在某些 ARM 上失效 - 若容器里没装
util-linux（即无lscpu），别硬凑，直接回退到 sysfs
为什么不能只看 /proc/cpuinfo 里的 cache size
/proc/cpuinfo 中的 cache size 字段通常只反映 L3 总容量（比如 cache size : 20480 KB），和缓存行大小完全无关。
- 它不提供任何关于“一行多少字节”的信息
- 试图用
grep "cache size" /proc/cpuinfo来查缓存行，结果一定是空忙 - 有些旧内核甚至根本不写这个字段，或者只写 L2/L3，L1 行大小压根不出现
代码里做对齐时，alignas(64) 填多少才对
结构体整体对齐值必须 ≥ 实际缓存行大小，且是 2 的幂。实践中填 64 最稳妥。
- 即使真实值是 128（少见），
alignas(64)仍有效——只是略保守 - 填
128而实际是 64，没问题；但反过来，填32就大概率触发 false sharing - 千万别只对单个字段加对齐（如
uint64_t hits __attribute__((aligned(64)))），这无法防止整个结构体跨缓存行布局 - 验证是否生效：用
offsetof检查结构体起始地址是否 % 64 == 0
真正容易被忽略的是：缓存行大小不是“性能调优的可选项”，而是 false sharing 的硬边界。查错一次，比后期反复压测定位快十倍。
