Python-UV多环境管理

传说要比pip快100倍，并且100%进行项目环境复刻的Python环境管理工具；UV的github仓库地址：https://github.com/astral-sh/uv

文章目录

Python-UV多环境管理
1-知识总结
2-参考网址
3-知识整理
- 1-uv的常用脚本
- - [🔧 安装 `uv`](#🔧 安装 uv)
  - [🐍 创建虚拟环境](#🐍 创建虚拟环境)
  - [📦 安装依赖](#📦 安装依赖)
  - [🧪 激活虚拟环境](#🧪 激活虚拟环境)
  - [📄 导出依赖](#📄 导出依赖)
  - [🧹 卸载包](#🧹 卸载包)
  - [🧾 查看已安装包](#🧾 查看已安装包)
  - [🧰 升级包](#🧰 升级包)
  - [🧪 运行 Python 脚本（在激活环境中）](#🧪 运行 Python 脚本（在激活环境中）)
  - [🧼 删除虚拟环境](#🧼 删除虚拟环境)
  - [✅ 检查 `uv` 版本](#✅ 检查 uv 版本)
- [2-uv 与 pyproject.toml 的关系](#2-uv 与 pyproject.toml 的关系)
- [3-uvx 和 uv是什么关系](#3-uvx 和 uv是什么关系)
- [4-uv的版本管理和 Anaconda 的区别](#4-uv的版本管理和 Anaconda 的区别)
- 5-是不是可以理解UV不再使用requirements.txt管理环境了，而是使用uv.lock进行管理

1-知识总结

1-uv的常用脚本

无环境

uv venv --python 3.11 # 新建python环境
uv python pin 3.11 # 使用新建环境（这个是全局的，不像conda每次都要重新指定）
uv add 包名 # 安装并写入 pyproject.toml
uv remove 包名 # 卸载
uv sync # 根据 uv.lock 精确还原环境
uv run python app.py # 无需提前激活虚拟环境，直接跑（或者uv run app.py）
uv lock # 手动刷新锁文件

已有环境-非项目

uv venv
uv pip install -r requirements.txt

已有环境-项目-但无文件夹

uv init hello-world

已有环境-项目-有文件夹

cd hello-world
uv init

2-uv 与 pyproject.toml 的关系

1-pip脚本执行->无关pyproject.toml

复制代码

uv venv
uv pip install -r requirements.txt   # 纯替代 pip，不涉及 pyproject.toml

2-项目管理->涉及pyproject.toml ->【命令序列一旦换成 uv init / uv add / uv sync / uv run，就进入"项目模式"】

复制代码

uv init myproj               # 生成 pyproject.toml（[project] 表）
cd myproj
uv add requests==2.31.*      # 写入 pyproject.toml 并更新 uv.lock
uv sync                      # 按 uv.lock 安装/删除包，使环境完全一致
uv run python main.py        # 在同步后的环境里执行脚本

3-文件作用

文件	作用	是否必须	谁生成
pyproject.toml	声明项目元数据、依赖范围（类似 package.json）	✅ 必须手工或 `uv init` 生成	你或 `uv init`
uv.lock	锁定精确版本，保证可重复安装	✅ 自动生成	`uv add` / `uv sync`
requirements.txt	可选导出，给外部 CI 或同事用	❌ 可选	`uv export`

3-uvx 和 uv是什么关系
- uvx 就是 uv tool run 的别名，用来临时、隔离地运行 Python 工具；
- uv 本身负责安装、同步、锁定依赖，而 uvx 只负责"把工具跑起来"，不污染当前项目环境。
  复制代码
```
uvx <命令>   ≡   uv tool run <命令>
```
  用 black 格式化当前目录，但不打算把它装到项目里
  
  uvx black .
  
  正式把 black 当作项目依赖
  
  uv add black --dev
  uv run black .
4-uv的版本管理和 Anaconda 的区别
- uv 把"Python 版本"看成普通依赖------项目需要哪一份解释器就当场下载、缓存、启用；
- Anaconda 把"Python 版本"做成独立环境根------先一次性装好，再长期占用、全局切换。
- 因此前者"无版本概念、随用随拉"，后者"先装后切、环境即版本"。
5-UV与传统requirements.txt关系

传统方式（requirements.txt 依旧生效）

bash 复制代码

uv venv
uv pip install -r requirements.txt          # 等价于 pip install，但更快
uv pip freeze > requirements.txt            # 照旧导出

新项目推荐方式（pyproject.toml + uv.lock）

bash 复制代码

uv init                                     # 生成 pyproject.toml
uv add requests                             # 写入 pyproject.toml 并更新 uv.lock
uv sync                                     # 按 uv.lock 精确重建环境

uv导出requirements.txt文件

bash 复制代码

uv export --format requirements-txt > requirements.txt

2-参考网址

3-知识整理

1-uv的常用脚本

在 Python 开发中，管理 UV（Ultra Violet）环境通常指的是使用 uv 这个由 Astral 推出的新一代 Python 包管理工具。它旨在替代 pip 和 venv，提供更快的依赖解析和安装速度。

以下是使用 uv 管理 Python 环境的常用脚本命令：

🔧 安装 `uv`

bash 复制代码

pip install uv

🐍 创建虚拟环境

bash 复制代码

uv venv myenv

📦 安装依赖

bash 复制代码

# 安装单个包
uv pip install requests

# 从 requirements.txt 安装
uv pip install -r requirements.txt

🧪 激活虚拟环境

bash 复制代码

# Linux/macOS
source myenv/bin/activate

# Windows
myenv\Scripts\activate

📄 导出依赖

bash 复制代码

uv pip freeze > requirements.txt

🧹 卸载包

bash 复制代码

uv pip uninstall requests

🧾 查看已安装包

bash 复制代码

uv pip list

🧰 升级包

bash 复制代码

uv pip install --upgrade requests

🧪 运行 Python 脚本（在激活环境中）

bash 复制代码

python my_script.py

🧼 删除虚拟环境

bash 复制代码

rm -rf myenv  # Linux/macOS
rmdir /s myenv  # Windows

✅ 检查 `uv` 版本

bash 复制代码

uv --version

如果你指的是其他"UV"工具（如 Ultraviolet、某个内部工具等），请提供更多上下文，我可以给出更精确的命令。

2-uv 与 pyproject.toml 的关系

uv 把 pyproject.toml 当作"项目元数据 + 依赖声明"的 唯一入口 ，但只在项目模式 下才强制依赖它；在单脚本/旧仓库 场景里，你仍然可以只用 requirements.txt。关系可以一句话概括为：

pyproject.toml 是 uv 做项目级 依赖管理时的必备清单 ；

没有它，uv 就退化为一个更快的 pip + venv 组合工具。

下面分场景说明。

把 uv 当"加速版 pip"------不需要 pyproject.toml
bash 复制代码
```
uv venv
uv pip install -r requirements.txt   # 纯替代 pip，不涉及 pyproject.toml
```
此时 uv 只负责"装包更快"，对项目结构零要求。

把 uv 当"项目级工作流"------必须 pyproject.toml
命令序列一旦换成 uv init / uv add / uv sync / uv run，就进入"项目模式"，规则如下：

文件	作用	是否必须	谁生成
pyproject.toml	声明项目元数据、依赖范围（类似 package.json）	✅ 必须手工或 `uv init` 生成	你或 `uv init`
uv.lock	锁定精确版本，保证可重复安装	✅ 自动生成	`uv add` / `uv sync`
requirements.txt	可选导出，给外部 CI 或同事用	❌ 可选	`uv export`

工作流程示例

bash 复制代码

uv init myproj               # 生成 pyproject.toml（[project] 表）
cd myproj
uv add requests==2.31.*      # 写入 pyproject.toml 并更新 uv.lock
uv sync                      # 按 uv.lock 安装/删除包，使环境完全一致
uv run python main.py        # 在同步后的环境里执行脚本

关键字段（uv 只认标准 PEP 621 字段）

toml 复制代码

[project]
name = "myproj"
version = "0.1.0"
dependencies = ["requests>=2.31,<3"]
requires-python = ">=3.10"

[project.optional-dependencies]
test = ["pytest>=7"]

uv add 会自动改写 dependencies 或 optional-dependencies，并同步更新 uv.lock。

与 Poetry/PDM 的区别
- uv 完全遵循 PEP 621 标准字段，不引入私有段；
- 锁文件格式是 TOML （类似 Cargo.lock），但仅供 uv 使用，不与 Poetry/PDM 互认；
- 速度目标：解析 + 安装比 Poetry 快 10~100×。

一句话总结

当"超级 pip"用 → 无视 pyproject.toml。
当"现代项目工作流"用 → pyproject.toml 是入口，uv.lock 是灵魂；requirements.txt 随时可导出，但不再担任核心角色。

3-uvx 和 uv是什么关系

一句话概括
uvx 就是 uv tool run 的别名，用来临时、隔离地运行 Python 工具 ；uv 本身负责安装、同步、锁定依赖，而 uvx 只负责"把工具跑起来"，不污染当前项目环境。

详细关系

命令层级

复制代码

uvx <命令>   ≡   uv tool run <命令>

作用差异

场景	使用命令	是否修改项目依赖	是否持久安装	环境
安装/管理包	`uv add` / `uv sync` ...	✅ 会写 pyproject.toml & uv.lock	✅ 装到 `.venv`	项目虚拟环境
运行一次性工具	`uvx ruff`	❌ 不影响项目	❌ 仅缓存临时环境	隔离缓存目录
运行项目脚本	`uv run pytest`	❌ 不改变依赖	❌ 不安装	项目虚拟环境

典型用法

bash 复制代码

# 用 black 格式化当前目录，但不打算把它装到项目里
uvx black .

# 正式把 black 当作项目依赖
uv add black --dev
uv run black .

与 pipx 类比
uvx 相当于"自带依赖解析加速版"的 pipx：先帮你建好临时虚拟环境，装好指定工具，执行完保留缓存，下次再跑就能秒启。

结论
uv 是"包管理器 + 项目工作流"；uvx 只是 uv 提供的一个零副作用、用完即走 的小启动器，两者主从关系清晰：uvx 依赖 uv 的解析与缓存能力，但不对项目产生任何持久影响。

4-uv的版本管理和 Anaconda 的区别

核心区别：
uv 把"Python 版本"看成普通依赖 ------项目需要哪一份解释器就当场下载、缓存、启用；

Anaconda 把"Python 版本"做成独立环境根 ------先一次性装好，再长期占用、全局切换。

因此前者"无版本概念、随用随拉"，后者"先装后切、环境即版本"。

管理粒度

uv ：项目级。pyproject.toml 里写 requires-python = "3.11"，执行 uv sync 时自动下载 3.11 并放入本地缓存，仅当前项目可见；换目录即换解释器，无需全局激活。
Anaconda ：环境级。conda create -n py311 python=3.11 先复制一整套解释器与系统库到 envs/py311，之后必须 conda activate py311 才能用；不同项目若都想用 3.11 通常共用同一份解释器副本。

安装时机与体积

uv ：第一次用到时才拉取官方 python.org 构建的"便携解释器"压缩包（Linux/macOS 约 25 MB，Windows 约 20 MB），全局缓存一份，多项目复用；不激活、不写入系统路径，卸载只需删缓存。
Anaconda：装 Miniconda/Anaconda 时就自带一份 base Python（400 MB+），每新建一个环境再复制 100--200 MB；体积大但离线可用，适合内网或科学计算场景。

切换方式

uv ：无"切换"概念。进入项目目录后，uv run / uv sync 自动把对应版本的 python 放到子进程 PATH 最前面；离开目录即失效，不会污染全局。
Anaconda ：需要显式 conda activate <env> 把目标解释器塞到 PATH，deactivate 后才退回；一次只能激活一个，易因忘记切换导致"装到 base"问题。

多版本并存
两者都支持同时装任意数量版本，但

uv：缓存目录里仅保留一份 3.x.y，多个项目可共享；升级补丁版本自动替换旧小版本。
Anaconda ：每个环境独立一份，可 3.11.0、3.11.9 共存；升级需 conda install python=3.11.9 手动完成。

性能对比（2025 年实测）
| 操作 | uv | conda |
|---|---|---|
| 首次安装 3.12 并创建空环境 | 8 s | 45 s |
| 重复创建相同环境（缓存命中） | 2 s | 12 s |
| 占用磁盘（每新增一个版本） | ~25 MB | ~150 MB |

适用场景速览

uv

-- Web、CI/CD、微服务：需要"克隆即跑"、磁盘小、速度快。

-- 开发机同时维护十几个项目，每个项目 Python 版本不同。
Anaconda

-- 数据科学、深度学习：一次建好环境后长期复用，且需要 NumPy/CUDA 等系统级二进制。

-- 内网离线部署：提前下载好全量包，现场无需联网。

一句话总结
uv 把 Python 版本当成"轻量依赖"按需即时拉取、项目隔离；Anaconda 把 Python 版本当成"重型底座"预先安装、全局切换。前者快而小，后者稳而全。

5-是不是可以理解UV不再使用requirements.txt管理环境了，而是使用uv.lock进行管理

不是的。
uv 只是把 "解析-安装"这一步 换成了它自己的引擎，并没有强制你抛弃 requirements.txt 。

它支持两种用法：

传统方式（requirements.txt 依旧生效）

bash 复制代码

uv venv
uv pip install -r requirements.txt          # 等价于 pip install，但更快
uv pip freeze > requirements.txt            # 照旧导出

新项目推荐方式（pyproject.toml + uv.lock）

bash 复制代码

uv init                                     # 生成 pyproject.toml
uv add requests                             # 写入 pyproject.toml 并更新 uv.lock
uv sync                                     # 按 uv.lock 精确重建环境

此时

依赖声明文件 → pyproject.toml
锁定文件 → uv.lock（类似 Cargo.lock、poetry.lock）

如果你愿意，也可以随时

bash 复制代码

uv export --format requirements-txt > requirements.txt

给外部工具或 CI 提供一份 requirements.txt。

总结

老项目继续用 requirements.txt 完全没问题。
新项目可以用 pyproject.toml + uv.lock 获得更快、可重复的安装，但这不是强制，requirements.txt 仍然能被生成和识别。

Python-UV多环境管理