Python venv 虚拟环境入门

Python venv 虚拟环境入门

在 Python 开发中，不同项目往往依赖不同版本的第三方包，甚至不同的小版本 Python。如果把所有包都装在全局环境里，很快就会出现版本冲突、互相牵制的局面。Python 标准库内置的 venv 模块，就是为了解决这个问题而存在的：它能为每个项目创建一个干净的、彼此隔离的虚拟环境。

什么是虚拟环境

虚拟环境本质上是文件系统上的一个普通目录。创建时，venv 会把当前 Python 解释器的一个副本（或符号链接）放进去，同时准备好 site-packages 目录用来安装项目专属的包。激活虚拟环境后，命令行里的 python 和 pip 都会指向这个副本，安装的包也只会落到当前项目的目录里，不会影响系统或其他项目。

创建虚拟环境

Python 3.3 起 venv 已随解释器自带，无需额外安装。在项目根目录执行：

python -m venv .venv

这里 .venv 是约定俗成的目录名，也可以叫 venv、env 或任意你喜欢的名字。创建完成后，目录下会出现 bin（Windows 下是 Scripts）、lib、include 等结构，以及一个 pyvenv.cfg 配置文件，里面记录了虚拟环境的来源解释器路径。

激活与退出

Linux / macOS：

source .venv/bin/activate

Windows CMD：

.venv\Scripts\activate.bat

Windows PowerShell：

.venv\Scripts\Activate.ps1

激活后命令行提示符通常会显示虚拟环境名称，例如 (.venv) $，说明 python 和 pip 已切换到项目环境。退出只需执行 deactivate，无论在哪种 shell 下都通用。

安装与管理依赖

激活环境后，用 pip 安装项目所需的包：

pip install requests
pip install flask==3.0.0

建议把依赖写入 requirements.txt，方便他人复现：

pip freeze > requirements.txt

拉取项目后，其他人只需创建环境并执行：

pip install -r requirements.txt

即可安装完全一致的版本。

该把 .venv 提交到版本库吗

通常不建议。虚拟环境目录包含大量二进制文件，体积大且与平台强绑定，提交到 Git 只会制造无意义的差异。正确做法是把 .venv 写入 .gitignore，而把 requirements.txt（或 pyproject.toml）提交。这样团队成员各自 python -m venv 即可得到干净的环境。

与 IDE 配合

主流编辑器都能识别激活的虚拟环境。以 VS Code 为例，激活环境后打开项目，编辑器一般会自动将 Python 解释器指向 .venv/bin/python；如果没有，可在命令面板执行 “Python: Select Interpreter” 并选择该项目下的解释器。PyCharm 则在创建项目时提供 “New environment using Virtualenv / venv” 的选项，指向同一目录即可。

常见注意事项

• 尽量用 python -m venv 而不是直接调用某个第三方 venv 脚本，这样可以确保使用的是当前 python 命令对应的解释器。
• 全局 pip install 仍会把包装到系统环境，务必确认已在虚拟环境中执行。
• 如果只需要可执行脚本而不要整个 site-packages，可以用 python -m venv --without-pip .venv，再手动拷贝需要的解释器组件，这在打包发布时偶尔有用。
• 多个 Python 版本共存时，用 python3.11 -m venv .venv 显式指定版本。

小结

venv 是 Python 官方提供的轻量级环境隔离工具，零外部依赖、跨平台、与 pip 和主流 IDE 无缝配合。养成 “一个项目一个环境、依赖写进文件、环境目录不进版本库” 的习惯，就能大幅降低依赖冲突和 “在我机器上能跑” 的困扰。