我要评论一、什么是 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. 依赖隔离
不同项目可能依赖同一包的不同版本：
| 项目 | 依赖 |
|---|---|
| 项目 a | fastapi==0.100 |
| 项目 b | fastapi==0.115 |
若全部装在全局 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 | 包级 | 否 | 否（标准库） |
| virtualenv | 包级 | 否 | 是 |
| conda | 包级 + 环境级 | 是 | 是 |
| pipenv | 包级 | 否 | 是 |
| poetry | 包级 | 否 | 是 |
| docker | 系统级 | 是 | 是 |
选择建议：
- 纯 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的资料请关注代码网其它相关文章！
发表评论