Python 虚拟环境 venv：从入门到实践，一篇讲透

做 Python 开发时，你一定遇到过这种尴尬：项目 A 要用 requests 2.x，项目 B 却依赖 requests 1.x；或者跟着教程 pip install了一堆包，几个月后自己都说不清系统里装了什么。这时候，Python 自带的虚拟环境工具 venv 就是标准答案。

一、为什么需要虚拟环境

Python 的包默认装在全局的 site-packages 里。所有项目共用一套依赖，版本稍有冲突就会互相“打架”。虚拟环境给每个项目创建一个独立的“小房间”：解释器、pip、第三方包都隔离存放，互不干扰。删项目时连同环境目录一起删掉，干干净净，不留垃圾。

二、venv 是什么

venv 是 Python 3.3 起内置的标准库模块，不用额外安装。它的原理很简单：复制一份当前解释器的“壳”，配上独立的包目录，并通过激活脚本临时修改 PATH，让 python 和 pip 指向环境内的版本。

三、四步上手

1. 创建环境

python -m venv .venv

习惯上把环境目录命名为 .venv 并放在项目根目录下。创建后你会看到 bin/（或 Windows 下的 Scripts/）、lib/ 等子目录。

2. 激活环境

Linux / macOS：

source .venv/bin/activate

Windows（PowerShell）：

.venv\Scripts\Activate.ps1

激活成功后，终端提示符前会多出 (.venv) 前缀，这就是“已进入小房间”的标志。

3. 安装依赖

pip install requests
pip freeze > requirements.txt

pip freeze 把当前环境的精确版本清单导出到 requirements.txt，别人拿到项目后一条命令就能复刻环境：

pip install -r requirements.txt

4. 退出与删除

deactivate

退出后环境依然存在，下次 source 激活即可继续用。不想要了直接删除 .venv 目录，没有任何残留。

四、三个最佳实践

第一，每个项目一个环境，不要图省事共用。第二，把 .venv/ 写进 .gitignore，环境目录不提交到版本库，只提交 requirements.txt。第三，用 python -m pip 代替裸 pip，可以避免“装到了别的解释器里”这类玄学问题。

五、常见坑

• PowerShell 报“禁止运行脚本”：这是执行策略限制，以管理员身份运行 Set-ExecutionPolicy RemoteSigned 即可。
• VS Code 里提示符有 (.venv) 但运行用的还是全局解释器：按 Ctrl+Shift+P 选择解释器，手动指向 .venv/bin/python。
• 升级 pip 别忘了：新环境自带的 pip 往往很旧，先 python -m pip install --upgrade pip 再装包更顺畅。

虚拟环境是 Python 工程化的第一课，成本极低、收益极高。从今天起，给每个新项目都建一个 .venv，你会感谢这个习惯。