写 Python 最容易遇到的一个问题,不是语法,而是环境:这个项目要 requests==2.31,那个项目要新版本;系统 Python 里装了一堆包,过几个月自己都不知道哪些还能删;换台机器运行,又开始缺依赖。
虚拟环境就是用来解决这类混乱的。它给每个项目准备一套独立的 Python 包目录,让项目之间互不干扰。你可以把它理解成项目自己的工具箱:这个项目要什么就放什么,不影响别的项目,也尽量不污染系统环境。
什么时候应该创建虚拟环境
只要是一个会长期保留、会安装第三方依赖、或者未来可能换机器运行的 Python 项目,都建议创建虚拟环境。
最典型的场景有三类:
- 写脚本时需要安装
requests、pandas、openpyxl之类的包。 - 开发 Web、爬虫、自动化、数据分析项目。
- 复现别人项目里的
requirements.txt或pyproject.toml。
不太需要虚拟环境的情况也有:只运行一段标准库脚本,例如 python hello.py,完全不装第三方包。除此之外,默认创建虚拟环境通常是更省心的选择。
推荐的目录习惯
一个清爽的项目目录大概长这样:
|
|
其中 .venv 就是虚拟环境目录。它一般放在项目根目录下,名字固定用 .venv,原因很简单:编辑器容易识别,人也容易识别。
如果项目使用 Git,记得把 .venv/ 放进 .gitignore。虚拟环境本身不应该提交到仓库,应该提交的是依赖清单,例如 requirements.txt。
|
|
创建虚拟环境
Python 自带 venv 模块,不需要额外安装工具。进入项目目录后执行:
|
|
如果你的系统里同时装了多个 Python 版本,Windows 上可以用 py 启动器指定版本:
|
|
macOS 或 Linux 上通常是:
|
|
创建完成后,项目里会出现一个 .venv 文件夹。这个文件夹里有一份独立的 Python 解释器入口,以及后续安装的第三方包。
激活虚拟环境
创建虚拟环境只是准备好了房间,激活才是走进去。
在 Windows PowerShell 里:
|
|
在 Windows CMD 里:
|
|
在 macOS 或 Linux 里:
|
|
激活成功后,终端前面通常会出现 (.venv)。这时你运行的 python、pip,都会优先指向当前项目的虚拟环境。
可以用下面的命令确认:
|
|
输出路径里如果包含当前项目的 .venv,就说明环境已经用对了。
安装和记录依赖
激活虚拟环境后,就可以正常安装依赖:
|
|
这里推荐使用 python -m pip,而不是直接敲 pip。这样可以明确告诉当前 Python 去运行它对应的 pip,减少装错环境的概率。
安装完依赖后,把当前环境里的包记录下来:
|
|
以后换机器、换目录、或者让别人运行这个项目时,只需要先创建并激活虚拟环境,再执行:
|
|
这就是最基础、也最通用的 Python 项目复现方式。
每天使用时的顺序
平时打开项目后,可以按这个顺序操作:
|
|
如果是第一次拿到项目,则多一步安装依赖:
|
|
项目写完或暂时不用时,可以退出虚拟环境:
|
|
退出后,终端前面的 (.venv) 会消失。
常见问题
PowerShell 提示不能运行脚本
如果激活时报类似错误:
|
|
这是 PowerShell 执行策略限制。可以只给当前用户放宽限制:
|
|
然后重新打开 PowerShell,再执行激活命令。
明明安装了包,运行还是提示找不到
这种情况大概率是装到了另一个 Python 环境里。先确认当前解释器:
|
|
再确认 pip 属于谁:
|
|
如果路径不在项目 .venv 下面,就先重新激活虚拟环境,再安装依赖。
可以删除虚拟环境重建吗
可以。.venv 只是本地生成物,不是项目源代码。环境乱了时,最干净的处理方式往往是删掉 .venv,然后按依赖清单重建:
|
|
只要 requirements.txt 维护得好,重建环境通常比在旧环境里反复修更稳定。
venv、conda、pipx 怎么选
日常 Python 项目开发,优先用 venv。它是 Python 标准库自带的工具,轻量、通用、不会引入太多额外概念。
如果你主要做数据科学,依赖里经常有复杂的二进制包、CUDA、科学计算库,可以考虑 conda 或 mamba。它们管理的不只是 Python 包,还包括一部分系统级依赖。
如果你只是想全局安装某个 Python 命令行工具,例如 black、ruff、httpie,可以用 pipx。它会给每个命令行工具单独建环境,避免把工具依赖混进项目里。
简单记法是:
- 项目开发:用
venv。 - 数据科学复杂环境:考虑
conda或mamba。 - 安装 Python 命令行工具:用
pipx。
一个够用的工作流
对大多数个人项目来说,不需要一上来就引入复杂的包管理方案。先把这套流程坚持下来,环境问题就会少很多:
|
|
然后提交代码时提交 requirements.txt,不要提交 .venv。
真正重要的不是记住每个命令,而是形成边界感:系统 Python 只负责提供基础解释器,项目依赖只进入项目自己的虚拟环境。这个边界清楚了,Python 项目就会从“这次怎么又跑不起来”变成“删掉重建也不慌”。