Python虚拟环境.venv与uv创建使用对比：激活、依赖安装、退出

脚本专家

结论先行：.venv 与 uv 不是两套互斥的虚拟环境。.venv 是虚拟环境目录的常见约定名，python -m venv 与 uv venv 最终生成的都是 Python 标准虚拟环境；差别在于创建和管理工具：前者用 Python 自带的 venv 模块，后者用 uv。激活、使用、退出的命令对两者通用，uv 的优势集中在依赖同步、免激活运行和 Python 版本管理。

一、创建方式与核心差异
传统方式：

2. python -m venv .venv

复制代码

这种方式由 Python 标准库 venv 创建虚拟环境，默认目录可用 .venv，也可以自定义名称。uv 方式：

2. uv venv
3. uv venv --python 3.12

复制代码

uv 默认同样生成 .venv，行为与通用约定对齐；--python 参数可用于指定版本。两者生成的目录结构完全一样：Windows 下是 Scripts/，Linux/macOS 下是 bin/。

差异主要在管理能力：传统 venv 创建速度通常是秒级到十秒级，uv 创建速度可到毫秒级；传统方式不支持自动同步 pyproject，需要手动处理，uv sync 可按 pyproject.toml 一键装齐依赖；传统方式运行前通常要先激活，或用完整路径，uv run 可自动识别并使用 .venv，不必激活；Python 版本管理上，传统方式只能使用当前系统 Python，uv 可自动下载或指定任意 Python 版本。

二、Windows 下激活虚拟环境
不同终端激活命令不同。Git Bash：

2. source .venv/Scripts/activate

复制代码

CMD：

2. .venv\Scripts\activate.bat

复制代码

PowerShell：

2. .venv\Scripts\Activate.ps1

复制代码

如果 PowerShell 拦截脚本，先执行：

2. Set-ExecutionPolicy -Scope Process Bypass

复制代码

然后重试。Linux / macOS 可参考：

2. source .venv/bin/activate

复制代码

激活成功的标志是命令行提示符前出现 (.venv)，例如 (.venv) user@pc:~/project$。

三、激活后的常用操作
激活后，pip 和 uv 都可以在同一个虚拟环境内工作。传统 pip 方式：

2. pip install requests
3. pip install -r requirements.txt
4. python xxx.py
5. flask run
6. pytest
7. pip list
8. where python

复制代码

uv 方式：

2. uv pip install requests
3. uv add requests
4. uv sync
5. uv pip install -r requirements.txt
6. uv pip list

复制代码

其中 uv sync 用于读取 pyproject.toml 并安装依赖，uv pip install -r requirements.txt 也可按 requirements.txt 安装。激活后运行 Python，python 即指向 .venv。如果不激活，也可以用完整路径运行，例如：

2. .venv/Scripts/python xxx.py
3. .venv/Scripts/flask run

复制代码

但装包、按清单装依赖、查看包列表这类操作，在完全不激活的通用方式里并不适用，仍需要在虚拟环境中执行。

四、退出虚拟环境
所有终端通用：

2. deactivate

复制代码

退出后 (.venv) 前缀消失，python 恢复指向系统全局环境。

五、uv 的独特用法：不激活也能工作
如果项目使用 uv，可以不走传统激活流程。常用命令如下：

2. uv venv
3. uv venv --python 3.12
4. uv run python app.py
5. uv add requests
6. uv sync

复制代码

含义分别是：在当前目录生成 .venv；指定 Python 版本创建环境；uv run 自动找到并使用 .venv 运行脚本；uv add 自动写入 pyproject.toml 并同步 .venv；uv sync 把 pyproject.toml 中的依赖全部装进 .venv。这个模式适合不想频繁激活，且项目已有或准备使用 pyproject.toml 的场景。

六、选择建议
如果项目还没有引入 uv，传统 python -m venv .venv 加激活命令已经够用；如果项目已有 pyproject.toml，或想利用 uv 的毫秒级创建、uv sync、uv run 等能力，可以直接使用 uv venv 加 uv sync。需要注意的是，uv 创建的仍是标准虚拟环境，激活命令和传统方式一模一样，因此从传统方式切换到 uv 的激活成本几乎为零。把 .venv 看作结果、把 venv 和 uv 看作两种生成与管理方式，就不容易混淆目录名和工具职责。

热心网友1

这个总结很到位，之前确实容易把 .venv 和 uv 混在一起理解，其实一个是目录约定，一个是管理工具。看完最大的感受是激活、退出这些基础操作完全通用，切换成本很低；而 uv 的优势主要在 uv sync、uv run 和 Python 版本管理上。Windows 几种终端的激活命令和 PowerShell 那个设置也写得很实用。选择建议也很中肯：没上 uv 就传统方式够用，有 pyproject.toml 再考虑 uv。感谢整理。

热心网友4

看完总结得很清楚，以前确实容易把 .venv 和 uv 当成两套互斥的东西，按“目录约定”和“创建管理工具”来区分一下就理顺了。Windows 下不同终端的激活命令、PowerShell 的 ExecutionPolicy 处理，还有激活成功后的 (.venv) 标志，这些细节都很实用。uv 那套 uv venv、uv sync、uv run 免激活的流程，对有 pyproject.toml 的项目确实省事；传统 python -m venv .venv 对还没引入 uv 的项目也完全够用。退出统一用 deactivate 这点也少了很多记忆负担。收藏了，后面按项目情况选。

热心网友4

感谢整理，这篇把容易混淆的点讲透了：.venv 只是目录约定，python -m venv 和 uv venv 生成的都是标准虚拟环境，激活、使用、退出命令通用。我最受用的是 Windows 下 Git Bash、CMD、PowerShell 的激活命令分开列了，还有 PowerShell 拦截时的处理；另外 uv run、uv sync、uv add 这种免激活流程，对已有 pyproject.toml 的项目确实省事。没有引入 uv 的项目继续 python -m venv .venv 加激活也完全够用。选择建议很清楚，收藏了。