Solving environment: Unsuccessful initial attempt using frozen solve. Retrying...

Question

在使用 Conda 安装或更新包时，用户常遇到“Solving environment: Unsuccessful initial attempt using frozen solve. Retrying...”提示，随后环境解析陷入长时间卡顿甚至失败。该问题通常源于复杂的依赖关系冲突或通道（channel）配置不当。当 Conda 无法通过“frozen solve”策略（即固定已安装包版本）快速求解依赖时，会回退到更耗时的全量解析。常见诱因包括混合使用 conda-forge 与 defaults 通道、存在过时或不兼容的包版本，或环境中包数量庞大。解决方法包括：清理索引缓存（`conda clean --all`）、明确指定通道优先级、简化安装命令，或改用 mamba 作为替代求解器以提升解析效率。

Answer 1

一、问题现象与初步诊断

在使用 Conda 安装或更新包时，用户常遇到如下提示：

Solving environment: Unsuccessful initial attempt using frozen solve. Retrying...

该提示表明 Conda 在尝试使用“frozen solve”策略（即保持当前已安装包版本不变）快速解析依赖失败后，转而进行全量环境求解。此过程可能持续数分钟甚至更久，严重时导致命令无响应。

常见触发场景包括：

• 执行 conda install 安装新包
• 运行 conda update --all 升级所有包
• 跨通道安装（如同时涉及 conda-forge 与 defaults）
• 环境中已存在大量第三方包

二、根本原因分析

Conda 的依赖解析器基于 SAT 求解算法，需满足所有包的版本约束和依赖兼容性。当环境复杂度上升，求解空间呈指数级增长。以下是主要成因：

成因类别	具体表现	影响程度
通道混合使用	conda-forge 与 defaults 提供同名但构建方式不同的包	高
缓存污染	本地索引元数据过期或损坏	中
包版本锁定	某些包被固定版本或存在冲突 pin	高
环境膨胀	超过 100+ 包的环境显著增加求解难度	中高
Python 版本不一致	不同包要求不同 Python ABI 兼容层	中

三、系统性解决方案

以下为从轻量到深度的递进式解决路径：

1. 清理缓存：执行 conda clean --all 清除 pkg 缓存、索引及临时文件
2. 指定通道优先级：通过配置强制统一来源，例如：

   conda config --add channels conda-forge
   conda config --set channel_priority strict

3. 简化安装命令：避免一次性安装多个非相关包，分步执行并明确版本约束
4. 创建干净环境：使用最小基础环境隔离项目依赖

   conda create -n myenv python=3.9
   conda activate myenv

5. 启用 Mamba 替代求解器：Mamba 使用 C++ 编写的 libsolv，速度提升可达 10–100 倍

   mamba install package_name

6. 导出并审查环境文件：通过 conda env export > environment.yml 检查是否存在冗余或冲突依赖
7. 使用 --dry-run 预演：在实际操作前验证可行性

   conda install package_name --dry-run

8. 降级或 pin 关键包：对引发冲突的核心包手动控制版本范围

四、高级调试手段与流程图

对于长期受困于依赖解析的团队，建议建立标准化诊断流程：

# 启用详细日志输出
CONDA_VERBOSITY=3 conda install package_name

结合 mamba repoquery depends 分析依赖树结构。

以下是推荐的故障排查流程图：

graph TD
            A[出现"Solving environment"卡顿] --> B{是否首次出现?}
            B -->|是| C[执行 conda clean --all]
            B -->|否| D[检查环境规模]
            C --> E[重试安装]
            D -->|包数量>150| F[考虑拆分环境]
            D -->|正常| G[检查 channel 配置]
            G --> H[是否混合 defaults 和 conda-forge?]
            H -->|是| I[设置 channel_priority strict]
            H -->|否| J[尝试 mamba 替代]
            I --> K[重新创建环境]
            J --> L[成功?]
            K --> L
            L -->|否| M[导出 environment.yml 并人工审计]
            L -->|是| N[记录解决方案]

五、生产环境最佳实践

为避免此类问题反复发生，建议实施以下工程化措施：

• 采用 environment.yml 管理依赖，禁止裸调 conda install
• 统一使用 mamba 作为默认 CLI 工具
• 定期重构环境，移除未使用包（conda autoremove）
• 对 CI/CD 流水线使用预构建的 Docker 镜像以规避现场解析
• 监控关键包的构建字符串（build string），确保 ABI 一致性
• 利用 conda-lock 生成跨平台锁文件，实现可复现构建
• 建立内部私有通道（如 Artifactory）统一软件源
• 培训团队成员理解“通道污染”风险
• 设置自动化脚本定期执行 conda clean
• 文档化常见陷阱及应对策略