Featured image of post Python 虚拟环境使用指南:把项目依赖关进自己的小房间

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

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

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

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

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

最典型的场景有三类:

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

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

推荐的目录习惯

一个清爽的项目目录大概长这样:

1
2
3
4
5
my-python-project/
├── .venv/
├── main.py
├── requirements.txt
└── README.md

其中 .venv 就是虚拟环境目录。它一般放在项目根目录下,名字固定用 .venv,原因很简单:编辑器容易识别,人也容易识别。

如果项目使用 Git,记得把 .venv/ 放进 .gitignore。虚拟环境本身不应该提交到仓库,应该提交的是依赖清单,例如 requirements.txt

1
2
3
.venv/
__pycache__/
*.pyc

创建虚拟环境

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)。这时你运行的 pythonpip,都会优先指向当前项目的虚拟环境。

可以用下面的命令确认:

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

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

1
2
3
4
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、科学计算库,可以考虑 condamamba。它们管理的不只是 Python 包,还包括一部分系统级依赖。

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

简单记法是:

  • 项目开发:用 venv
  • 数据科学复杂环境:考虑 condamamba
  • 安装 Python 命令行工具:用 pipx

一个够用的工作流

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

1
2
3
4
5
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 项目就会从“这次怎么又跑不起来”变成“删掉重建也不慌”。

使用 Hugo 构建
主题 StackJimmy 设计