TL;DR：uv 是 Astral（做 Ruff 那家）用 Rust 寫的 Python 套件工具，把 pip、venv、pyenv、pipx 那一整排東西收進同一個指令。uv add 裝套件、uv run 跑程式、uv python install 管版本，第一次跑會自己幫你建好 .venv。安裝速度大概比 pip 快 8 到 10 倍，warm cache 重建環境更誇張。它相容你現有的 requirements.txt，所以想試的話風險很低，挑一個專案換換看就知道。

開一個新的 Python 專案，腦子裡要記的工具有點多。venv 開虛擬環境，pip 裝套件，requirements.txt 記依賴，想管 Python 版本要 pyenv，想把某個 CLI 工具裝成全域又得搬出 pipx，講究一點還會上 poetry 或 pip-tools 處理鎖檔。每個我都會用，但每開一個新專案，那串「先建環境、再 source、再 pip install」的開場白，還是得從頭再打一次。

uv 就是來收拾這一攤的。一個指令，把上面那排東西的活幾乎都接走了。

為什麼 Python 會搞出這麼多工具

這事說來有段歷史。Python 一開始沒把「環境」跟「套件」當成同一個問題在解，所以它們是一塊一塊長出來的：先有 pip 管安裝，後來發現裝一裝會互相打架，才有 virtualenv / venv 把每個專案隔開；再後來大家想鎖死版本好重現，pip-tools、poetry、pipenv 各自上場；版本管理又是另一條線，交給 pyenv。

每個工具單看都合理，合起來就得自己分工：這件事歸誰、那件事又歸誰。uv 的想法很簡單，把這些當成同一個問題的不同切面，用一個工具一起解掉。

它接走了哪些工具

換算起來大概是這樣，左邊是以前的習慣，右邊是 uv 的講法：

以前 現在用 uv
python -m venv .venv 然後 source 不用手動開，uv 第一次跑會自己建 .venv
pip install requests uv add requests
pip install -r requirements.txt uv pip install -r requirements.txt（指令相容）
python script.py uv run script.py（自動在對的環境裡跑）
pyenv install 3.12 uv python install 3.12
pipx run black uvx black
poetry 那套鎖檔、發佈 uv（pyproject.toml + uv.lock）

幾個比較有感的點。uv add 第一次在一個資料夾裡跑，它會順手把虛擬環境建好、把依賴寫進 pyproject.toml，你不用記得先 activate 那一步——uv run 會自己找到那個環境再執行。uvx 是 uv tool run 的縮寫，拿來跑一次性的 CLI 工具，它會開一個臨時環境跑完就收，剛好補上 pipx 的位子。版本管理也是內建的，uv python install 3.12 直接幫你抓一份回來，連 pyenv 都省了。

還有個小地方我覺得很關鍵：uv 本身是一顆單一 binary，裝它不需要你先有 Python。這聽起來像廢話，但 pyenv 那種「要先有 Python 才能管 Python」的雞生蛋問題，它一開始就繞過去了。

快這件事，到底快多少

uv 最常被拿出來講的賣點就是快，而且是用 Rust 寫的那種快。它的下載是並行的、抓 metadata、解依賴、寫磁碟這些步驟會重疊著跑；pip 預設是一個一個照順序下載，又卡在 Python GIL，差距就出來了。

具體一點的數字：裝 JupyterLab 這種套件，pip 量到大概 21 秒，uv 大概 2.6 秒，8 倍。如果是 warm cache（這些套件你機器上抓過了），uv 會用 hardlink 直接把環境拼起來，那快法更不像話：重建一個一二十個套件的環境，pip 要等上好幾秒，uv 零點幾秒就好。

Astral 官方掛的數字是「快 10 到 100 倍」。這話我覺得誠實，但要會看區間：接近 100 倍那端是 warm cache 重建環境的情況，日常比較常遇到的是沒 cache 的全新安裝，獨立測試量出來大概落在 8 到 10 倍。就算砍到區間最低，省下的時間每天累積起來也很有感，尤其 CI 每跑一次都要重裝一輪的話。順帶一提，到今年四月，uv 在 PyPI 上的月下載量已經到七千五百萬，超過了 Poetry，也慢慢變成不少 CI 的預設選擇。

換過去之後，最有感的不是快

用了一陣子，速度反而不是我最在意的部分。最有感的是腦子裡那張表不見了。

以前要在心裡分一下「環境的事問 venv、裝的事問 pip、版本的事問 pyenv、全域工具問 pipx」，現在就是 uv 開頭，接著想做什麼。少掉的不是那幾秒，是每開新專案都要先在腦中把工具鏈排一次的那點麻煩。這跟我之前寫 AI 寫 code 為什麼又搬回終端機 時的感覺有點像：工具真正的價值，常常不在它多了什麼功能，而在它幫你少記了什麼東西。

那要不要現在就換

我不會說「所有人立刻全換」，那有點像在賣東西。比較持平的講法是：純 pip / venv 的專案，幾乎是無痛搬，因為 uv 連 pip 的指令介面都相容，你 uv pip install -r requirements.txt 一樣會動，等於先用熟悉的姿勢試水溫。

要留意的主要是 conda 那一圈。做科學運算、吃一堆非 Python 二進位依賴（那種 conda 幫你打包好的 C / Fortran 函式庫）的場景，搬過來不是無痛的，這塊 conda 還是有它的理由在。如果你平常就是 pip 派的，那大概可以放心試；如果重度靠 conda，就先別急。

想試的話，從一個專案開始

裝 uv 官網給的是一行指令的安裝 script（macOS / Linux 用 curl ... | sh，Windows 有對應的 PowerShell 版），或者你習慣 Homebrew、winget、pipx 也都裝得到。裝完別急著全面翻新，挑一個現有的小專案：

# 進到專案資料夾，照現有的 requirements.txt 裝
uv venv
uv pip install -r requirements.txt

# 或者開始用 uv 自己的管法
uv init
uv add requests
uv run python main.py

跑個幾次，感覺一下那個「不用先 activate」跟「裝套件快到有點不真實」的差別。喜歡再慢慢往其他專案推就好，反正它不會逼你一次到位。

說到底 uv 沒發明什麼新觀念，虛擬環境、鎖檔、版本管理這些事 Python 圈早就在做。它只是把散在各處的工具收進同一個入口，再用 Rust 把速度補上。就這樣而已，但每天用下來，這樣也就夠了。

延伸閱讀：

想看源頭的話：uv 官方文件、astral-sh/uv on GitHub。

English version: uv: the Python tool that replaces pip, venv, and pyenv