Python venv 入门：给每个项目一个干净的家

Python venv 入门：给每个项目一个干净的家

如果你经历过这样的场景：项目 A 依赖 requests 2.x，项目 B 只兼容 requests 1.x，装了新版本旧项目崩掉，退回旧版本新项目报错——那么你正需要虚拟环境。Python 从 3.3 起内置了 venv 模块，无需安装任何第三方工具，就能为每个项目隔离出一套独立的运行环境。

一、虚拟环境解决什么问题

Python 的包默认装进解释器所在的全局 site-packages 目录，所有项目共享。这在只有一个项目时没什么问题，但项目一多，依赖冲突几乎不可避免。虚拟环境的思路很简单：在项目目录下复制一份轻量的解释器环境，之后所有的 pip 安装都只落进这个目录，互不干扰。删除环境也不过是删掉一个文件夹，干净利落。

二、基础操作三步走

创建环境：

python3 -m venv .venv

这条命令会在当前目录生成 .venv 文件夹，包含独立的解释器副本和空的 site-packages。目录名随意，但 .venv 已是社区惯例，多数 IDE 和工具链会默认识别它。

激活环境：

source .venv/bin/activate

激活后命令行提示符会加上 (.venv) 前缀，此时 which python 指向虚拟环境内部的解释器。Windows 下对应 .venv\Scripts\activate.bat。激活只是修改了 PATH 环境变量，不激活直接用 .venv/bin/python 调用也完全可以。

安装依赖：

pip install requests
pip freeze > requirements.txt

requirements.txt 是环境的"快照"，换机器或协作开发时，一条 pip install -r requirements.txt 即可复原全部依赖。

三、几个容易踩的坑

第一，激活不是必须的。脚本里写死 .venv/bin/python 的绝对路径或相对路径，同样能使用虚拟环境，CI 流水线里通常就是这么干的。第二，Python 版本与环境绑定：venv 不负责安装 Python 本身，环境创建后不会自动跟随系统 Python 升级，需要新版本时应重建环境。第三，别忘了 .gitignore 里加上 .venv/，环境本身不该进版本库，进库的只有 requirements.txt。第四，pip 建议先升级到环境内最新版：python -m pip install --upgrade pip，老版本 pip 在解析依赖时偶尔会装出冲突的组合。

四、进阶一点的选择

当项目多到需要频繁切换 Python 版本时，可以引入 pyenv 管理多个解释器版本，配合 venv 使用；如果希望环境目录与项目分离、并缓存已下载的包以节省磁盘，poetry 和 uv 这类工具提供了更自动化的依赖解析与锁定能力。但对大多数中小项目而言，标准库自带的 venv 加 pip 加 requirements.txt，已经足够可靠。

总结

虚拟环境是 Python 工程化的第一课：一个项目一个环境，依赖冲突从根源上消失。记住三个动作——python -m venv .venv 创建、source 激活、freeze 导出依赖清单，就足以应对日常开发的绝大多数场景。

（本文为作者原创技术笔记，欢迎交流指正。）