全面轉向用環境變數配置 uv，簡化設定、提升效率，取代 uv.toml，適用於多元開發環境並強化管理透明度。
前言： 如果你是 Python 開發者，過去幾年想必曾在 pip、conda、poetry 與 pipenv 之間反覆折騰。每一款工具各有千秋，卻也都有令人抓狂的短板——不是執行速度緩慢、鎖定檔（lock file）混亂，就是 Python 版本管理與套件管理被拆解成兩套割裂的體系。 直到 uv 的出現。 這款由 Astral 團隊（同時也是 Ruff 程式碼檢查工具的開發者）以 Rust 語言編寫的工具，野心極大：它致力於成為 Python 生態中「統一的瑞士刀」——試圖以單一工具取代 pip、pip-tools、pipx、poetry、pyenv 與 virtualenv 的所有功能，同時將執行速度提升一個數量級。 在複雜的工程實踐中，開發者常面臨網路代理限制、系統磁碟空間不足、跨平台環境不一致等痛點。儘管 uv 提供了 uv.toml 設定檔，但由於其設計上的「非對稱性」（部分核心路徑如 Python 安裝目錄僅支援環境變數），為了達成配置方式的絕對統一與最大靈活性，本文建議完全捨棄 uv.toml，統一透過系統級環境變數來管理 uv。
先前我一直使用 rye 進行 Python 專案的建構與管理，但在 2025 年 2 月，官方宣布停止維護，並建議全面遷移至 uv。在實際開發中，真正需要關注的配置其實不多，核心僅有兩項路徑：Python 直譯器安裝位置、套件快取儲存位置。此外，網路代理在開發環境中幾乎是必備項目；而針對機器學習場景，還需額外處理 PyTorch 等特殊套件的安裝來源。掌握這四個面向，uv 的配置便足以涵蓋絕大多數的日常開發場景。
uv 的設計中存在一個關鍵的配置差異：
這種不統一意味著，若您依賴 uv.toml，仍無法完整配置 uv 的所有行為。統一使用環境變數 (Environment Variables) 是目前最專業、最無歧義的深度客製化方案。
透過環境變數，我們可以輕鬆地將 uv 的大型資料目錄（包含 Python 版本與快取）從系統磁碟（如 Windows 的 C 槽）移至其他位置。
當您執行 uv python install 時，uv 會從 python-build-standalone 專案下載預先編譯好的 Python 發行版。
uv 的高速相依性解析完全仰賴本機快取。
這是 uv 目前最依賴環境變數的部分。由於 uv 內部並未提供獨立的代理開關，它會直接繼承 Shell 的標準代理變數。不過我個人認為，考量到現實中網路環境的複雜性——例如企業內網、科研機構的隔離網路，以及各式家庭代理——uv 日後或許有必要將代理參數視為一等公民納入其配置體系，而非完全依賴 Shell 層級的環境變數繼承。我目前採用的做法是：每次執行 uv add 或 uv sync 時，預先在當前的 Shell 中設定代理配置。
若您處於公司內網，或需要透過特殊的網路環境來安裝套件，請直接在環境變數中指定：
雖然不再使用全域的 uv.toml，但在專案層級，仍需透過 pyproject.toml 中的 [[tool.uv.index]] 來管理特定的安裝來源（例如 PyTorch 的 CUDA 來源）。這是專案相依性邏輯的一部分，而非工具本身的偏好設定。
設定好 pyproject.toml 後，執行下列指令安裝相依套件：
注意：torch、torchvision 與 torchaudio 三者的版本必須嚴格對應，混用不同版本極易引發執行階段錯誤。建議務必在 pyproject.toml 中同步鎖定這三者的版本下限。
既然已經統一了環境變數，所有的維護操作都會變得非常透明：
uv 憑藉著極致的依賴解析速度與統一的工具鏈，帶來了前所未有的開發效率，令人愛不釋手。然而，繁多的配置選項確實容易讓初次接觸的開發者感到眼花撩亂，不知從何下手。
本文的核心觀點只有一個：全面擁抱環境變數，捨棄 uv.toml。這一策略不僅涵蓋了所有配置場景（包含 uv.toml 無法支援的 Python 安裝路徑與代理設定），更讓工具配置與系統層級的設定高度統一，不僅清晰易讀，也便於追蹤管理。