从Conda到UV：Python项目依赖管理的现代演进

引言：Python开发者的环境管理之痛

如果你是一名Python开发者，你一定经历过这样的场景：

打开终端，面对一堆虚拟环境名称，完全想不起来哪个对应哪个项目。创建新环境时，看着命令行提示，苦思冥想该给它起什么名字。等待pip安装依赖，看着进度条缓慢爬升，内心充满无奈。将项目交给同事，却因为requirements.txt中的版本约束不够精确而反复报错。这些困扰几乎是每个Python开发者的共同记忆。而今天，我想向大家介绍一个正在改变这一现状的工具------UV。

Python作为一门生态系统极其丰富的编程语言，其包管理和环境管理一直是社区讨论的热点话题。从早期的virtualenv到后来的pipenv、poetry，再到conda这样的全能型选手，工具链的演进从未停止。而UV的出现，标志着一个新的阶段------以项目为中心、极速、精确的依赖管理时代正在到来。

为什么我要放弃Conda

Conda的五大痛点

在我多年的Python开发生涯中，Conda确实帮我解决了环境管理的基本问题，但它也带来了一些难以忽视的困扰，这些困扰在日常开发中不断累积，最终促使我寻找替代方案。

第一，命名焦虑

每创建一个新环境，都需要给它起一个名字。对于有选择困难症的程序员来说，这简直是一种折磨。test_env、project_env、env_202401、my_venv、dev_env......到后来自己都分不清这些名字背后的含义。更糟糕的是，当你在终端输入conda activate命令时，面对自动补全弹出的一长串环境名称列表，那种茫然感是每个conda用户都深有体会的。

第二，重复安装浪费时间

每个新环境都需要从头安装所有包。即使某个包已经在另一个环境中安装过了，conda也不会自动复用，而是重新从网络下载并安装。这意味着如果你有十个项目都使用numpy和pandas，那么你需要下载并安装十次。对于网络状况不佳或者包体积较大的情况，这种重复劳动的时间成本是相当可观的。

第三，环境与项目脱节

一个机器上可能有十几个环境对应不同项目，时间一长就完全记不清哪个环境属于哪个项目，更别提项目源码在哪个文件夹下了。你可能会在conda env list中看到一堆名字，但当你想要清理一些不再使用的环境时，你根本不敢轻易删除，因为你已经无法确认这些环境是否还在被某个项目使用。

第四，依赖版本不够精确

传统的requirements.txt通常使用大于等于符号来指定版本约束。这种宽泛的约束在项目初期看起来很方便，但在团队协作和部署上线时却会带来隐患。团队成员可能因为pip安装时的版本解析策略不同而得到不同的依赖组合，导致同样的代码在不同人的机器上表现不一致，甚至直接报错。

第五，手动激活操作繁琐

每次进入项目都需要手动执行conda activate命令来激活对应的虚拟环境。进入项目要激活，切换到另一个项目要先deactivate再activate另一个，日复一日地重复这些操作确实让人感到厌烦。虽然这只是一件小事，但当这种重复操作成为肌肉记忆的一部分时，你总是希望有更优雅的方式来解决它。

理想的解决方案：以项目为中心

针对上述痛点，我在寻找新的工具时明确了以下几个核心诉求：

第一个诉求是以项目为中心进行管理。所谓以项目为中心，通俗来讲就是把所有相关的源码文件和虚拟环境都集中在这个项目的根文件夹里。当我cd进入项目文件夹，我就知道这个虚拟环境是和这个项目绑定的，这样我就不会忘记，也不会记不清哪个虚拟环境对应哪个项目了。

第二个诉求是不用给隔离环境起名。环境的标识就是项目本身，项目文件夹的路径就是环境的唯一标识，不需要额外增加一个抽象的名称层。

第三个诉求是安装依赖包的速度要快，并且不同环境之间如果之前已经安装过相同的包，应该能够复用缓存，而不是每次都重新下载。

第四个诉求是可以精确锁定项目所依赖的每一个包的精确版本，这样其他人在其他机器上就能够精确复现开发环境，避免因为版本不一致导致的各类诡异问题。

第五个诉求是不要每次都手动激活环境。理想的情况是，当我处于项目目录下时，所有Python相关的命令都自动在这个项目的隔离环境中执行。

如果你也认同以上这些诉求，那么UV可能就是一个非常适合你的工具。

UV是什么

UV是一个用Rust编写的包管理和项目管理工具。Rust是一门以性能和内存安全著称的系统编程语言，选择Rust作为实现语言，本身就表明了工具对于性能的追求。

UV的目标是通过一个工具就完成原本需要多个工具配合才能完成的工作。在传统的Python开发流程中，你可能需要pyenv来管理Python版本，需要virtualenv或conda来管理虚拟环境，需要pip来安装包，需要pip-tools或poetry来管理依赖锁定。UV的出现意味着这些工具可以被统一替代。

UV的速度优势是显著的。官方数据显示它的包安装速度比pip快十到一百倍，这得益于Rust的高效实现、智能的缓存策略以及并发的下载机制。在实际使用中，这种速度提升的感受是非常直观的。

UV的统一管理能力体现在三个层面：它能够管理Python解释器的版本，能够管理项目的虚拟环境，能够管理项目依赖的第三方包。这三个层面在UV中被整合成了一个连贯的工作流。

UV简明上手指南

安装UV

安装UV的方式有多种，你可以根据自己的偏好选择。

如果系统上已经安装了Conda，可以使用conda来安装UV：

bash 复制代码

conda install uv

如果更习惯使用pip，同样可以通过pip来安装：

bash 复制代码

pip install uv

安装完成后，可以通过运行uv --version来验证是否安装成功。

管理Python版本

UV安装完成之后，首先可能需要管理Python解释器的版本。不同于conda需要单独安装Python版本管理工具，UV内置了这一能力。

安装最新版本的Python：

bash 复制代码

uv python install

安装指定版本的Python：

bash 复制代码

uv python install 3.12

查看当前系统上已经安装了哪些Python版本：

bash 复制代码

uv python list

创建项目环境

UV以项目为管理单元，创建项目环境的第一步是创建项目文件夹，然后在该文件夹下初始化UV项目。

bash 复制代码

mkdir my_project
cd my_project
uv init

执行uv init之后，UV会在当前目录下创建必要的项目文件。默认情况下，它会创建一个pyproject.toml文件和一个main.py入口文件。

如果不需要自动生成main.py文件，可以使用以下命令只创建必要的配置文件：

bash 复制代码

uv init --no-main

指定Python版本

在项目中使用特定的Python版本，可以通过pin命令来锁定：

bash 复制代码

uv python pin 3.12

UV的Python版本管理非常灵活，你可以随时调整项目使用的Python版本。假设一开始你使用的是3.12，后来发现需要用到3.13的某个新特性，那么直接执行uv python pin 3.13即可。如果发现某个包在3.13上存在兼容性问题，也可以随时降回3.12。

这与conda形成了鲜明对比。在conda中，创建环境时指定的Python版本在环境生命周期内是不可以更改的，如果版本选错了，只能删除环境重新创建。

管理依赖包

在UV管理的环境中安装依赖包，使用add子命令：

bash 复制代码

uv add fastapi

这条命令会将fastapi添加到项目的依赖列表中，同时自动更新uv.lock锁定文件，记录fastapi及其所有间接依赖的精确版本。

移除依赖包使用remove子命令：

bash 复制代码

uv remove fastapi

如果你的项目目前使用的是传统的requirements.txt文件，UV也提供了兼容方案，可以将requirements.txt中的包一次性导入：

bash 复制代码

uv add -r requirements.txt

如果从网上下载了一个已经使用UV管理的项目，或者团队其他成员推送了新代码更新了依赖，可以使用sync命令来同步环境：

bash 复制代码

uv sync

sync命令会读取pyproject.toml中的依赖声明和uv.lock中的精确版本信息，在当前环境中安装所有需要的包。

运行项目

UV最方便的特性之一是不需要手动激活虚拟环境。在conda的工作流中，你需要执行conda activate环境名来激活，然后才能运行项目中的脚本。而在UV中，只需要在命令前面加上uv run即可：

bash 复制代码

uv run python main.py
uv run uvicorn app:app --reload
uv run pytest tests/
uv run python manage.py runserver

无论原本要执行什么Python命令，在前面加上uv run，这个命令就会在项目的隔离环境中执行，而不需要事先激活环境。这使得在脚本中、在IDE配置中、在CI/CD流水线中使用UV变得异常简单和统一。

从Conda迁移到UV

对于已有的conda环境，或者使用pip管理的虚拟环境，UV同样提供了迁移路径。UV对pip命令做了兼容，如果你有一些包习惯用pip安装，可以直接在UV环境中使用uv pip install：

bash 复制代码

uv pip install some_package

这种兼容性设计使得从传统工作流切换到UV变得平滑，不需要一次性重写所有流程。

深入理解UV的核心文件

UV通过三个关键文件来管理项目，理解这三个文件的作用和关系，就基本掌握了UV的工作原理。

pyproject.toml项目配置文件

这是UV的核心配置文件，它遵循Python社区的标准PEP 621规范，包含了项目的元数据和依赖声明。当你初始化一个UV项目时，会自动生成这个文件。

一个空的UV项目，其pyproject.toml文件内容大致如下：

toml 复制代码

[project]
name = "my_project"
version = "0.1.0"
requires-python = ">=3.13"
dependencies = []

这里的name字段默认使用项目文件夹的名称，version是项目的版本号，requires-python指定了项目所需的Python版本范围，dependencies是目前安装的第三方包列表。

当我们执行uv add fastapi之后，dependencies字段会发生变化：

toml 复制代码

[project]
name = "my_project"
version = "0.1.0"
requires-python = ">=3.13"
dependencies = [
    "fastapi>=0.141.1"
]

可以看到，dependencies中新增了fastapi的声明，版本约束使用的是大于等于某个版本号的形式。这种写法在pyproject.toml层面是宽泛的版本约束，它只表达了一个最低兼容版本的要求。

uv.lock精确版本锁定文件

uv.lock是UV相较于传统pip管理工具最突出的差异化设计。在pip的管理体系中，requirements.txt通常只记录顶层依赖和宽泛的版本约束，而间接依赖的版本完全取决于pip安装时的解析结果，不同的环境可能得到不同的版本组合。

uv.lock则完全不同。它是项目在执行uv add或uv sync时自动生成和维护的，不需要用户手动编辑。它所记录的是整个依赖树中每一个包精确的版本号，不仅包括直接依赖的fastapi，还包括fastapi所依赖的starlette、pydantic、typing-extensions等所有间接依赖。

展开一个典型的uv.lock文件，你会看到类似这样的内容：

toml 复制代码

[[package]]
name = "fastapi"
version = "0.141.1"
source = { registry = "https://pypi.org/simple" }
dependencies = [
    { name = "pydantic" },
    { name = "starlette" },
]

[[package]]
name = "pydantic"
version = "2.13.4"
source = { registry = "https://pypi.org/simple" }
dependencies = [
    { name = "pydantic-core" },
    { name = "typing-extensions" },
]

[[package]]
name = "pydantic-core"
version = "2.27.2"
source = { registry = "https://pypi.org/simple" }

[[package]]
name = "starlette"
version = "0.49.2"
source = { registry = "https://pypi.org/simple" }
dependencies = [
    { name = "anyio" },
]

这个文件完整记录了每一个包的来源、版本以及它自身的依赖关系。当团队中的其他成员拿到项目代码后，只需要执行uv sync，UV就会根据uv.lock中的精确版本信息安装完全一致的依赖组合，彻底杜绝了因版本不一致而导致的兼容性问题。

uv.lock是UV实现可重现构建的关键所在，它保证了无论在什么机器上、无论什么时间执行同步操作，得到的依赖环境都是完全相同的。

.python-version Python版本锁定文件

第三个值得关注的文件是.python-version，这是一个非常简短的文件，只包含一行内容：

txt 复制代码

3.13

这个文件记录的是项目所使用的Python解释器的精确主版本号。当执行uv python pin 3.12时，这个文件的内容就会更新为3.12。当再次执行uv python pin 3.13时，文件内容变为3.13。

这个文件的存在使得UV能够在执行uv run时自动选择合适的Python解释器版本，而无需用户手动指定。结合pyproject.toml中的requires-python约束，UV能够确保使用的Python版本既满足项目的最低要求，又符合开发者通过pin命令指定的精确版本。

这三个文件共同构成了UV的项目管理基础。pyproject.toml定义了项目是什么、需要什么，uv.lock锁定了依赖的精确版本，.python-version指定了Python解释器的版本。三位一体，构成了一个完整的、可重现的、以项目为中心的Python开发环境。

UV的局限性

任何工具都不可能面面俱到，UV也有其不擅长的领域。了解这些局限性有助于我们在合适的场景选择合适的工具。

UV的主要短板在于对非Python依赖的管理能力较弱。如果项目仅仅涉及纯Python代码，那么UV完全可以胜任。但如果项目中需要同时管理Python代码和原生库以及其他语言工具链的版本，UV就显得有些力不从心了。

所谓非Python依赖，典型场景包括科学计算项目中需要精确控制CUDA的版本、需要链接特定版本的BLAS库、需要使用C或C++编写的Python扩展并且这些扩展依赖于特定版本的系统库、项目涉及R语言或Julia等其他编程语言的工具链集成。

在这些场景下，Conda仍然是一个更强的选择。因为Conda本质上是一个跨语言的包管理系统，它不仅仅服务于Python生态系统。Conda的包仓库中包含了大量非Python的软件包，从CUDA工具包到HDF5库，从OpenMPI到R语言解释器，覆盖的范围远超PyPI。

具体来说，如果你的项目涉及深度学习模型训练，需要使用特定版本的CUDA和cuDNN，同时Python代码依赖于PyTorch或TensorFlow，那么用Conda来管理这个环境往往更省心。因为Conda可以同时处理CUDA工具链和Python包的版本兼容性，而UV目前还做不到这一点。

所以在选择使用UV还是Conda时，可以按照以下原则来判断：如果项目是纯Python开发或者主要依赖都可以从PyPI获得，那么UV是更好的选择，因为它更快、更轻量、更方便。如果项目的底层依赖比较复杂，涉及大量原生库和多语言工具链，那么Conda仍然是更稳妥的选择。

写在最后

UV正在成为Python项目的新标配

在开源社区中，越来越多的现代Python项目开始采用UV来管理依赖和虚拟环境。这些项目的README文档中，你可以看到它们明确推荐或要求使用UV。例如近期备受关注的Index TTS 2项目，在它的开发文档中就使用了UV作为环境管理工具。

如果你还不熟悉UV，那么当你遇到这类项目时，可能会感到困惑，看不懂项目的搭建流程，甚至无法顺利运行项目。因此，跟上工具链的演进趋势，对于保持技术敏感度和开发效率都是有帮助的。

学习和使用建议

对于希望掌握UV的开发者，我有以下几点建议。

第一，不需要死记硬背所有命令。UV的命令设计得比较直观，常用的就是init、add、remove、sync、run这几个。即使记不住，也可以通过uv --help随时查看帮助信息。

第二，理解三个核心文件的作用比记忆命令更重要。弄清楚pyproject.toml是干什么的，uv.lock解决了什么问题，.python-version记录了什么信息，这些原理性的理解会帮助你更好地使用UV，也能在遇到问题时快速定位原因。

第三，遇到不会的操作时，可以借助AI辅助。现在的大语言模型对UV都有较好的了解，当你不知道某个场景下该用什么命令时，直接向AI描述你的需求，它往往能够给出准确的命令和解释。

第四，如果需要深入了解UV的更复杂功能和高级用法，可以参考官方文档的中文翻译版本，那里的内容更加系统和详尽，涵盖了从基础到进阶的所有内容。

回顾与展望

回顾我们最初提出的五个期望，UV一一给出了答案：它以项目为中心管理环境，不需要额外命名，安装速度快且支持缓存复用，通过uv.lock精确锁定版本，通过uv run免去了手动激活环境的操作。

可以说，UV代表了Python工具链现代化的一个方向。它用Rust编写追求极致性能，它遵循PEP标准保持了与生态的兼容性，它以项目为核心的设计理念贴合了现代开发的实践习惯。

下次当你创建新项目时，不妨告别conda activate加环境名的老流程，试试这样的新体验：

bash 复制代码

mkdir new_project
cd new_project
uv init
uv python pin 3.12
uv add fastapi uvicorn
uv run uvicorn main:app --reload

短短几行命令，一个现代化的Python项目环境就搭建完成了。没有命名焦虑，没有漫长的等待，没有激活环境的额外操作，一切都在项目文件夹内自然而然地完成。

希望这篇文章能够帮助你对UV有一个系统性的了解，并在合适的项目中尝试使用它。