Python 打包这件事，我一直觉得有点乱。做一个项目，忘了先建虚拟环境，pip 直接把包装到全局。新建了 venv，又忘了激活，结果还是全局。一两次倒没什么，但项目一多，这种低级错误就像循环往复的咒语，时不时就要犯一次。

稍微大一点的项目，我会转向 Poetry —— 它能管依赖、能写 lock 文件、还能打包。比起 pip + venv 的散装组合，Poetry 明显更完整。可问题又来了：它启动慢，体感总是沉甸甸的。对于我手头那些数据脚本、Web 小应用，常常觉得有点大材小用，但又没有更干净的办法，只能硬着头皮用。

打开网易新闻 查看精彩图片

说到底，pip、venv、Poetry 这些工具本身都不差。它们能成为主流，各自都有充足的理由：pip 是 Python 默认的包安装器，venv 负责隔离环境，Poetry 解决了可复现的依赖管理。但切换成本的累加，让我开始问自己一个简单得有点过分的问题：

我为什么非要在三个工具之间跳来跳去？明明一个就能干完的事。

后来我遇到了 uv。它是 Astral 团队（就是那支做出 Ruff 的团队）发布的 Python 包和项目管理器，速度极快。你可以这么理解：以前安装包用一个工具，管虚拟环境用另一个，锁定依赖用第三个，管 Python 版本还得再来一个 —— uv 把这些工作流收敛到了一起。按官方的说法，它在常见场景下比 pip 快 10 到 100 倍，支持项目管理，能生成 lock 文件，还保留了一套兼容 pip 的命令行接口。

这个速度对比听起来像营销话术，但在日常使用里，它带来的改善很实在：Python 项目的初始化变得更快、更干净，那种“我又忘了激活环境”的焦虑也少了很多。

回看我没用 uv 之前的日常，大概是这样的：先用 python -m venv .venv 建环境，接着 source .venv/bin/activate（Windows 下要用 .venv\Scripts\Activate.ps1），然后 pip install 需要的包，最后 pip freeze > requirements.txt。如果项目体量上去了，就转身切到 Poetry：poetry init，poetry add 几个依赖，再用 poetry run python main.py 跑起来。

这个过程并不是不能管理，可就是有种永远在不同工具和不同文件格式之间跳转的摩擦感：有时是 requirements.txt，有时是 pyproject.toml，有时是 lock 文件，有时纯粹因为忘记激活环境，又往全局装了一堆包。问题不大，但又远称不上干净。

uv 进入我的工作流之后，这套跳转几乎就消失了。不必再因为场景的不同，在 pip + venv 和 Poetry 之间反复横跳。无论是快速实验一个笔记本脚本，还是搭建一个稍复杂的应用，多数工作的入口都统一到了一个命令之下。

这种统一不是工具功能的简单堆叠，而是让我不用再去操心“这次该用哪种方式管依赖”这种低价值的决策。工具隐身到工作流背后，让我能更快地从想法跳到代码上，这也是我最终把 pip、virtualenv 与 Poetry 都替换掉的真正原因。