物理内存总量应以 free -h 的 mem: 行 total 值为准，单位 gib，该值已剔除显存、bios 保留等不可用部分；/proc/meminfo 的 memtotal 需换算且可能高估；dmidecode 等工具反映硬件配置而非实际可用量。

直接看 free -h 的 Mem: 行 total 值

这就是你要的物理内存总量，单位是 GiB（二进制），比如显示 31.2Gi，就约等于 33.5GB 物理内存（按十进制算）。这个值是内核当前实际识别并可用的容量，已自动剔除显卡显存、BIOS 保留区、PCIe BAR 空间等不可用部分。不需要 root 权限，几乎所有发行版默认自带。

别拿 /proc/meminfo 的 MemTotal 直接当结论

grep MemTotal /proc/meminfo 输出的是 KB 单位，比如 MemTotal: 32941268 kB，必须手动换算：

• 除以 1024 * 1024 → ≈ 31.4 GiB（推荐，和 free -h 对齐）
• 除以 1000 * 1000 → ≈ 32.9 GB（硬盘厂商式，会高估约 1.5GB）

更重要的是：MemTotal 可能包含 BIOS 未启用的内存块（尤其在 ARM 或嵌入式平台），而 free 已做裁剪，更贴近运行时真实可用量。

PyCharm 2026.2.0.1 Linux版

PyCharm 2026.2.0.1 Linux版提供 JetBrains 官方 2026.2.0.1 版本安装包，适合需要指定 PyCharm 版本进行 Python 项目开发、运行和调试的用户。

下载

别信 dmidecode -t memory 显示的插槽容量

sudo dmidecode -t memory | grep -E "Size|Locator" 读取的是 SMBIOS 表，反映的是“主板 BIOS 记录的硬件配置”，不是系统实际用了多少：

• 若内存条接触不良、BIOS 关闭了通道、或运行在单通道模式下，dmidecode 仍可能报 16 GB × 2，但 free -h 只会显示 16Gi
• 在虚拟机里常返回 No SMBIOS nor DMI entry point found，完全不可用
• 需要 root 权限，Alpine 等最小化系统通常不带该命令

为什么不用 lshw 或 lsmem？

它们引入额外抽象层，字段含义模糊，反而增加判断成本：

• lshw -class memory 的 size 字段有时指单条容量、有时指总和，且默认不带单位，脚本解析易错
• lsmem 主要面向内存块（memory block）管理，常见于大页/热插拔场景，在普通服务器上输出字段（如 SIZE, STATE）意义不直观
• 两者都依赖 udev/dbus，在容器、initramfs 或精简系统中常缺失；而 free 只读 /proc/meminfo，稳定可靠

真正要确认“物理内存总量”，盯死 free -h 的 Mem: → total。其他命令只适合交叉验证——比如看到 free -h 报 31.2Gi，再用 dmidecode 看是否插了两条 16G，就能判断是不是 BIOS 预留了约 0.8Gi 给集成显卡。