坑边闲话：用了多年 Miniconda，直到某天 du -sh ~/miniconda3 显示 8GB 的时候，我决定认真审视一下这套工具链。Micromamba 是现代 Python 虚拟环境和包管理的版本答案，因此我决定使用新工具替代用了若干年的 Miniconda.

1. 为什么我要放弃 Miniconda·

Miniconda 本身没有什么大问题，只是它在使用过程中积累了太多历史包袱。

  1. 体积。一个精简安装的 Miniconda，在正常使用几年后很容易膨胀到 5~8 GB 以上。这不是什么奇怪的事情，conda 的包缓存机制会把每次安装的包文件保留在 pkgs/ 目- 录下，以便后续复用。但问题是，这些缓存不会自动清理，加上历史环境的残留，磁盘占用会持续增长。
  2. base 环境的污染。默认情况下，conda 启动后会自动激活 base 环境，很多人会在 base 里直接安装包，导致 base 和项目环境之间的边界模糊。一旦 base 环境被污染，- 排查问题的成本会显著上升。
  3. Python 升级后的历史残留。每次升级 Python 版本，旧版本的 site-packages 不会自动清理，conda update --all 在某些情况下也无法完全处理版本冲突，最终只- 能靠重建环境来解决。
  4. solver 速度。conda 的依赖解析器在面对复杂依赖图时会非常慢，有时候一个简单的 conda install 会卡在 Solving environment 上好几十秒。

这些问题叠加在一起，让日常的环境管理变得越来越不优雅。本来我选择 Miniconda 而不是 Anaconda, 就有轻量化、最小化的诉求，如今看到 8GB 的存储占用，我也是非常崩溃。MacBook Pro 的 SSD 本来就寸土寸金，我实在不想为不清不楚的文件而占用宝贵的空间。

2. micromamba 是什么？·

micromamba 是 mamba 项目的一个子集，核心定位是：一个无需 base 环境的独立 conda 客户端。

要理解 micromamba，需要先理清 conda 生态的几个层次：

  • conda：Anaconda 公司开发的包管理器，使用 Python 实现的原生 solver，速度较慢。下列两个软件均提供 conda 命令行。
    • Anaoconda: 自带大量科学计算相关的 package, 属于个人可免费使用的商业软件；
    • Miniconda: 一个没有自带 Python 包的轻量化 Anaconda.
  • mamba：conda 的一个替代品，使用 C++ 重写了 solver（libmamba），兼容 conda 命令，但仍然依赖 base Python 环境
  • micromamba：完全独立的二进制，不依赖 Python，不需要 base 环境，直接使用 libmamba solver.

micromamba 和 conda/mamba 的最大区别在于：它没有 base 环境的概念。安装 micromamba 只需要把一个二进制文件放到 $PATH，然后配置 shell 初始化脚本即可。整个工具本身只占几十 MB。

从架构上看：

1
2
3
conda          = Python 运行时 + conda solver + conda CLI
mamba          = Python 运行时 + libmamba solver + mamba CLI
micromamba     = libmamba solver + micromamba CLI（纯 C++，无 Python 依赖）

micromamba 实现了 conda 的绝大部分常用命令子集，日常使用几乎无感。唯一的区别是某些 conda 专有的高级功能（如 conda doctor、conda content-trust）不在 micromamba 的支持范围内。

3. micromamba 的核心优势·

3.1 单一二进制，零依赖·

micromamba 是一个静态链接的可执行文件，不依赖 Python，不依赖任何系统库（除了 libc）。这意味着可以在任何 Linux/macOS 系统上直接运行，包括 Docker 镜像、CI 环境、嵌入式 Linux 等场景。

3.2 没有 base 环境·

conda 的 base 环境是一个长期存在的设计包袱。micromamba 直接消除了这个概念——所有环境都是用户创建的具名环境，base 只是一个空的根目录，不会自动激活，不会污染默认 PATH。

3.3 libmamba solver 的速度优势·

libmamba 的依赖解析速度比 conda 原生 solver 快几个数量级。一个在 conda 里需要 3~5 分钟的环境创建操作，在 micromamba 里通常在 20~30 秒内完成。这个差异在频繁创建、重建环境的工作流中非常明显。

3.4 兼容 conda 生态·

micromamba 完全兼容 conda 的包格式、channel 机制和 .condarc 配置文件，可以直接使用 conda-forge、bioconda 等所有 conda channel。

4. conda-forge 与默认 Anaconda 源的区别·

conda 的包来自不同的 channel（频道），最常见的两个是：

  • defaults (repo.anaconda.com)
    • Anaconda 公司维护的官方 channel，包含 Anaconda 自行打包和测试过的包。优点是稳定性有保障，包之间的兼容性测试更严格；缺点是更新较慢，包的数量不如 conda-forge 多，且 Anaconda 在 2023 年更新了商业使用条款，企业用户使用需要注意许可证问题。
  • conda-forge (conda.anaconda.org/conda-forge)
    • 社区维护的 channel, 任何人都可以提交新包或更新现有包的 recipe。它是目前包数量最多、更新最快的 conda channel：
      • 包数量：超过 25,000 个（defaults 约 7,000 个）
      • 更新频率：通常在上游发布后数天内跟进
      • Apple Silicon 支持：conda-forge 对 osx-arm64 的支持远早于 defaults, 且质量更好
      • Python 版本支持：conda-forge 通常最先支持最新的 Python 版本

conda-forge 还有一个值得关注的设计：它使用统一的 CI 流水线（staged-recipes + feedstock 机制）来构建所有包，确保构建环境一致性。这使得 conda-forge 的包在跨平台兼容性上表现相当好。

5. conda-forge 已成为主流·

这个趋势有几个结构性原因。

首先是 Python 数据科学生态的快速迭代。PyTorch、JAX、NumPy、SciPy 等核心库的更新节奏很快，conda-forge 的快速跟进能力使它成为这些包的事实分发渠道。其次是非 Python 依赖的管理。conda 相比 pip 的核心优势之一是能管理 C/C++ 库依赖，比如 CUDA 工具链、MKL、OpenBLAS 等。conda-forge 在这方面的包覆盖更全，且对 ARM 架构的支持更完整。第三是商业合规问题。随着 Anaconda 商业条款收紧，越来越多的企业和开源项目开始把 defaults channel 替换为 conda-forge, 以避免许可证风险。

许多开发者现在的配置方案是：完全只使用 conda-forge, 不添加 defaults channel。这实际上是一个相当干净的设定：包来源单一，依赖解析更快，没有 channel 优先级混乱的问题。

在 .mambarc 或 .condarc 中配置：

1
2
3
channels:
  - conda-forge
channel_priority: strict

channel_priority: strict 意味着当多个 channel 都有某个包时，严格按照 channel 列表顺序选择，不会因为版本号做跨 channel 的混合解析，避免依赖地狱。

6. micromamba 的实际使用方法·

6.1 安装·

在 macOS 上使用 Homebrew：

1
brew install micromamba

或者使用官方安装脚本（跨平台）：

1
"${SHELL}" <(curl -L micro.mamba.pm/install.sh)

安装后，执行 shell 初始化：

1
micromamba shell init --shell zsh --root-prefix ~/.local/share/micromamba

重启终端后生效。

6.2 创建环境·

最简单的创建：

1
micromamba create -n py314 python=3.14

创建时直接安装包：

1
micromamba create -n dev python=3.14 numpy pandas

指定 channel：

1
micromamba create -n dev python=3.14 -c conda-forge

如果已经配置好 .mambarc，通常不需要每次都指定 -c conda-forge。

6.3 激活环境·

1
micromamba activate py314

退出环境：

1
micromamba deactivate

6.4 在环境中安装包·

1
2
micromamba install pip
micromamba install numpy scipy matplotlib

6.5 验证安装·

1
2
3
python --version
pip --version
which python

6.6 禁止 base 自动激活·

1
micromamba config set auto_activate_base false

这一步很重要。默认配置下，micromamba 不会像 conda 那样自动激活 base, 但显式配置能确保这个行为不会在未来被意外修改。保持 base 不激活的好处是：默认终端的 PATH 是干净的系统 PATH, 不会有任何 conda 相关的路径前置，只有在主动 micromamba activate 后才会改变环境。

6.7 查看已有环境·

1
micromamba env list

6.8 删除环境·

1
micromamba env remove -n dev

7. micromamba 的目录结构与配置·

7.1 XDG 标准路径·

micromamba 遵循 XDG Base Directory 规范，默认数据目录是：

1
~/.local/share/micromamba

目录结构：

1
2
3
4
5
6
~/.local/share/micromamba/
├── envs/           # 所有虚拟环境
│   ├── py314/
│   ├── dev/
│   └── ml/
└── pkgs/           # 包缓存
  • envs/：每个命名环境是一个独立的目录，包含 Python 解释器、site-packages 和相关二进制
  • pkgs/：包缓存目录，conda 包在解压安装前会先缓存在这里，多个环境可以复用同一份缓存

这个目录结构比 Miniconda 的 ~/miniconda3/ 要清晰得多，所有内容都在 ~/.local/share/micromamba/ 下，不会散落在用户主目录的多个位置。

7.2 micromamba info 输出解读·

micromamba info 提供了当前安装和配置状态的摘要：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
libmamba version : 2.5.0
micromamba version : 2.5.0

envs directories : /Users/newton/.local/share/micromamba/envs
package cache : /Users/newton/.local/share/micromamba/pkgs

environment : py314 (active)

env location :
/Users/newton/.local/share/micromamba/envs/py314

user config files :
/Users/newton/.mambarc

populated config files :
/Users/newton/.condarc

base environment :
/Users/newton/.local/share/micromamba

各字段含义：

  • envs directories：环境目录，micromamba env list 会扫描这个路径下的所有环境
  • package cache：包缓存位置，micromamba clean 可以清理这里的过期缓存
  • user config files：micromamba 的专属配置文件（.mambarc），语法与 .condarc 相同
  • populated config files：当前实际被加载的配置文件（.condarc），可以同时存在多个配置文件，micromamba 会按优先级合并它们
  • base environment：micromamba 的根目录，对应 --root-prefix 参数的值

注意 user config files 和 populated config files 的区别：前者是 micromamba 专属的配置，后者是实际被应用的配置（可能包含来自系统级或项目级的 .condarc）。

7.3 配置文件·

.mambarc 的典型配置：

1
2
3
4
channels:
  - conda-forge
channel_priority: strict
auto_activate_base: false

这个配置做了三件事：把 conda-forge 设为默认 channel，启用严格 channel 优先级，禁止自动激活 base。

8. uv / pipx / micromamba 的关系·

这三个工具经常同时出现在现代 Python 工作流的讨论中，但它们解决的是不同层次的问题，不是替代关系。

1
2
3
micromamba  → Python 解释器 + 环境管理（conda 生态）
uv          → Python 包安装 + 依赖管理（pip 生态）
pipx        → CLI 工具的独立安装

micromamba 负责管理 Python 解释器本身和隔离的 conda 环境。它的优势是能管理非 Python 的二进制依赖（CUDA、HDF5、OpenBLAS 等），这是 pip/uv 做不到的。

uv 是 Astral 开发的 pip 替代品，使用 Rust 编写，依赖解析速度比 pip 快 10~100 倍。uv 可以作为 pip 的直接替代在任何 Python 环境里使用：

1
2
3
# 在 micromamba 环境中使用 uv 代替 pip
micromamba activate dev
uv pip install requests httpx

uv 还提供了 uv venv 来创建轻量 venv, 适合不需要 conda 包的纯 Python 项目。

pipx 专门解决 CLI 工具的安装问题。像 black、ruff、mypy、httpie 这类工具，如果安装在项目环境里会污染依赖，安装在 base/全局环境里又难以管理版本。pipx 为每个 CLI 工具创建独立的 venv，工具的二进制暴露在 ~/.local/bin，版本管理和卸载都很干净：

1
2
3
pipx install black
pipx install ruff
pipx install httpie

这三者的组合方式是：用 micromamba 管理 Python 版本和环境，用 uv 在环境内快速安装 Python 包，用 pipx 管理全局 CLI 工具。

9. 一个现代 Python 环境管理的推荐方案·

经过实际使用后，我的 Python 环境架构大致是这样的：

1
2
3
4
5
micromamba
  ├── dev        # 日常开发，Python 3.12
  ├── firmware   # 嵌入式相关，带特定版本 arm-none-eabi-gcc
  ├── jupyter    # 数据分析，Jupyter + 常用科学计算包
  └── ml         # 机器学习，PyTorch + CUDA

每个环境都有明确的用途，互相隔离，创建时就指定好 Python 版本和核心依赖。

全局工具通过 pipx 管理，不进入任何 conda 环境：

1
2
3
4
5
pipx
  ├── black / ruff    # 格式化
  ├── httpie          # HTTP 客户端
  ├── yt-dlp          # 下载工具
  └── claude          # AI CLI

包管理策略：

  • conda 包（有非 Python 依赖的）：通过 micromamba 安装
  • 纯 Python 包：在 micromamba 环境中通过 uv pip install 安装
  • CLI 工具：通过 pipx 安装

这个方案的好处是责任边界清晰，不同工具管理不同层次的依赖，不会出现混用导致的依赖冲突。

.mambarc 的推荐配置：

1
2
3
4
channels:
  - conda-forge
channel_priority: strict
auto_activate_base: false

用 conda-forge 作为唯一 channel, strict 优先级，不自动激活 base. 这三行配置，加上 micromamba 本身，构成了一个相当干净的 Python 环境基础。

总结·

从 Miniconda 迁移到 micromamba 的核心收益是：

  • 磁盘占用大幅下降：去掉了臃肿的 base 环境，工具本身只有一个二进制
  • 环境管理更干净：没有 base 污染，每个环境都是显式创建的具名环境
  • 速度显著提升：libmamba solver 相比 conda 原生 solver 快了一个数量级
  • 目录结构清晰：遵循 XDG 规范，数据和配置有明确的位置

micromamba + conda-forge 是目前我认为最干净的 Python 环境管理方案之一。不依赖 Anaconda 公司的基础设施，包覆盖全，更新快，对 Apple Silicon 支持好。

迁移成本不高。核心步骤就是安装 micromamba、初始化 shell、配置 .mambarc 指向 conda-forge，然后按需重建环境。旧的 Miniconda 目录可以直接删掉，不会影响新的 micromamba 配置。