为何Python的两个APT缓存访问API返回不同软件包集合？

一、两个API的定位差异 #

• apt_pkg.Cache：是APT底层C++库的直接Python绑定，完全对应APT缓存的原始结构，能访问缓存中所有包条目，包括APT内部用于依赖管理的特殊包类型。它偏向底层操作，功能基础，无额外封装过滤。
• apt.Cache：基于apt_pkg封装的高层Python API，提供更符合Python习惯的接口（如可迭代、属性化访问）。加载时会自动对原始缓存数据做筛选，只保留对用户更有意义的、可安装的真实软件包。

二、包集合数量差异的原因 #

你观察到apt.Cache返回的包是apt_pkg.Cache的子集，核心原因在于两者的加载逻辑：

1. 过滤特殊包类型：apt_pkg.Cache包含APT缓存里的所有条目，比如虚拟包（仅用于依赖声明，无实际安装文件）、过渡包（用于版本迁移过渡）、以及只有依赖记录但无对应可安装版本的包；而apt.Cache默认会过滤掉这些特殊包，只保留有实际可安装二进制文件的包。
2. 架构与可用性筛选：apt.Cache会自动排除当前系统架构不支持、或在源中已被标记为不可用的包，而apt_pkg.Cache会保留这些条目，因为它们是APT缓存原始数据的一部分。

比如你测试中出现的92488 vs 64447的差异，就是因为apt_pkg.Cache包含了近3万个这类特殊包条目。

三、为何脚本会同时使用两者 #

像Ubuntu的apt_check.py这类脚本同时用两个API，是为了兼顾全量覆盖和便捷操作：

• apt_pkg.Cache能遍历到所有存在于缓存中的包，不会漏掉任何条目；
• apt.Cache提供了更丰富的高层方法和属性（如直观的依赖查询、安装状态判断、版本信息获取），适合获取包的详细业务数据。
  所以脚本会先用apt_pkg.Cache拿到全量包列表，再通过包名从apt.Cache中取出对应的高层对象来处理。

内容的提问来源于stack exchange，提问作者rgov