free -h 的 mem: total 值即为真实可用物理内存总量，单位 gib（如31.2gi≈32gb），已剔除显存、固件保留等不可用部分；swap total 不是物理内存，available 才反映真正可分配内存。

直接看 free -h 的 Mem: total 值

这就是你要的物理内存总量，单位是 GiB（二进制），比如显示 31.2Gi，实际就是约 32GB 物理内存。这个值由内核在启动时探测并裁剪后上报，已自动剔除显存、固件保留区、PCIe BAR 空间等不可用部分，是运行时真实可用容量。

常见错误现象：看到 available 或 free 列数值小，就误以为总内存少；或把 Swap: total 当成物理内存。

• free -h 不需要 root 权限，几乎所有发行版默认自带，解析稳定可靠
• 如果 total 比标称容量小（如插了 32G 却只报 31.2Gi），大概率是 BIOS 预留或集成显卡占用，不是命令不准
• 别用 free -m 或 free -g——单位固定易误读，-h 才能自适应显示 GiB/ MiB

为什么不用 grep MemTotal /proc/meminfo

它确实权威，但容易踩两个坑：单位是 KB，且未完全过滤 BIOS 未启用或保留区域。例如输出 MemTotal: 32941268 kB，必须手动换算：

• 除以 1024² → ≈ 31.4 GiB（推荐，和 free -h 对齐）
• 除以 1000² → ≈ 32.9 GB（硬盘厂商式，比真实可用多出近 1.5GB）
• 某些 ARM 或嵌入式平台中，该值可能包含 BIOS 未启用的内存块，而 free 已做裁剪

dmidecode -t memory 只反映插槽硬件信息

它读的是 SMBIOS 表，本质是 BIOS 记录的“插了什么”，不是“系统用了多少”。执行需 root 权限，在容器、Alpine 或最小化系统中常缺失；虚拟机里还可能直接报 No SMBIOS nor DMI entry point found。

PyCharm 2026.2.0.1 Linux版

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

下载

典型误导场景：

• 主板插了两条 16GB，但其中一根接触不良 → dmidecode 仍显示 32GB，free -h 正确报 16Gi
• BIOS 关闭了内存通道或降频 → dmidecode 显示频率 3200MHz，实际运行在 2133MHz，free 不关心这些，只管可用总量

别被 lshw 和 lsmem 干扰判断

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

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

真正要确认“物理内存总量”，盯死 free -h 输出中 Mem: 行的 total 值。其他命令只适合交叉验证——比如怀疑内存插槽接触不良时，再跑一遍 dmidecode 对比插槽识别状态。