使用requirements.txt配合Miniconda管理Python依赖
在人工智能和数据科学项目中，你是否曾遇到这样的场景：本地训练好的模型在同事的机器上跑不起来？或者几个月后自己重新运行实验时，因为库版本不一致导致结果无法复现？这类问题背后，往往是依赖管理不当惹的祸。
Python生态虽然繁荣，但“依赖地狱”始终是开发者绕不开的痛点。一个典型的例子是，PyTorch 1.12要求CUDA 11.6，而某些旧版OpenCV又只兼容CUDA 11.3——这种底层依赖冲突如果靠手动解决，轻则浪费数小时，重则直接阻塞项目进度。更别提当团队协作时，每个人环境略有差异，最终可能导致“在我机器上能跑”的经典尴尬局面。
这时候，我们需要一套既能隔离环境又能精确锁定依赖的解决方案。Miniconda +requirements.txt的组合正是为此而生。它不像Anaconda那样臃肿，也不像纯virtualenv那样对非Python依赖束手无策，而是走了一条“精准控制+灵活扩展”的中间路线。
Miniconda作为Conda的轻量发行版，核心优势在于其真正的系统级环境隔离能力。当你执行conda create -n myproject python=3.10时，它会在~/miniconda3/envs/myproject下创建一个完全独立的空间。这个环境不仅拥有自己的Python解释器，连pip、setuptools等工具都是专属副本。更重要的是，Conda能管理Python之外的二进制依赖——比如你在安装带有原生扩展的包（如NumPy）时，Conda会自动处理BLAS、LAPACK等底层数学库的链接问题，而这在传统virtualenv中往往需要用户自行编译或配置。
但Conda并非万能。尽管conda-forge社区已非常庞大，仍有大量新兴库仅发布在PyPI上。这时就需要requirements.txt登场了。这个看似简单的文本文件，其实是整个Python生态中最通用的依赖契约格式。它的妙处在于极简主义设计：每行一条记录，支持丰富的版本约束语法。例如：
torch==1.13.1+cu117 pandas>=1.5.0,<2.0.0 scikit-learn~=1.2.0 # 等价于 >=1.2.0, <1.3.0 jupyter这里有个工程实践中的关键细节：直接用pip freeze > requirements.txt虽然方便，但会把环境中所有间接依赖（transitive dependencies）都固化下来，导致文件臃肿且难以维护。更好的做法是使用pip-tools。先编写高层次的requirements.in：
numpy>=1.21.0 pandas>=1.3.0 torch==1.13.1+cu117 scikit-learn>=1.2.0 jupyter然后通过pip-compile requirements.in自动生成带精确版本号的requirements.txt。这种方式让你只需关注直接依赖，而复杂的依赖图谱由工具自动求解并锁定，兼顾了可读性与可复现性。
实际工作中，我见过太多团队踩过“混合安装”的坑。有人习惯在Conda环境中混用pip安装所有包，这看似无害，实则埋下隐患——Conda无法追踪pip安装的包，可能导致依赖冲突时求解失败。正确的姿势应该是“Conda优先，pip补充”：先用Conda安装核心科学计算栈（尤其是涉及CUDA、MKL优化的包），再用pip处理其余依赖。例如：
# 推荐方式：利用Conda渠道的优势 conda install numpy scipy matplotlib jupyter conda install pytorch torchvision torchaudio pytorch-cuda=11.8 -c pytorch -c nvidia # 补充安装Conda没有的包 pip install -r requirements.txt这样既享受了Conda预编译包带来的安装速度提升，又能覆盖PyPI上的长尾库。
在一个典型的AI开发流程中，这套组合拳的价值尤为突出。假设你要搭建一个图像分类项目，基本工作流如下：
初始化环境
bash conda create -n imgcls python=3.10 conda activate imgcls安装基础工具链
先装Jupyter和pip，这两个通常是后续操作的前提：bash conda install pip jupyter notebook加载项目依赖
如果已有requirements.txt，直接安装：bash pip install -r requirements.txt
对于PyTorch这类关键框架，建议仍用Conda安装GPU版本，因为它会自动拉取匹配的cuDNN和CUDA runtime，避免手动配置驱动版本的麻烦。集成到开发界面
很多团队使用Jupyter进行交互式开发。为了让Notebook识别新环境，需要注册内核：bash python -m ipykernel install --user --name=imgcls --display-name "Image Classification"
刷新页面后就能在Jupyter的kernel列表里看到这个选项了。
这套流程最大的好处是什么？是可重复性。当你把代码仓库推送到Git时，附带的requirements.txt就像一份精确的配方清单。新成员克隆项目后，只需几条命令就能获得和你完全一致的环境。在CI/CD流水线中也是如此，自动化测试不再因环境差异而随机失败。
我还想特别强调一个容易被忽视的点：base环境的纯洁性。很多用户习惯在base环境下安装各种常用包，久而久之这个环境变得臃肿且状态不明。正确的做法是保持base尽可能干净，只保留conda、pip等管理工具本身。所有项目相关依赖都在独立环境中安装。这样即使某个项目环境损坏，也不会影响其他工作。
为了进一步提升效率，可以配置Conda镜像源。国内用户常遇到下载慢的问题，修改.condarc文件即可加速：
channels: - defaults - conda-forge show_channel_urls: true channel_alias: https://mirrors.tuna.tsinghua.edu.cn/anaconda这会让Conda优先从清华镜像站拉取包，速度提升显著。
最后分享一个真实案例。某研究团队曾因未规范依赖管理，导致论文附录中的实验代码一年后无法复现——原来他们当时用了某个库的夜间构建版本（nightly build），而该版本后来被移除。改用requirements.txt锁定正式发布版本后，这个问题彻底解决。评审专家甚至专门称赞了他们出色的可复现性设计。
归根结底，技术选型的本质是在灵活性、稳定性和效率之间找平衡。Miniconda提供了强大的环境底盘，requirements.txt则充当了精确的依赖说明书。二者结合，既避免了Anaconda的笨重，又弥补了virtualenv在科学计算支持上的短板。特别是在云开发环境盛行的今天，基于Miniconda的镜像能让开发者“开箱即用”，把宝贵时间花在真正重要的事情上——写代码，而不是配环境。
