Python 虚拟环境管理：venv 还是 conda？

上周帮同事配环境，他问我："新项目用 venv 还是 conda？" 我发现这个问题我被问过不下十次，干脆写篇博客，以后直接甩链接。

一句话结论

• 纯 Python 项目（Web、脚本、工具）→ venv，轻量、标准库自带
• 数据科学 / 需要非 Python 依赖（numpy、cuda、gdal 这种）→ conda，二进制包省心
• 不确定 → 先 venv，不够用了再换，不丢人

venv：标准库亲儿子

python3 -m venv .venv
source .venv/bin/activate
pip install -r requirements.txt

优点：零安装（Python 3.3+ 自带）、速度快、目录小。缺点：只隔离 Python 包，系统级的依赖（比如 libgdal）还得 apt 装，版本对不上就编译报错，新手劝退。

我的习惯：每个项目根目录一个 .venv，.gitignore 里忽略掉。进目录就 source .venv/bin/activate，肌肉记忆了。

conda：开箱即用的重装甲

conda create -n myproject python=3.11
conda activate myproject
conda install numpy pandas

优点：连 Python 解释器本身都能多版本共存，二进制包不用编译，数据科学全家桶一键装。缺点：臃肿（base 环境就几个 GB）、慢、和系统 pip 混用容易打架。

血泪教训：别在 conda 环境里 pip install，除非你清楚自己在干什么。conda 和 pip 的依赖解析各管各的，混用三个月后环境必坏。非要混用，pip 装完立刻 conda env export 备份。

几个坑

• venv 套娃：在已经激活的 venv 里又 python -m venv，路径会乱。先 deactivate 再建新的
• conda 初始化污染 shell：conda init 会改 ~/.bashrc，每开终端自动进 base。我一般 conda config --set auto_activate_base false 关掉
• requirements.txt vs environment.yml：venv 项目用前者（pip freeze > requirements.txt），conda 项目用后者（conda env export > environment.yml），别混
• 生产部署：Docker 里直接系统 Python + venv，镜像小；conda 镜像动不动 2GB+，能不用就不用

2026 年的新选择

顺带提一句，uv 最近很火（Rust 写的 pip 替代品），速度快一个数量级，uv venv && uv pip install 一套带走。我已经在几个新项目里用了，体验不错，但生态还在追，生产环境先观望。

总结：工具没有银弹，看项目类型选。我的默认顺序是 venv → 不够用 → conda → 尝鲜 uv。