用 Python venv 为工具建立独立运行环境：从创建到检查的基础操作

如果你打算在电脑上运行一个小工具或脚本，又不想让它安装的包影响系统里其他 Python 程序，那么 venv 就是为这个场景准备的。

venv 模块用于创建轻量级虚拟环境，每个环境有自己独立的一套 Python 包，安装在它自己的 site 目录里。虚拟环境建立在已有的 Python 安装之上，这个已有的安装称为基础 Python。默认情况下，虚拟环境与基础环境里的包是隔离的，只有显式装进虚拟环境的包才可用。

适用情境（自建示例）：假设你在练习目录下准备运行一个自建的小工具，希望它的依赖和系统 Python 分开。本文只讲创建、激活、确认解释器来源和重建这几件基础操作，不涉及依赖锁定、打包发布或高级参数组合。

需要提前说明：venv 不支持 Android、iOS 和 WASI，也就是移动平台和 WebAssembly 平台。如果你在这些平台上操作，venv 不适用。

创建虚拟环境用下面这条命令，把路径换成你自己的练习目录：

python -m venv exercise/.venv

在 Windows 上可以写成：

python -m venv exercise\.venv

这条命令会做几件事：

1. 创建目标目录，需要的话连父目录一起创建。

2. 在目录里放一个 pyvenv.cfg 文件，其中的 home 键指向运行这条命令时所用的 Python 安装位置。

3. 创建一个 bin 子目录（Windows 上是 Scripts），里面放 Python 可执行文件的副本或符号链接，具体取决于平台或创建时使用的参数。

4. 创建一个 lib/pythonX.Y/site-packages 子目录（Windows 上是 Lib\site-packages）。

如果指定的目录已经存在，它会被复用。

关于命名，官方文档给出的惯例是在项目目录里叫 .venv 或 venv，或者集中放在一个容器目录下，例如 ~/.virtualenvs。你可以按自己的习惯选，只要后续命令里的路径一致。

自建示例：在练习目录下执行 python -m venv exercise/.venv，之后检查 exercise/.venv 目录里是否有 pyvenv.cfg 和 bin（或 Scripts）子目录。这是编辑设计的检查步骤，不是对某台机器的实测记录。

环境创建好之后，可以激活它。激活脚本放在环境的二进制目录里，POSIX 系统是 bin，Windows 是 Scripts。激活会把该目录加到 PATH 前面，这样运行 python 就会调用环境里的解释器，运行已安装的脚本也不必写完整路径。

各平台和 shell 的激活命令如下（把 exercise/.venv 替换成你的环境目录路径）：

POSIX bash/zsh:  source exercise/.venv/bin/activate
POSIX fish:      source exercise/.venv/bin/activate.fish
POSIX csh/tcsh:  source exercise/.venv/bin/activate.csh
POSIX pwsh:      exercise/.venv/bin/Activate.ps1
Windows cmd.exe: exercise\.venv\Scripts\activate.bat
Windows PowerShell: exercise\.venv\Scripts\Activate.ps1

在 Windows 上，可能需要先为当前用户设置执行策略才能运行 Activate.ps1：

Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser

激活不是必须的。你也可以直接写环境里 Python 解释器的完整路径来调用它，环境里安装的脚本同样可以不激活就运行。

退出环境在 shell 里输入 deactivate。具体机制因平台而异，属于内部实现细节。

激活之后，怎么确认自己确实在用虚拟环境里的解释器，而不是系统那个？

当 Python 解释器从虚拟环境运行时，sys.prefix 和 sys.exec_prefix 指向虚拟环境的目录，而 sys.base_prefix 和 sys.base_exec_prefix 指向创建该环境时所用的基础 Python 的目录。因此，检查 sys.prefix != sys.base_prefix 就足以判断当前解释器是否来自虚拟环境。

自建示例：在激活后的环境里运行下面几行，观察两个值是否不同。

import sys
print(sys.prefix)
print(sys.base_prefix)
print(sys.prefix != sys.base_prefix)

需要提醒的是，激活环境时会把 VIRTUAL_ENV 环境变量设为该环境的路径。但既然不激活也能使用环境，这个变量就不能用来判断当前是否正在使用虚拟环境。判断依据还是上面的 sys.prefix 与 sys.base_prefix 比较。

虚拟环境目录有几条使用上的限制，初学者容易踩到。

1. 不要提交到版本控制。官方文档明确说虚拟环境不应签入 Git 这类源码控制系统。从 Python 3.13 起，venv 默认会为 Git 创建一个 .gitignore 文件，让整个环境目录被忽略。

2. 不要放项目代码。环境目录只用来装解释器和依赖，项目代码放在环境目录之外。

3. 不要移动或复制。环境里安装的脚本，其 shebang 行写的是环境解释器的绝对路径，所以环境在一般情况下本身不可移植。如果你因为移动了父目录而移动了环境，应当在新的位置重新创建环境，并删掉旧位置的那个。否则装进环境里的软件可能无法按预期工作。

4. 把它当作可丢弃的。环境应当能简单地删除并从头重建。

重建的做法：如果你有 requirements.txt，可以用环境里的 pip 执行 pip install -r requirements.txt 来装回所需的包。

下面几条是编辑整理的排查方向，不是对某个具体报错的诊断记录。

1. 命令找不到 python。先确认基础 Python 已安装，并且能在当前 shell 里直接调用。

2. 目标目录已存在且里面有内容。venv 会复用已存在的目录。如果你希望清空后重建，可以了解 --clear 选项的作用：它在创建环境前删除环境目录的内容。使用前请确认该目录确实是你准备重建的环境目录，不要指向存放其他文件的目录。

3. 激活脚本无法执行（Windows PowerShell）。参考上一节提到的执行策略设置。

4. 环境移动后脚本失效。按上一节的做法，在新位置重建，删除旧环境。

5. 想确认 pip 是否可用。默认情况下 venv 会通过 ensurepip 把 pip 装进虚拟环境；如果创建时用了 --without-pip，则不会安装。

以上选项只作说明，不要求你在练习中逐个尝试。

适用范围：本文只介绍 venv 的基础创建、激活、解释器来源确认和环境目录处理，以及少量相关选项的说明。不涉及依赖版本锁定、打包发布、CI 配置或第三方环境管理工具的比较。

平台限制：venv 不支持 Android、iOS 和 WASI。

版本相关：venv 在 Python 3.3 加入；从 3.5 起官方推荐用它创建虚拟环境；pyvenv 在 3.6 弃用、3.8 移除；3.12 起 setuptools 不再是 venv 的核心依赖；3.13 起新增 --without-scm-ignore-files 选项，并默认创建 .gitignore 文件。

操作提醒：本文所有示例都针对自建练习目录，不针对你的真实项目目录。执行任何会删除目录内容的选项之前，先确认路径，并做好备份。

参考资料：Python 官方文档 venv — Creation of virtual environments。