Python 虚拟环境使用指南：把项目依赖关进自己的小房间

Wed, 27 May 2026 23:58:18 +0800

写 Python 最容易遇到的一个问题，不是语法，而是环境：这个项目要 requests==2.31，那个项目要新版本；系统 Python 里装了一堆包，过几个月自己都不知道哪些还能删；换台机器运行，又开始缺依赖。

虚拟环境就是用来解决这类混乱的。它给每个项目准备一套独立的 Python 包目录，让项目之间互不干扰。你可以把它理解成项目自己的工具箱：这个项目要什么就放什么，不影响别的项目，也尽量不污染系统环境。

什么时候应该创建虚拟环境

只要是一个会长期保留、会安装第三方依赖、或者未来可能换机器运行的 Python 项目，都建议创建虚拟环境。

最典型的场景有三类：

写脚本时需要安装 requests、pandas、openpyxl 之类的包。
开发 Web、爬虫、自动化、数据分析项目。
复现别人项目里的 requirements.txt 或 pyproject.toml。

不太需要虚拟环境的情况也有：只运行一段标准库脚本，例如 python hello.py，完全不装第三方包。除此之外，默认创建虚拟环境通常是更省心的选择。

创建虚拟环境

Python 自带 venv 模块，不需要额外安装工具。进入项目目录后执行：

`1`	`python -m venv .venv`

如果你的系统里同时装了多个 Python 版本，Windows 上可以用 py 启动器指定版本：

`1`	`py -3.12 -m venv .venv`

macOS 或 Linux 上通常是：

`1`	`python3 -m venv .venv`

创建完成后，项目里会出现一个 .venv 文件夹。这个文件夹里有一份独立的 Python 解释器入口，以及后续安装的第三方包。

激活虚拟环境

创建虚拟环境只是准备好了房间，激活才是走进去。

在 Windows PowerShell 里：

`1`	`.\.venv\Scripts\Activate.ps1`

在 Windows CMD 里：

`1`	`.venv\Scripts\activate.bat`

在 macOS 或 Linux 里：

`1`	`source .venv/bin/activate`

激活成功后，终端前面通常会出现 (.venv)。这时你运行的 python、pip，都会优先指向当前项目的虚拟环境。

可以用下面的命令确认：

`1`	`python -c "import sys; print(sys.executable)"`

输出路径里如果包含当前项目的 .venv，就说明环境已经用对了。

安装和记录依赖

激活虚拟环境后，就可以正常安装依赖：

`1`	`python -m pip install requests`

这里推荐使用 python -m pip，而不是直接敲 pip。这样可以明确告诉当前 Python 去运行它对应的 pip，减少装错环境的概率。

安装完依赖后，把当前环境里的包记录下来：

`1`	`python -m pip freeze > requirements.txt`

以后换机器、换目录、或者让别人运行这个项目时，只需要先创建并激活虚拟环境，再执行：

`1`	`python -m pip install -r requirements.txt`

这就是最基础、也最通用的 Python 项目复现方式。

每天使用时的顺序

平时打开项目后，可以按这个顺序操作：

1
2
3

cd path\to\my-python-project
.\.venv\Scripts\Activate.ps1
python main.py

如果是第一次拿到项目，则多一步安装依赖：

python -m venv .venv
.\.venv\Scripts\Activate.ps1
python -m pip install -r requirements.txt
python main.py

项目写完或暂时不用时，可以退出虚拟环境：

`1`	`deactivate`

退出后，终端前面的 (.venv) 会消失。

常见问题

PowerShell 提示不能运行脚本

如果激活时报类似错误：

`1`	`running scripts is disabled on this system`

这是 PowerShell 执行策略限制。可以只给当前用户放宽限制：

`1`	`Set-ExecutionPolicy -Scope CurrentUser RemoteSigned`

然后重新打开 PowerShell，再执行激活命令。

明明安装了包，运行还是提示找不到

这种情况大概率是装到了另一个 Python 环境里。先确认当前解释器：

`1`	`python -c "import sys; print(sys.executable)"`

再确认 pip 属于谁：

`1`	`python -m pip --version`

如果路径不在项目 .venv 下面，就先重新激活虚拟环境，再安装依赖。

可以删除虚拟环境重建吗

可以。.venv 只是本地生成物，不是项目源代码。环境乱了时，最干净的处理方式往往是删掉 .venv，然后按依赖清单重建：

1
2
3

python -m venv .venv
.\.venv\Scripts\Activate.ps1
python -m pip install -r requirements.txt

只要 requirements.txt 维护得好，重建环境通常比在旧环境里反复修更稳定。

venv、conda、pipx 怎么选

日常 Python 项目开发，优先用 venv。它是 Python 标准库自带的工具，轻量、通用、不会引入太多额外概念。

如果你主要做数据科学，依赖里经常有复杂的二进制包、CUDA、科学计算库，可以考虑 conda 或 mamba。它们管理的不只是 Python 包，还包括一部分系统级依赖。

如果你只是想全局安装某个 Python 命令行工具，例如 black、ruff、httpie，可以用 pipx。它会给每个命令行工具单独建环境，避免把工具依赖混进项目里。

简单记法是：

项目开发：用 venv。
数据科学复杂环境：考虑 conda 或 mamba。
安装 Python 命令行工具：用 pipx。

一个够用的工作流

对大多数个人项目来说，不需要一上来就引入复杂的包管理方案。先把这套流程坚持下来，环境问题就会少很多：

python -m venv .venv
.\.venv\Scripts\Activate.ps1
python -m pip install -U pip
python -m pip install 需要的包
python -m pip freeze > requirements.txt

然后提交代码时提交 requirements.txt，不要提交 .venv。

真正重要的不是记住每个命令，而是形成边界感：系统 Python 只负责提供基础解释器，项目依赖只进入项目自己的虚拟环境。这个边界清楚了，Python 项目就会从“这次怎么又跑不起来”变成“删掉重建也不慌”。

Pip on Saki的小站