技术复盘：Python 项目虚拟环境，我用 .venv 还是 Conda？迁移实战总结

做技术久了会发现，很多坑不是业务逻辑带来的，而是环境本身。

这篇文章不是入门教程，而是一份我自己踩过坑之后的总结，核心回答两个问题：

虚拟环境到底该怎么选？
换机器了到底该怎么迁？

一、先说结论：我最终选择了 .venv + requirements.txt

这不是非此即彼的信仰问题，而是现实权衡后的结果。

方案	是否提交文件夹	跨平台表现	适用场景
Conda	不提交，导 `environment.yml`	一般，路径易出错	机器学习、C++ 依赖多的项目
.venv	不提交，导 `requirements.txt`	✅ 优秀	绝大多数 Web、后端、脚本项目

我现在的默认选择是：

项目自带 .venv（本地创建），用 requirements.txt 锁依赖，.venv 绝不进 Git。

二、关于”自带 .venv”的正确理解

很多人误以为”自带 .venv”就是把虚拟环境文件夹放进项目里一起提交。

这是错的。

正确的做法是：

项目里包含 .venv 文件夹（本地开发用）
但 .gitignore 里忽略它
真正”自带”的是 requirements.txt

也就是说：

代码带的是依赖清单，不是环境本身。

三、环境迁移的本质不是”复制”，而是”重建”

这个认识是我觉得最重要的一个总结。

我之前的错误认知

把本地的 .venv 打包，传到服务器解压直接用。

实际情况

路径硬编码（/Users/xxx/...）
不同系统二进制不兼容
激活脚本指向错误解释器

正确的迁移逻辑

在任何新机器上，都重新创建虚拟环境，再根据 requirements.txt 重建依赖。

这套流程是标准化的，也是跨平台最稳的方式。

四、我现在的标准迁移流程（速查版）

第一步：导出依赖（源机器）

1	pip freeze > requirements.txt

第二步：提交代码（仅提交 requirements.txt）

1
2
3

git add requirements.txt
git commit -m "update dependencies"
git push

第三步：新机器重建环境

git clone xxx
cd project
python -m venv .venv
source .venv/bin/activate   # Windows 用 .venv\Scripts\activate
pip install -r requirements.txt

整个过程 5 分钟以内，稳定、可重复、无意外。

五、一个容易被忽略的细节：系统级依赖

有些包不是 pip 能搞定的，比如：

psycopg2（PostgreSQL 驱动）
mysqlclient
涉及 CUDA 的 PyTorch

这类问题 .venv 解决不了，需要在系统层面提前装好依赖库。

我的做法是：

在 README.md 里写明系统依赖
用 Docker 统一基础镜像
复杂项目单独写 setup.sh

六、我现在推荐的项目环境结构

my-project/
├── .venv/                # 虚拟环境（本地，不进 Git）
├── .gitignore            # 必须包含 .venv/
├── requirements.txt      # 生产依赖
├── requirements-dev.txt  # 开发依赖（可选）
├── README.md             # 写明环境搭建步骤
└── src/

这样的结构，任何人拿到项目都能在 3 分钟内跑起来。