最快方法是执行lscpu | grep -i 'cache'，其中l1d/l1i为每核私有容量，l3为全芯片共享总量；若需验证拓扑或排查虚拟化/微码异常，则须进入/sys/devices/system/cpu/cpu0/cache/读取level=3且shared_cpu_list覆盖全部逻辑cpu的size值。
直接用 lscpu 最快，但别只信它显示的数字——L1d cache 和 L1i cache 是每核私有容量，L3 cache 才是整颗 CPU 的共享总量；真要确认细节（比如是否分片、是否被虚拟化截断），得进 /sys/devices/system/cpu/cpu0/cache/ 看原始拓扑。
怎么用 lscpu 快速查各级缓存大小
lscpu 输出里明确标了 L1d cache、L1i cache、L2 cache、L3 cache 四行，单位统一为 KB 或 K/M。注意：
-
L1d cache: 32K表示每个逻辑核心独占 32KB 数据缓存，不是全 CPU 总和 -
L3 cache: 12288K表示整颗 CPU 所有核心共享的总容量（即 12MB），和核心数无关 - 某些 ARM 平台或旧内核可能不显示
L2 cache行，这时不能默认它不存在，得查/sys - 执行
lscpu | grep -i 'cache'可快速过滤，避免滚动大量无关字段
为什么 /proc/cpuinfo 的 cache size 字段不可靠
/proc/cpuinfo 里那个 cache size 字段，多数情况下等于 L3 总量（单位 KB），但它没说明层级，也不保证一致性：
- 在部分 ARM64 或老款 AMD CPU 上，
cache size可能指向 L2，甚至为空 - 虚拟化环境（如 KVM + QEMU）中，该字段常被模拟为固定值（如 4096K），与物理硬件脱钩
- 没有
L1d/L1i单独字段，无法区分数据/指令缓存 - 想脚本化提取，建议优先用
lscpu --parse=cache（新版支持），而不是解析/proc/cpuinfo
怎么从 /sys 目录手动验证 L3 是否真实共享
当 lscpu 显示异常（比如 L3 数值为 0、或怀疑微码降级导致缓存拓扑错乱），必须直读 sysfs：
- 每个逻辑 CPU 下的
/sys/devices/system/cpu/cpu0/cache/index*/对应一个缓存单元 - 先确认哪个是 L3：
cat /sys/devices/system/cpu/cpu0/cache/index*/level，输出为3的才是 L3 - 再验证共享范围：
cat /sys/devices/system/cpu/cpu0/cache/index*/shared_cpu_list，若显示0-15且你机器有 16 个逻辑 CPU，基本可确认是全核共享 - 真实容量看：
cat /sys/devices/system/cpu/cpu0/cache/index*/size，单位就是 KB（如12288） - 注意：不同核心看到的
index*数量可能不一致，但只要 level=3 的目录存在且shared_cpu_list覆盖全部逻辑 CPU，就可信
哪些场景下必须绕过 lscpu 查 /sys
以下情况 lscpu 输出大概率失真，不能作为调优依据：
- Intel Cascade Lake 或 Ice Lake 平台在微码降级后，
lscpu可能把 L2 错标为 shared，L3 消失 - KVM 虚拟机中启用了
cache=none或cache=emulate，lscpu显示的 L3 常为 0 或固定小值 - 容器运行时（如 containerd）启用 CPU 隔离（
cpuset.cpus）后，lscpu仍显示整机 L3，但实际进程只能访问部分缓存行 - 需要知道缓存行大小（
coherency_line_size）或路数（ways_of_associativity）时，lscpu完全不暴露这些字段
真正做缓存敏感编程（比如手动对齐、避免 false sharing）时，/sys 下的 coherency_line_size 和 number_of_sets 才是关键，而这些连 lscpu 的 man page 都没提过。
