Python中虚拟环境venv创建和使用教学

一、什么是 venv

venv 是 python 标准库自带的虚拟环境（virtual environment）模块，从 python 3.3 起内置，用于创建隔离的 python 运行环境。

一个虚拟环境本质上是一个目录，里面包含：

• 一套独立的 python 解释器（python.exe / python）
• 独立的包管理工具（pip）
• 独立的第三方包安装目录（site-packages）
• 激活脚本（activate / activate.bat / activate.ps1）
• 配置文件 pyvenv.cfg

它不是一个沙箱或容器，而是通过路径重定向实现的轻量级隔离。

二、目录结构

以 windows 下 backend\venv 为例：

backend\venv\
├── scripts\
│   ├── python.exe          # 该环境的 python 解释器
│   ├── pip.exe             # 该环境的 pip
│   ├── activate.bat        # cmd 激活脚本
│   ├── activate.ps1        # powershell 激活脚本
│   ├── uvicorn.exe         # 已安装的命令行工具
│   └── ...
├── lib\
│   └── site-packages\      # 该环境专属的第三方包
├── include\                # c 扩展头文件
└── pyvenv.cfg              # 关键配置：记录创建时的 python 路径与版本

linux / macos 下对应结构为：

venv/
├── bin/
│   ├── python
│   ├── pip
│   ├── activate
│   └── ...
├── lib/
│   └── python3.x/
│       └── site-packages/
└── pyvenv.cfg

三、核心机制

1. 创建

python -m venv venv

执行后，python 会：

• 在目标目录生成一套解释器入口（windows 上是真实的 python.exe 副本，linux 上通常是指向系统解释器的符号链接）。
• 写入 pyvenv.cfg，记录创建它的基础 python 的路径和版本。
• 安装一份独立的 pip。

2. pyvenv.cfg

这是虚拟环境的“身份证”，例如：

home = c:\python314
include-system-site-packages = false
version = 3.14.x

• home：创建它的基础 python 所在目录。
• version：基础 python 版本。
• include-system-site-packages：是否允许访问全局 site-packages，默认 false。

虚拟环境与创建它的 python 版本永久绑定，这是关键特性。

3. 激活

# windows cmd
venv\scripts\activate.bat

# windows powershell
venv\scripts\activate.ps1

# linux / macos
source venv/bin/activate

激活的本质是修改当前 shell 的 path，把 venv/scripts（或 venv/bin）排到最前面。此后：

• python → 指向虚拟环境里的解释器
• pip → 指向虚拟环境里的 pip
• 安装的包 → 进入虚拟环境的 site-packages

激活只在当前 shell 会话生效，关闭终端即失效。

4. 退出

deactivate

恢复原来的 path。

四、为什么需要 venv

1. 依赖隔离

不同项目可能依赖同一包的不同版本：

若全部装在全局 python 中，必然冲突。虚拟环境让每个项目拥有独立的依赖集合。

2. 避免污染全局环境

实验性、一次性、版本敏感的包不会影响系统 python，降低“装崩全局环境”的风险。

3. 便于复现

配合 requirements.txt 或 pyproject.toml，可在任意机器上重建一致环境：

pip install -r requirements.txt

4. 权限友好

在 linux 上无需 sudo 即可安装包。

五、常见误区

误区 1：激活 venv 后，path 里的 python 版本仍生效

错。 激活后，python 命令解析到虚拟环境里的解释器，与系统 path 中的 python 无关。

误区 2：系统显示 python 3.11，项目用的就是 3.11

错。 若 venv 是用 3.14 创建的，激活后实际运行的是 3.14。判断依据是 pyvenv.cfg 里的 version，而非系统 python --version。

误区 3：venv 是沙箱，能隔离系统资源

错。 venv 只隔离 python 包，不隔离文件系统、网络、进程。需要更强隔离应使用 docker、conda、virtualenv（功能更全）等。

误区 4：venv 可以随意换 python 版本

错。 venv 与创建它的 python 版本绑定。要换版本，必须删除重建：

rm -rf venv          # linux / macos
rmdir /s /q venv     # windows
python -m venv venv  # 用新版本重建

六、典型问题案例

现象

脚本运行后报错：

python reports soabi: cp314-win_amd64
...
modulenotfounderror: no module named 'loguru'

但用户在命令行查看 python --version 显示 3.11.9。

原因

• backend\venv 是之前用 python 3.14 创建的。
• 脚本检测到 venv 已存在，跳过创建，直接 activate。
• 激活后 pip install -r requirements.txt 使用 3.14 安装依赖。
• 部分包（如 pydantic-core）在 3.14 下无预编译 wheel，pip 回退到源码构建，需要 rust 工具链，网络失败导致安装中断。
• loguru 等包实际未装上。
• 启动 uvicorn 时立即 modulenotfounderror。

解决

删除 venv，用 3.11.9 重建：

rmdir /s /q backend\venv
python -m venv backend\venv
backend\venv\scripts\activate.bat
pip install -r backend\requirements.txt

七、venv 与其他方案对比

选择建议：

• 纯 python 项目、依赖不复杂 → venv 足够。
• 需要管理多个 python 版本或科学计算栈 → conda。
• 需要完整环境复现、部署一致性 → docker。

八、最佳实践

每个项目一个 venv，放在项目根目录，命名为 venv 或 .venv。

将 venv 加入 .gitignore，绝不提交到版本控制。

用 requirements.txt 或 pyproject.toml 锁定依赖版本，保证可复现。

换 python 版本时删除重建 venv，不要试图复用。

ci/cd 中显式指定 python 版本，避免本地与流水线不一致。

判断 venv 实际版本看 pyvenv.cfg，不要只看系统 python --version。

激活后确认解释器路径：

where python     # windows
which python     # linux / macos

应指向 venv 内部。

九、一句话总结

venv 是 python 内置的轻量级依赖隔离工具，通过独立的解释器入口、site-packages 和 pyvenv.cfg 实现项目级环境隔离；它与创建时的 python 版本永久绑定，换版本必须删除重建，激活后系统 path 中的 python 版本不再生效。

以上就是python中虚拟环境venv创建和使用教学的详细内容，更多关于python虚拟环境venv的资料请关注代码网其它相关文章！