在 Linux 系统中，dmidecode -t memory 是目前唯一能够较稳定读取原始 SPD 相关信息的命令，可提供 Part Number 等用于内存颗粒级溯源的关键字段；而 Manufacturer 与 Speed 字段则需要结合 Handle 分组进行提取，并过滤空插槽信息，此外还需通过查询厂商文档，利用 Part Number 反向确认具体的内存颗粒型号。
dmidecode -t memory 是唯一能获取颗粒级信息的命令
在 Linux 环境下，如果想查看内存条的具体颗粒信息，例如单颗芯片型号、位宽、厂商代号等，就必须通过 SMBIOS/DMI 表来获取——dmidecode -t memory 是当前唯一能够稳定读取原始 SPD 相关数据的工具。像 lshw、/proc/meminfo 以及 lsmem 这类常见命令都不会直接访问 SPD，因此无法看到内存颗粒的细节信息。
需要注意的是，颗粒型号本身（例如 Micron MT40A512M16JE-083E 或 Samsung K4AAG085WB-BCTD）通常不会直接显示在 dmidecode 输出结果中。该命令通常只会给出 Part Number（如 M378A2K43CB1-CTD），而这个编码还需要结合厂商公开资料进一步反查，才能定位到具体颗粒型号。不过，Part Number 依然是进行内存颗粒溯源最关键的入口信息。
- Part Number 字段（
Part Number:）是识别内存颗粒的核心起点，不同品牌的命名规则并不相同：三星通常以 M 开头，海力士多以 HMA 开头，镁光则常见 MT 开头 - Manufacturer 字段（
Manufacturer:）如果显示为0x0000或NO DIMM，通常表示 BIOS 未写入相关信息，或 SPD 数据存在损坏，不能仅凭该字段判断颗粒来源或真伪 - Type 字段（
Type:）与 Speed 字段（Speed:）需要结合判断颗粒规格，例如 DDR4-3200 对应特定 MT/s 数值，实际颗粒标称频率应与之匹配
为什么 grep Speed: 经常漏掉信息或发生错配
如果直接使用 grep Speed: 解析 dmidecode -t memory 的输出，结果通常并不可靠。原因在于该命令输出并不是简单的扁平文本结构：每一根内存条通常对应独立的 Handle 块，而 Speed: 与 Part Number: 还可能分布在不同的子 Handle 中（例如主 Handle 负责描述插槽信息，子 Handle 才真正包含 SPD 数据）。这种结构上的分离，很容易导致 A 插槽的 Part Number 与 B 插槽的 Speed 被错误关联，最终得到误导性的内存信息。
- 建议先使用
sudo dmidecode -t memory | grep -A2 -B2 "Size: [0-9]+ GB"确认哪些插槽实际安装了内存 - 再通过
awk按 Handle 分块处理，确保Slot:、Size:、Part Number:、Speed:四项信息都来自同一根物理内存条 - 空插槽（
Size: No Module Installed）通常也会带出不完整字段，必须提前过滤，否则会严重干扰判断结果
decode-dimms 能读取 SPD 芯片，但依赖 I2C 总线是否可用
如果主板 BIOS 提供支持，并且系统中的 I2C 总线驱动已经正确加载，那么 decode-dimms（来自 i2c-tools 软件包）可以直接读取内存条上的 SPD EEPROM，从理论上说，它比 dmidecode 更接近颗粒原始信息。但这个工具并不是任何环境下都可用：
- 需要启用内核配置
CONFIG_I2C_DESIGNWARE_PLATFORM=y，而很多云服务器或精简版 Linux 系统默认并未开启 - 执行前通常需要先探测 I2C 适配器：
sudo i2cdetect -l，如果没有任何输出，通常说明硬件不支持或相关驱动尚未加载 - 即使已经探测到适配器，执行
sudo decode-dimms时仍可能提示No SMBus driver installed，这时需要安装linux-modules-extra或手动执行 modprobe - 部分 DDR5 内存条采用 SMBus 3.0 或 DMI 3.0 协议，旧版本的
decode-dimms可能无法正确识别，返回结果可能为空或出现乱码
不要指望 /sys/firmware/dmi/tables/ 直接提取颗粒编码
乍一看，使用 sudo strings /sys/firmware/dmi/tables/DMI | grep -i "part|manufacturer" 似乎像是不安装额外工具也能查看内存信息的快捷方法，但实际上它输出的只是原始二进制字符串流，并不存在明确稳定的字段边界。这意味着 Part Number 很容易被截断、拼接错误，甚至根本没有被写入 DMI 表——在一些国产 BIOS 或笔记本固件中，省略 SPD 相关数据的情况并不少见。
更重要的是，真正的内存颗粒信息（例如芯片丝印）本身就不属于 DMI 规范中的标准字段，它通常只存在于 SPD EEPROM 的特定地址区域（例如 DDR4 SPD offset 0x40~0x7F），而 /sys/firmware/dmi/tables/ 仅导出 SMBIOS 表，并不包含完整的 SPD 原始字节数据。因此，想靠这一方式反推出内存颗粒型号，成功率非常低。
如果确实需要确认内存颗粒型号，通常还是要先借助 dmidecode 获取 Part Number，再去查询厂商官方 datasheet，或者结合第三方数据库（如 Crucial Scanner、Kingston Finder）进行交叉验证——这一步基本无法完全自动化，仍然需要人工判断与确认。
