Python 虚拟环境入门：venv 与 uv，让每个项目各用各的包

很多人第一次被 Python 坑到，都是因为 pip install 装的东西"互相打架"：项目 A 要 requests 2.x，项目 B 要 requests 3.x，全装进系统 Python 里，迟早有一个项目跑不起来。虚拟环境解决的就是这件事——给每个项目一个独立的包目录，各用各的，互不干扰。

venv：Python 自带的三板斧

Python 3.3 之后自带 venv，不需要装任何东西。记住三个命令就够了。创建：在项目目录下执行 python -m venv .venv，会在当前目录生成一个 .venv 文件夹，那就是这个项目的"独立小世界"。激活：Linux/macOS 下执行 source .venv/bin/activate，终端提示符前面多出 (.venv) 就是成功了。退出：deactivate，一秒回到系统环境。

激活之后再 pip install，包装的全进 .venv 里。换个项目就换个 .venv，版本冲突从根上消失。注意 .venv 目录不要提交到 Git，.gitignore 里加一行 .venv/，别人拿到你的 requirements.txt 自己重建即可。

uv：更快的新选择

uv 是这两年流行起来的 Python 包管理工具，Rust 写的，安装和解析依赖都比 pip 快一个数量级。装完后常用三招：uv venv 创建环境，uv pip install <包名> 装包，uv pip freeze > requirements.txt 锁版本。它的命令刻意模仿 pip/venv 的心智模型，迁移成本很低。

更进一步可以用 uv init 建项目，它会生成 pyproject.toml，配合 uv add / uv sync 管理依赖和锁文件，相当于把虚拟环境和依赖声明统一在一个工具里。对新项目，我会直接走这条路；老项目继续用 venv 也完全没问题，不必为了追新而迁移。

三个最常见的坑

坑一：编辑器用的还是系统解释器。VS Code 里按 Ctrl+Shift+P 搜 "Python: Select Interpreter"，手动选到项目 .venv/bin/python，否则你在终端里装的包，编辑器里照样报红。

坑二：用 sudo pip install 救急。权限不够就加 sudo，装进了系统 Python，和系统自带的工具链打架，修起来比项目还麻烦。虚拟环境里永远不需要 sudo。

坑三：requirements.txt 长期不锁。只写 requests 不写版本号，半年后重建环境装到大版本升级的包，代码直接挂。发布前 freeze 一次，把版本号钉死。

一句话总结：一个项目一个虚拟环境，是写 Python 的基本卫生习惯。venv 零成本上手，uv 更快更现代，选哪个都行，关键是每个项目都用上。