Python虚拟环境.venv与uv创建使用对比：激活、依赖安装、退出
结论先行：.venv 与 uv 不是两套互斥的虚拟环境。.venv 是虚拟环境目录的常见约定名，python -m venv 与 uv venv 最终生成的都是 Python 标准虚拟环境；差别在于创建和管理工具：前者用 Python 自带的 venv 模块，后者用 uv。激活、使用、退出的命令对两者通用，uv 的优势集中在依赖同步、免激活运行和 Python 版本管理。一、创建方式与核心差异
传统方式：
python -m venv .venv
这种方式由 Python 标准库 venv 创建虚拟环境，默认目录可用 .venv，也可以自定义名称。uv 方式：
uv venv
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：
source .venv/Scripts/activate
CMD：
.venv\Scripts\activate.bat
PowerShell：
.venv\Scripts\Activate.ps1
如果 PowerShell 拦截脚本，先执行：
Set-ExecutionPolicy -Scope Process Bypass
然后重试。Linux / macOS 可参考：
source .venv/bin/activate
激活成功的标志是命令行提示符前出现 (.venv)，例如 (.venv) user@pc:~/project$。
三、激活后的常用操作
激活后，pip 和 uv 都可以在同一个虚拟环境内工作。传统 pip 方式：
pip install requests
pip install -r requirements.txt
python xxx.py
flask run
pytest
pip list
where python
uv 方式：
uv pip install requests
uv add requests
uv sync
uv pip install -r requirements.txt
uv pip list
其中 uv sync 用于读取 pyproject.toml 并安装依赖，uv pip install -r requirements.txt 也可按 requirements.txt 安装。激活后运行 Python，python 即指向 .venv。如果不激活，也可以用完整路径运行，例如：
.venv/Scripts/python xxx.py
.venv/Scripts/flask run
但装包、按清单装依赖、查看包列表这类操作，在完全不激活的通用方式里并不适用，仍需要在虚拟环境中执行。
四、退出虚拟环境
所有终端通用：
deactivate
退出后 (.venv) 前缀消失，python 恢复指向系统全局环境。
五、uv 的独特用法：不激活也能工作
如果项目使用 uv，可以不走传统激活流程。常用命令如下：
uv venv
uv venv --python 3.12
uv run python app.py
uv add requests
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 看作两种生成与管理方式，就不容易混淆目录名和工具职责。
Re: Python虚拟环境.venv与uv创建使用对比：激活、依赖安装、退出
这个总结很到位，之前确实容易把 .venv 和 uv 混在一起理解，其实一个是目录约定，一个是管理工具。看完最大的感受是激活、退出这些基础操作完全通用，切换成本很低；而 uv 的优势主要在 uv sync、uv run 和 Python 版本管理上。Windows 几种终端的激活命令和 PowerShell 那个设置也写得很实用。选择建议也很中肯：没上 uv 就传统方式够用，有 pyproject.toml 再考虑 uv。感谢整理。Re: Python虚拟环境.venv与uv创建使用对比：激活、依赖安装、退出
看完总结得很清楚，以前确实容易把 .venv 和 uv 当成两套互斥的东西，按“目录约定”和“创建管理工具”来区分一下就理顺了。Windows 下不同终端的激活命令、PowerShell 的 ExecutionPolicy 处理，还有激活成功后的 (.venv) 标志，这些细节都很实用。uv 那套 uv venv、uv sync、uv run 免激活的流程，对有 pyproject.toml 的项目确实省事；传统 python -m venv .venv 对还没引入 uv 的项目也完全够用。退出统一用 deactivate 这点也少了很多记忆负担。收藏了，后面按项目情况选。Re: Python虚拟环境.venv与uv创建使用对比：激活、依赖安装、退出
感谢整理，这篇把容易混淆的点讲透了：.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 加激活也完全够用。选择建议很清楚，收藏了。
页:
[1]