第一次用 Python venv 隔离项目环境：踩过的三个坑与正确姿势

在云服务器上同时跑两个 Python 项目时，我第一次真正理解了环境隔离的重要性。一个是定时拉取数据的脚本，只认 requests 2.28；另一个是新写的接口服务，需要 requests 2.32 的新特性。最开始我图省事，把两个项目都装在系统 Python 里，结果升级一个项目的依赖，另一个项目当场报错。那次之后，我才认真用起了 Python 自带的 venv。

第一个坑：不隔离，全局安装迟早互相拖垮。系统 Python 只有一份 site-packages，A 项目要旧版，B 项目要新版，pip install --upgrade 一次，只能保住一个。正确做法是每个项目一个虚拟环境：进入项目目录后执行 python3 -m venv .venv，再用 source .venv/bin/activate 激活。激活后命令行前面会出现 (.venv) 提示，这时 pip install 装的包只进这个环境，与系统和其他项目互不干扰。退出用 deactivate。

第二个坑：以为激活一次就一劳永逸。venv 的激活只对当前终端会话有效，换一个终端、重连一次 SSH，提示符里的 (.venv) 就没了，pip 和 python 又回到了系统环境。我有一次就是在新终端里直接 pip install，结果包又装进了系统里，排查了半天才发现 python 的路径不对。养成习惯：每次进项目先看一眼 which python，确认路径是项目下的 .venv/bin/python 再操作；写定时任务、systemd 服务或后台脚本时，不要依赖激活状态，直接写绝对路径，例如 /home/user/myapp/.venv/bin/python /home/user/myapp/main.py，这样不管谁来执行，用的都是对的环境。

第三个坑：把 .venv 一起提交或备份。虚拟环境里有成百上千个小文件，提交到 Git 既臃肿又不可移植，换一台机器、换一个 Python 小版本就可能出问题。正确的做法是只提交代码和依赖清单：项目根目录建一个 .gitignore，写上 .venv/；每次装好依赖就执行 pip freeze > requirements.txt；到了新机器，先 python3 -m venv .venv，激活后再 pip install -r requirements.txt，就能原样复现。顺手把 pip 升级一下，下载慢时可以换国内镜像源，例如加上 -i https://pypi.tuna.tsinghua.edu.cn/simple。

还有两点小经验：一是创建虚拟环境时确认 python3 的版本，python3 --version 先看一眼，避免用错系统自带的旧版本；二是不要在虚拟环境里再用 sudo pip install，sudo 会绕过虚拟环境，把包装到系统里，前面隔离的功夫全白费。venv、virtualenv 和 conda 都能做隔离，对大多数个人项目和云服务器上的小服务来说，Python 自带的 venv 已经够用，不用再多装一套工具。

回头看，venv 本身并不复杂，难的是改掉图省事的习惯：一个项目一个环境、每次确认当前环境、只提交 requirements.txt 而不是整个 .venv。按这三条做下来，之后再多接几个 Python 项目，也不用担心依赖互相打架了。