free -h 的 Mem: 行 total 值即为最准的物理内存总量，是内核上报的运行时实际可用容量，已剔除显存、固件等保留内存；/proc/meminfo 需手动换算且含未启用区域，dmidecode 仅反映插槽硬件信息而非系统识别量。
free -h 是最快、最可靠的查物理内存总量的方法，输出中的 Mem: 行 total 值即为实际可用的物理内存容量。别信 /proc/meminfo 里没换算的 KB 数，也别依赖 dmidecode ——它可能显示插槽容量而非系统识别量。
free -h 看 total 字段最准
这是内核直接上报的运行时物理内存总量，已剔除保留内存（如显存、固件占用），反映真实可用基础。注意三点：
-
free -h的Mem:行total是最终答案，比如15Gi就是约 16GB 物理内存 - 不要看
available或free——它们是剩余可用量，不是总量 - 如果看到
total明显小于你预期（如标称 32G 却只显示 31.2G），大概率是 BIOS 预留或集成显卡占用了部分内存
/proc/meminfo 的 MemTotal 要手动换算
该值虽权威，但单位是 KB，且未过滤所有保留区，容易误判：
- 执行
grep MemTotal /proc/meminfo得到类似MemTotal: 32941268 kB - 需手动除以 1024² ≈ 31.4 GiB；除以 1000² ≈ 32.9 GB ——混用单位会差出近 1.5GB
- 某些 ARM 或嵌入式平台该值可能包含未启用的内存区域，
free已做裁剪，更贴近实际
dmidecode 显示的是硬件插槽信息，不是系统识别量
它读取 SMBIOS 表，告诉你“插了什么”，但不保证“系统用了多少”：
- 需要
sudo权限：sudo dmidecode -t memory | grep -E "Size|Type" - 可能显示
Size: 16 GB× 2，但若其中一根接触不良或 BIOS 关闭了某通道，free仍只报 16GB - 在虚拟机中常返回
No SMBIOS nor DMI entry point found，此时完全不可用
为什么不用 lshw 或 lsmem？
它们看似全面，但引入额外抽象层，反而增加歧义：
-
lshw -class memory输出冗长，size字段有时指单条容量，有时指总和，且默认不显示单位 -
lsmem主要面向内存块（memory block）管理，常见于大页/热插拔场景，在普通服务器上字段意义模糊 - 两者都依赖 udev/dbus，容器环境或最小化系统常缺失，而
free是 procps-ng 核心工具，几乎无依赖
真正要确认“物理内存总量”，盯死 free -h 的 Mem: → total。其他命令只适合交叉验证或排查硬件配置异常——比如 free 报 16G，dmidecode 却显示两根 16G 条，那基本能断定有一根没被识别。
