Python 依赖为什么要安装在 .venv 虚拟环境中

一、社区最佳实践：依赖存放在工程目录中

Python 标准流程如下：

• 在项目根目录创建虚拟环境 .venv（或 venv）；
• 项目依赖安装进该项目的
  .venv/lib/pythonxx/site-packages；

• 依赖列表记录在 pyproject.toml 或 requirements.txt 中；
• 运行代码时需激活当前项目的虚拟环境。

.venv 是现代 Python 工具链（uv / Poetry / Pipenv）广泛采用的虚拟环境目录名，已成为事实惯例。

那 Python 全局环境放什么？仅放独立的命令行工具（如 ruff、poetry、uv）。

看起来有点麻烦——新项目要新建虚拟环境、安装依赖，看完本文，就知道这样做的必要性了。

二、不使用虚拟环境会怎样？

Python 默认通过 pip 安装的第三方库，默认安装到当前 Python 环境对应的 site-packages 目录，所有项目共用一套依赖。这导致几个问题：

• 版本冲突：老项目需要 Django 2.2，新项目需要 Django 4.2，全局环境只能存一个版本，必然有一个项目报错。
• 环境污染：全局会堆积大量无用依赖，无法区分哪个包对应哪个项目。
• 系统稳定性风险：若直接操作系统级 Python，可能覆盖系统工具所需的特定包版本，导致系统工具异常。

本地虚拟环境能为单个项目打造独立、隔离、纯净的运行环境，同时也保护了系统 Python 不被污染。

三、对标 npm 与 Maven

其实它们面临的问题都一样，只是解决方式不同。

1. npm：默认本地隔离

npm install 默认将依赖安装在当前项目的 node_modules。

npm 是“默认本地隔离”，而 Python 原生 pip 是默认安装在全局，所以 Python 需要额外的虚拟环境补全这一环。

2. Java Maven：仓库分级隔离

Maven 依靠 GAV 坐标区分不同版本，多个版本的 jar 可以并存于 ~/.m2/repository 本地仓库中。但同一个项目内依赖树最终只会锁定一个版本，且所有项目共用同一个本地仓库缓存，无法像 Python 虚拟环境那样为单个项目提供完全独立的依赖隔离空间。

四、总结

• npm 天生自带项目级隔离；
• Maven 依靠仓库机制规避冲突；
• Python 的 pip 默认将依赖安装至统一目录，因此虚拟环境是官方内置、行业通用的依赖隔离方案。