这是个很常见的conda构建与日常安装之间的依赖差异问题，核心原因在于两者的依赖解析逻辑和运行环境存在本质区别，具体可以从以下几个方面拆解：

• 依赖解析的环境与目标不同
  conda install是针对你当前已有的环境做依赖求解，会优先考虑环境中已安装包的兼容性，同时solver会倾向于选择最贴合用户日常使用场景的包变体。而conda build是在一个完全干净的隔离构建环境中求解依赖，这个环境没有你日常环境的包约束，默认配置（比如通道优先级、特性开关）可能和你平时使用的环境不一样，导致solver选择了不同的hdf5变体。

• 包变体的选择逻辑差异
  你遇到的两个hdf5包是同一版本（1.10.6）的不同构建变体，通过末尾的build字符串区分：nompi_h6a2412b_1114带S3 VFD支持，而nompi_h3c11f04_101不带。conda的solver在不同场景下的变体偏好不同：

  • 日常conda install时，solver可能默认倾向于选择不带特殊特性的通用变体，或者你的环境里已有其他包间接约束了不能带S3 VFD；
  • conda build的干净环境没有这些约束，加上某些conda通道（比如conda-forge）默认会优先推送带扩展特性的变体，就会拉取到带S3 VFD的版本。

• 构建配方的依赖约束不足
  如果你的软件包的meta.yaml里没有明确约束hdf5的具体变体或版本细节，conda build的solver只会满足h5py 3.2.1的最低依赖要求（比如hdf5>=1.10.6），而不会自动匹配你日常安装时的那个特定变体。这种情况下，solver会选择通道中满足依赖的“最优”包，而这个“最优”的判定标准和日常安装场景不一样。

解决方法 #

要让conda build使用你需要的hdf5版本，可以在meta.yaml里明确约束具体的包变体：

requirements:
  build:
    - hdf5 1.10.6 nompi_h3c11f04_101
  run:
    - hdf5 1.10.6 nompi_h3c11f04_101

如果不想绑定死build字符串，也可以通过约束排除带S3 VFD的变体，或者在conda_build_config.yaml里调整构建配置，禁用S3 VFD的默认启用，确保solver拉取到正确的包。

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