4. 虚拟环境创建与依赖管理

在科学计算项目里，最容易被忽视、却最容易在换机器时“翻车”的环节，就是依赖环境。你可能遇到过这样的场景：本地跑得好好的脚本，拷到同学电脑上就报 ModuleNotFoundError；或者昨天还能用的代码，今天因为随手 pip install 升级了某个包，结果 NumPy 和 SciPy 版本不匹配，程序直接崩溃。conda 的虚拟环境正是为了解决这类问题而存在的。

所谓环境隔离，本质上是为每个项目准备一套独立的 Python 解释器、包目录和依赖版本。不同环境之间互不干扰：项目 A 用 NumPy 1.24，项目 B 用 NumPy 2.0，它们可以同时存在于同一台机器上，只要分别激活对应环境即可。这就像给每个项目分配一个独立的工具箱，而不是所有项目共用一个抽屉、互相抢工具。理解这一点，后面的创建、导出、复现才有意义——环境不只是一个文件夹，而是一份可被记录、可被重建的依赖契约。

创建与激活：从零搭一个科学计算环境

conda 的环境操作围绕 conda env 和 conda activate 展开。假设我们要为“数据分析入门”项目建一个环境，指定 Python 3.11，并预装几个常用科学计算包：

# 创建名为 ds-intro 的环境，指定 Python 版本与核心包
conda create -n ds-intro python=3.11 numpy pandas matplotlib jupyter -y

# 查看当前所有环境（带 * 的是当前激活环境）
conda env list

# 激活环境
conda activate ds-intro

# 确认解释器与包版本
python --version
conda list

执行 conda create 时，conda 会解析这些包的依赖关系，计算出一组彼此兼容的版本组合，再下载安装。这一步的“求解”过程很关键：它不会简单地装最新版，而是尽量满足所有约束。安装完成后，conda env list 会显示环境所在路径，通常位于 conda 安装目录下的 envs/ds-intro。激活后，命令行提示符前会出现 (ds-intro)，此时 python、pip、jupyter 都指向该环境内的副本。

需要提醒的是：激活环境后再安装包。如果忘记激活就执行 pip install，包会装进 base 环境，造成“明明装了却找不到”的困惑。退出环境用 conda deactivate。删除环境则用 conda env remove -n ds-intro，删除前建议先 conda deactivate，避免在环境内删除自身引发异常。

environment.yml：把环境写成可复现的文件

环境真正的价值在于可复现。手工记下装了哪些包既繁琐又容易漏，conda 提供了导出机制：

# 导出当前环境为 yml 文件（--from-history 只记录显式安装的包）
conda env export --from-history > environment.yml

# 完整导出（含所有传递依赖及精确版本）
conda env export > environment-full.yml

两种导出方式各有用途。--from-history 只记录你主动安装的包（如 numpy、pandas），文件简洁、跨平台友好，但重建时可能装到更新的次版本；完整导出会锁定每个传递依赖的精确版本和 build 号，复现最严格，但换操作系统时可能因平台差异无法求解。科学计算项目通常推荐：开发阶段用完整导出保证一致，共享给他人时用 from-history 保证可移植，必要时再手动补充关键版本约束。

一个典型的 environment.yml 结构如下：

name: ds-intro
channels:
  - conda-forge
  - defaults
dependencies:
  - python=3.11
  - numpy=1.26
  - pandas>=2.0
  - matplotlib
  - jupyter
  - pip
  - pip:
      - some-pypi-only-package==1.2.0

几个编写要点：name 决定重建后的环境名；channels 的顺序影响包的来源优先级，conda-forge 通常更全更新；dependencies 下用 = 锁定精确版本、用 >= 表示最低要求；conda 仓库里没有的包，可以放在 pip: 子节点下由 pip 安装。重建环境只需一条命令：

conda env create -f environment.yml

如果同名环境已存在，可加 --force 覆盖，或先删除再重建。重建后建议执行 conda list 与原始环境对比，确认关键包版本一致。

环境隔离的意义与常见误区

把上面的流程串起来看，环境隔离解决的是版本冲突和可移植性两个问题。科学计算生态里，NumPy、SciPy、pandas、matplotlib 之间存在大量版本耦合，一个包升级可能连带要求其他包同步升级。如果所有项目共用 base 环境，任何一次安装都可能“牵一发而动全身”。而每个项目独立环境后，升级只影响当前项目，风险被限制在局部。

实践中还有几个高频误区值得注意。第一，base 环境尽量保持干净，只放 conda 自身和极少数工具，项目包一律进独立环境。第二，不要混用 conda 与 pip 随意安装同一个包，否则可能出现两份副本、版本记录混乱；确需 pip 安装时，优先在 yml 的 pip: 节点中声明，保证可复现。第三，导出文件要纳入版本控制，和代码一起提交，别人拿到仓库后一条命令即可重建。第四，环境名建议与项目对应，避免 test、env1 这类无法辨认的名字。

最后强调一个观念：environment.yml 不是“装完包顺手导出的备份”，而是项目的依赖契约。它应当和源码一样被认真维护——新增依赖后及时更新，锁定关键版本，写清渠道。做到这一点，你的科学计算项目才真正具备“换一台机器、换一个队友也能跑起来”的工程属性。