優化版：【保姆級喂飯教程】優化版：Python依賴管理工具終極指南（2025最新版）

前言1

在 Python 開發中，虛擬環境和包管理工具是必不可少的。它們可以幫助我們更好地管理項目依賴，避免環境沖突，提高開發效率。但是依賴管理堪稱“頭號工程難題”——環境沖突、版本不一致、部署失敗等問題層出不窮。
由于Python的庫發展的非常快，工具也是日新月異，搜索會發現有pip，venv、Virtualenv、Conda、Pipenv、Poetry、UV等等，你是否能把它們完全分清楚？
本文全面梳理解析截至目前的所有主流依賴工具，并分類介紹，涵蓋基礎工具、現代解決方案與新興神器，助你精準選擇最適合項目的武器庫！

---

前言2

在深入對比之前，我們先明確虛擬環境和包管理工具的核心作用：
包管理：管理項目的依賴包，包括安裝、更新、卸載等操作，并確保依賴關系的一致性。
虛擬環境：為每個項目創建一個獨立的Python運行環境，隔離依賴，避免不同項目之間的包版本沖突。

一、包管理工具

1. pip（Python官方，2008）

pip GitHub

• 定位：Python包安裝核心引擎，最基本也是最廣泛使用的 Python 包安裝工具，所有工具底層依賴 ，從PyPI安裝庫，由PyPA組織維護。
  PyPA：指 Python Packaging Authority，一個維護 Python 打包相關項目的小組，包括 pip、packaging、setuptools、wheel、twine、build 等，相關項目具體見 https://github.com/pypa。
• 優點：無需安裝，pip install 即用，支持PyPI源定制。
• 缺點：無依賴沖突解決能力，無環境隔離功能
• 場景：臨時腳本安裝包，其他工具的底層引擎

二、虛擬環境工具

1. virtualenv（Ian Bicking，2007）

virtualenv GitHub

舊時代的產物，除非還在使用python 2。

• 定位：第三方虛擬環境工具（支持Python 2/3）
• 功能：創建隔離環境，支持指定不同 Python 解釋器。依賴 pip 管理包。
• 優點：支持舊版 Python（如 Python 2）。可指定任意Python解釋器，支持--system-site-packages復用系統包 。
• 缺點：需額外安裝，Windows兼容性較弱 。依賴管理需手動處理。無自動依賴解析。
• 場景：遺留Python 2項目維護，多解釋器版本測試。

# 安裝virtualenv   
pip install virtualenv      
# 創建虛擬環境   
virtualenv myenv      
# 激活虛擬環境   
# Windows   
myenv\Scripts\activate   
# macOS/Linux   
source myenv/bin/activate      
# 退出虛擬環境   
deactivate

2. venv（Python3.3，2012）

python自帶的虛擬環境管理，簡單是它的優勢，也是它的劣勢。
只能創建虛擬環境，不能指定系統不存在的python環境版本，不能管理系統中的環境列表（例如選擇一個已經創建好了的虛擬環境）。
venv的虛擬環境默認是存放在項目文件夾里的，這會影響項目文件的管理。

• 定位：Python 3.3+內置的輕量級環境隔離
• 功能：創建隔離的 Python 環境，依賴 pip 手動管理包。
• 優點：開箱即用，無額外依賴，目錄結構清晰。兼容性好，與"pip"無縫集成。
• 缺點：無依賴解析能力，需手動維護 requirements.txt。無法創建非系統Python版本環境 ，不支持多 Python 版本切換。
• 場景：快速驗證代碼或小型項目。如果你只需要基本的虛擬環境功能，"venv"是最輕量、最直接的選擇。

# 創建虛擬環境   
python -m venv myenv      
# 激活虛擬環境   
# Windows   
myenv\Scripts\activate   
# macOS/Linux   
source myenv/bin/activate      
# 退出虛擬環境   
deactivate

三、版本管理工具

1. pyenv（社區開發，2014）

pyenv GitHub

Pyenv 讓開發者可以在多個 Python 版本之間輕松切換，解決了 venv 不能創建不同 Python 版本虛擬環境的限制。
Pyenv 支持在不同項目中切換 Python 版本。
但是，開發者有時會濫用 pyenv 設置全局的 Python 版本，導致項目之間的 Python 版本混亂，影響項目的復用和開發環境的穩定。
Pyenv 的理念很簡單，秉承了 UNIX 哲學中單一用途工具的傳統，它源自于 rbenv 和 ruby-build，并專門為 Python 進行了修改和適配。
與同類工具不同，pyenv 完全由純 Shell 腳本實現，不依賴 Python，無需擔心 Python 引導問題。
Pyenv 通過修改操作系統的 PATH 環境變量，可不同 Python 版本之間切換，并能同時運行多個 Python 版本的命令，在不同 Python 環境下進行測試和開發時特別實用。
pyenv 主要用于切換 Python 版本，并不直接管理虛擬環境。不過，可以結合 pyenv 與 virtualenv 命令，或使用 pyenv-virtualenv 插件管理虛擬環境。

pyenv Github

• 定位：純Python版本管理工具（非依賴管理）。 主要用于管理多個 Python 版本，而不是直接管理包，但它可以用來設置特定版本的 Python 環境，進而使用其他包管理工具。
• 優點：支持多版本無縫切換，解決“我本地是Python 3.10，服務器是3.8”的經典問題。
• 缺點：需配合venv/pipenv等使用，Windows支持較弱。
• 場景：需同時維護多個Python版本的項目。

四、項目管理工具：依賴+環境+打包三位一體

1. Pipenv（Kenneth Reitz，2017）

pipenv GitHub

requests庫作者Kenneth Reitz大神的作品。但pipenv并不穩定，例如，如果你運行pip install…兩次，結果可能不一樣，pipenv曾承諾解決這個問題，但實際上，它只是多次嘗試運行pip install <單個包>，直到結果看起來差不多符合規范。顯然，這樣的方式更慢，但最終問題依然存在。

• 定位：首次整合pip+virtualenv的革命性工具，引入Pipfile和Pipfile.lock管理依賴。 Python 官方曾推薦的依賴管理工具。
• 功能：自動創建虛擬環境 + 依賴管理（Pipfile 和 Pipfile.lock）。解決依賴版本沖突。
• 優點：自動管理虛擬環境，.env文件支持，統一開發和生產環境依賴。依賴哈希校驗提升安全性。 替代傳統 requirements.txt。
• 缺點：依賴解析速度慢，大型項目體驗不佳。 社區活躍度下降（逐漸被 Poetry 取代）。
• 場景：中小型Web應用，追求開箱即用的團隊。
• 動態：2025版移除Python 3.8支持，優化依賴解析邏輯。

# 安裝pipenv   
pip install pipenv      
# 創建虛擬環境并安裝依賴   
pipenv install      
# 激活虛擬環境   
pipenv shell      
# 退出虛擬環境   
exit

2. Poetry（Sébastien Eustace，2018）：現代Python項目的全能選手

poetry GitHub

• 在uv出現前最好用的管理工具。
• poetry使用pyproject.toml和poetry.lock文件來管理依賴，類似于JavaScript/Node.js的Npm和Rust的Cargo，這倆都是非常成熟好用的依賴管理方案。
• poetry本身并不具有管理Python解釋器的功能，推薦和pyenv/pyenv-win使用，可以輕松下載和設置不同版本的Python解釋器。
• poetry的缺點可能是較為復雜，上手困難。由于poetry嚴格的依賴管理策略，你可能會在安裝依賴包時遇到更多的問題。
• 在國內，poetry還有另一個缺點，無法設置全局鏡像源，只可針對單個項目設置鏡像源。

Poetry 支持安裝和更新支持庫，提供鎖文件以確保項目的復用，并能構建項目分發包。
Poetry 需要 Python 3.8+，跨平臺支持 Linux、macOS 和 Windows。
Poetry 類似于 Cargo（Rust 的包管理器） 和 npm（Node.js 的包管理器），是 Python 生態系統中使用體驗與這兩個包最接近的工具。
類似于 Conda，Poetry 預先解析完整的依賴圖，并按拓撲順序安裝支持庫。
Poetry 依據 pyproject.toml 管理項目內外的虛擬環境。
poetry.lock 文件可以確保項目的復用，但體積較大。
此外，Poetry 還兼具構建工具功能，可以發布 Python 包。
Poetry 的解析速度較慢，部分是因為 Python 包聲明支持庫的方式不一致，可能會導致支持庫解析的時間較長。

• 定位：現代依賴管理 + 打包工具（開源庫開發首選）。全生命周期管理（依賴+打包+發布），基于pyproject.toml。
• 功能：一體化工具：集成了虛擬環境管理、依賴管理（pyproject.toml）和打包發布功能。
• 優點：語義化版本控制，動態依賴約束（如 ^1.2.3）。一體化工具鏈（開發到發布全流程）。一鍵發布PyPI，依賴樹可視化。
• 缺點：冷啟動解析較慢，自定義構建流程支持弱。 學習成本較高（需熟悉 pyproject.toml）。對舊項目遷移有一定成本。
• 場景：復雜項目、開源庫開發、追求現代工作流。

# 安裝poetry   
pip install poetry      
# 創建新項目   
poetry new myproject      
# 添加依賴   
poetry add requests      
# 進入虛擬環境   
poetry shell

3. PDM（Frost Ming，2020）

pdm GitHub

PDM 的目標是成為新生代 Python 支持庫管理工具。
與 Poetry 類似，PDM 也是一款快速的支持庫解析器，主要用于大型二進制文件分發。
它具備靈活強大的插件系統和多功能用戶腳本。
此外，PDM 還可以使用 indygreg 的 python-build-standalone 安裝 Python，并支持類似 pnpm 的集中式安裝緩存。
PDM 與 Poetry 的主要區別在于，PDM 支持 PEP-582，將虛擬環境集成到項目目錄中，避免了傳統虛擬環境的手動激活和停用，提高了開發效率。

• 定位：PEP 582標準實踐者，支持項目本地包目錄，無需虛擬環境。
• 優點：依賴解析快，避免環境激活，兼容pyproject.toml。
• 缺點：IDE支持需額外配置，非虛擬環境模式調試復雜。
• 場景：追求輕量化的微服務、工具鏈開發。

4. Rye（Astral，2023）

Rye GitHub

Rye 由 Astral.sh 開發，也是基于 Rust 構建的，旨在提升開發效率和用戶體驗。
與傳統的包管理工具相比，Rye 的性能有顯著提升，功能也更加豐富。
Rye 希望為 Python 開發者提供一站式的工具，讓 Python 支持庫的安裝與管理更加輕松。
Rye 使用與 uv 相同的支持庫解析器，提供更快的管理體驗。
Rye 還提供了與 poetry 類似的功能，但速度更快。

• 定位：Poetry的極速替代品，共享uv解析引擎

5. uv（Astral，2024）： Rust高性能工具鏈，新王登基

uv GitHub

• uv 是一個由 Astral 開發的高性能 Python 包管理和項目管理工具，用 Rust 編寫，旨在取代傳統的 Python 工具（如 pip、virtualenv、poetry、甚至部分 pyenv 功能）。它以極快的速度和現代化的設計著稱，號稱比 pip 快 10-100 倍，比 Poetry 快 2-10 倍。uv 的目標是提供一個統一的、一站式的 Python 開發體驗，涵蓋包安裝、虛擬環境管理、項目管理和 Python 版本管理。
• uv使用rust構建，uv的維護者astral還有另一個大名鼎鼎的python代碼格式化工具ruff，在使用ruff和uv時，你能明顯感覺到和其它基于python的工具的差距，指哪打哪，非常爽快。
• uv和poetry一樣使用pyproject.toml和lock文件管理依賴，很現代，用過的都說好。
• uv還同時管理python解釋器，也就是集成了pyenv的功能，可以方便地下載和管理解釋器。在python解釋器小版本更新時（例如3.12.0→3.12.1），uv也會自動更新，以后再也不用苦嘻嘻的去python官網找解釋器了。
• 將uv生成的項目拷貝到沒有python環境的電腦上，只需使用命令uv sync，uv會自動安裝python解釋器，并接著安裝pip依賴，如果使用uv run，uv還會在全部安裝妥當后，自動開始運行腳本。
• uv甚至還集成了pipx安裝python全局工具的功能，例如ruff、isort、mypy、pyright這類全局工具，可以使用uv tool安裝、升級和管理。
• 即便你是一個純粹的“pip”命令愛好者，uv也可以滿足你。uv提供了uv pip系列命令，可以同時具備rust的爽快和pip的學院派感覺，堪稱古典與現代的結合。
• 在最新的pycharm版本（2024.3.2或以上）里也添加了uv的支持，使用pycharm和uv管理項目甚至不需要寫命令行。

uv 也是 Astral.sh 出品的 Python 虛擬環境管理器，是當前備受期待的新生代包管理工具。
uv 的目標是取代 pip，同時具備與 Cargo 類似的功能。
uv 支持 Python 打包工具的所有特性，包括可編輯安裝、Git 依賴、URL 依賴、本地依賴、約束文件和源碼分發等。
Astral.sh 還開發了 Rust 生態中備受開發者喜愛的 ruff （用 Rust 開發的高性能 Python 代碼檢查和代碼格式化工具）。
與 poetry 類似，uv 通過 pyproject.toml 管理項目，得益于 Rust 的高效算法，其解析速度至少比 poetry 快一個量級。

• 定位：新一代高性能 Python 工具，Rust編寫的超高速一體化工具

• 功能：超高速包安裝與依賴解析（兼容 pip 和 pip-tools 工作流）。支持虛擬環境管理（類似 venv）。支持生成 requirements.txt 和 pyproject.toml。

• 性能對比（Jupyter項目）：

  工具	冷啟動時間	熱緩存時間
  pip	32.1s	28.7s
  Poetry	11.4s	9.2s
  uv	0.5s	0.02s

• 命令全景：

  uv pip install numpy          # 替代pip
  uv venv .env                  # 替代virtualenv
  uv python install 3.12        # 替代pyenv
  uv run main.py                # 替代poetry run
  

• 定位：Rust編寫的超高速一體化工具，覆蓋pyenv+venv+pip+poetry功能。

• 優點：

  • 速度：依賴解析比pip快100倍（Jupyter項目冷啟動500ms → 熱緩存20ms）
  • 全能：支持Python版本管理（uv python install）、依賴鎖定（uv lock）、腳本執行（uv run）
  • 安全：跨平臺鎖文件，哈希校驗防篡改
  • 跨平臺：支持Windows、macOS和Linux。

• 缺點：生態適配中，暫不支持非Python依賴（如Conda的C++庫）。

• 場景：所有純Python項目的首選替代方案，尤其適合CI/CD流水線。

# 安裝uv   
pip install uv      
# 創建虛擬環境   
uv venv myenv      
# 激活虛擬環境   
# Windows   
myenv\Scripts\activate   
# macOS/Linux   
source myenv/bin/activate      
# 退出虛擬環境   
deactivate

五、科學計算：非Python依賴管理

1. Conda（Anaconda團隊，2012）

conda GitHub

conda 和 Anaconda 是兩回事：

• conda 是包管理器（開源，BSD 許可證，仍然免費）。
• Anaconda 是一個商業公司提供的 Python 發行版，包括 conda、本地鏡像源、大量預裝包等。

從 2020 年起，Anaconda 公司對商業用途（如公司或機構）使用其官方發行版和鏡像源實行了收費政策：

• 個人用戶、開源項目、學術研究用途仍然免費。
• 企業用戶如果通過 Anaconda 鏡像或工具部署，需要購買許可證。

anaconda實在過于臃腫，它的安裝包里包括了眾多科學計算會用到的packages，安裝后動輒5-6個G。
anaconda有個不包含packages的版本，叫miniconda，但miniconda仍然存在安裝依賴庫過于激進的問題，安裝同樣的packages，conda總會比別的包管理器安裝更多的“依賴包”，即便有的“依賴包”并不是必須，這會導致你的項目出現不必要的膨脹。
同時，conda的packages列表“conda list”還存在和“pip list”不一致的問題。

Conda 是由 Anaconda 出品的命令行工具，用于在 Windows、macOS 和 Linux 上管理虛擬環境。
它不僅能管理 Python 支持庫，還能處理非 Python 支持庫，尤其針對數據科學方面的開發進行了優化。
Conda 使用自己的 Conda 虛擬環境切換非 Python 依賴項，無需使用復雜的 Docker。
與 Poetry 類似，Conda 在構建環境時執行完整的支持庫解析，其支持庫解析器 libmamba 是用 C++ 實現的，速度更快。

• 定位：跨語言包與環境管理（科學計算領域主流）。 （Python/R/CUDA）
• 功能：管理 Python 和非 Python 依賴（如 C/C++、R 庫）。自帶預編譯包（優化科學計算庫安裝）。
• 優點：跨平臺：支持Windows、macOS和Linux。一鍵安裝SciPy棧，支持Python/R/CUDA等混合依賴，預編譯加速科學庫安裝。
• 缺點：包更新滯后PyPI，虛擬環境切換慢。 環境體積臃腫（Miniconda>1GB） 。復雜依賴解析可能沖突。
• 場景：數據科學、機器學習、跨學科項目。

# 創建虛擬環境   
conda create -n myenv python=3.8      
# 激活虛擬環境   
conda activate myenv      
# 退出虛擬環境   
conda deactivate

2. Mamba（2019年）

mamba GitHub
是Conda的改進版，旨在解決Conda的痛點，如慢的依賴解析和并行下載問題，用 C++ 實現，使用不同算法，推薦安裝方式已改變。
速度比Conda 快很多，其他方面和Conda類似。

3. Miniforge（conda-forge社區，2020）

miniforge GitHub

• 定位：Conda輕量替代版，默認conda-forge源
• 場景：數據科學輕量化部署

4. Pixi（Prefix.dev團隊，2024）

pixi GitHub

Pixi 是基于 Rust 的 rattler 庫開發的，具有顯著的性能和安全優勢。
它的理念是提供類似于 cargo 或 yarn 的開發體驗。
Pixi 目標是直接取代 Conda，并能像 Conda 一樣管理非 Python 依賴項。
2024 年 2 月，為了追求更快的速度，Pixi 將后臺的 rip 改為 uv。
與 Conda 和 mamba 不同，Pixi 提供了自定義類型的鎖文件，使其在復用方面領先于 Conda。
Pixi 支持可復用的方式安裝支持庫，并支持 Python、C++ 和 R 等多種語言， 且兼容所有主流操作系統。
Pixi 還提供了簡潔而強大的命令行界面，使得支持庫管理更加簡單、高效。

• 定位：Conda的現代替代品，基于Rust構建。 ，支持pyproject.toml
• 優點：兼容Conda庫且解析更快，支持pyproject.toml。 混合管理PyPI和Conda包，解析速度提升5倍
• 缺點：社區包覆蓋不全。
• 場景：需混合PyPI和Conda包的跨語言工程。

六、依賴管理工具：專治版本混亂

1. pip-tools（Vincent Driessen團隊，2013）

pip-tools GitHub

• 定位：生產級精準依賴鎖定
• 核心命令：
  • pip-compile：從.in文件生成帶哈希的requirements.txt
  • pip-sync：嚴格同步環境至鎖定狀態
• 場景：Docker鏡像構建，生產服務器部署

2. pipreqs（社區，2016）

pipreqs GitHub

• 定位：基于項目import語句生成純凈requirements.txt。
• 神技：pipreqs /project --ignore node_modules --encoding=utf8
• 優點：自動忽略虛擬環境目錄，支持--ignore排除無關路徑。
• 缺點：無法識別動態導入（如__import__('os')）。
• 場景：從遺留項目重構依賴，生成最小化生產環境清單。

3. pigar（社區，2018）

pigar GitHub

• 定位：AST解析依賴，標注依賴在代碼中的位置。
• 優點：精確識別跨版本標準庫（如Py2的futures vs Py3的concurrent.futures）。
• 缺點：輸出文件含位置注釋，需手動清理后部署。
• 場景：審計依賴來源，解決“這個包到底在哪用？”的靈魂拷問。

# 輸出帶代碼位置注釋的requirements.txt
$ pigar -p /project -o requirements.txt

4. pipdeptree（社區，2015）

pipdeptree GitHub

• 定位：可視化依賴樹與沖突檢測。
• 優點：提示循環依賴，生成沖突報告（如pkgA需要numpy<2.0，pkgB需要numpy>=2.0）。
• 缺點：需在每個虛擬環境中單獨安裝。
• 場景：診斷依賴沖突，架構治理。

# 檢測沖突示例
$ pipdeptree --warn conflict | grep "version conflict"

---

七、終極對比表：13款工具全景圖

工具	作者/團隊	發布時間	定位	環境隔離	Python版本安裝	依賴聲明文件	依賴解析器復雜度	鎖文件生成	跨平臺鎖文件	非Python依賴管理	pyproject.toml原生支持	包構建	包發布	CLI工具安裝	Monorepo支持	實現語言	主要缺點	典型適用場景
pip	Python官方	2008	基礎包安裝器	?	?	requirements.txt	低（無沖突解決）	?	?	?	??部分支持	?	?	?	?	Python	無依賴解析、無環境隔離	臨時安裝/底層引擎
virtualenv	Ian Bicking	2007	跨版本環境隔離	?	?	無	無	?	?	?	?	?	?	?	?	Python	無依賴管理功能，需配合pip	Python 2兼容/多解釋器測試
venv	Python官方	2012	輕量級環境隔離	?	?	無	無	?	?	?	?	?	?	?	?	Python	無法管理Python版本	Python 3小型項目快速隔離
pyenv	Yasushi Saito	2010	解釋器版本管理	?	?	無	無	?	?	?	?	?	?	?	?	Bash/Python	無依賴管理功能	多Python版本切換
pipenv	Kenneth Reitz	2017	環境+依賴整合	?	?	Pipfile	中（速度慢）	Pipfile.lock	?	?	?	?	?	?	?	Python	依賴解析不穩定，鎖文件偶發不一致	中小型Web應用
poetry	Sébastien Eustace	2019	全生命周期管理	?	?	pyproject.toml	高（嚴格策略）	poetry.lock	?	?	?	?	?	?	??基礎	Python	冷啟動慢，國內鏡像需逐項目設置	開源庫開發/復雜依賴項目
pdm	Frost Ming	2020	PEP 582項目本地包目錄	??（可選）	?	pyproject.toml	高	pdm.lock	?	?	?	?	?	?	??基礎	Python	IDE需手動配置解釋器路徑	微服務/CLI工具開發
rye	Armin Ronacher	2023	極速Poetry替代品	?	?	pyproject.toml	極高（Rust引擎）	requirements.lock	?	?	?	?	?	?	?	Rust	較新，生態適配中	追求速度的現代項目
uv	Astral	2024	超高速一體化工具鏈	?	?	pyproject.toml	極高（Rust引擎）	uv.lock	?	?	?	?	?	? (uv tool)	?	Rust	不支持非Python依賴（如C++庫）	所有純Python項目
conda	Anaconda	2012	科學計算生態	?	?	environment.yml	中（跨語言解析）	無標準鎖文件	?	?	??部分支持	??有限	??有限	?	?	Python	環境臃腫，包更新滯后PyPI	數據科學/AI工程
mamba	QuantStack	2019	Conda加速版	?	?	environment.yml	高（C++引擎）	無標準鎖文件	?	?	??部分支持	??有限	??有限	?	?	C++	命令行兼容性偶有問題	大型科學計算項目
Miniforge	conda-forge社區	2020	Conda輕量版	?	?	environment.yml	中	無標準鎖文件	?	?	??部分支持	??有限	??有限	?	?	Python	社區包覆蓋不全	數據科學輕量化部署
pixi	前綴樹科技	2024	Conda現代化替代	?	?	pyproject.toml	高（Rust引擎）	pixi.lock	?	?	?	?	?	?	?	Rust	社區包覆蓋不全	跨語言科學計算

---

八、依賴管理工具時間簡史

0. 2000年，setuptools

Python2自2000年發布以來，語言尚未完全穩定和成型，最開始通過easy_install（2004 年發布，屬于 setuptools 的一部分）從PyPI（2003 年上線）安裝.egg格式的包。

1. 2008年，pip+virtualenv

2008年，為了解決Python2中的一些設計缺陷和向后不兼容的問題，發布Python 3.0。隨著社區的建設，PyPI的庫越來越多，python官方發布了包管理工具pip用于從PyPI安裝庫，同樣的，python的版本也在增多，不同版本之間庫版本兼容不同，pip本身只是給全局環境直接安裝一套一樣的依賴，如果有兩個項目依賴于同一個庫的不同版本，你是不可能同時在全局環境里把這兩個版本都裝上的。為了避免沖突，最好是給每個項目都有一套獨立的 pip 環境，分別安裝各自需要的依賴，這個就是虛擬環境，第三方庫率先發布了virtualenv實現環境管理。

2. 2012年，venv

此時，包管理和環境管理工具為pip+virtualenv。2012年，Python3.3發布，內置了環境管理工具venv，內置的更高效和方便，就替代了virtualenv。你用 PyCharm 創建項目時，默認會用 venv 建一個虛擬環境，也就是你看到的 venv 文件夾，就是為了讓每個項目都有獨立的依賴，避免沖突。

3. 2013年，pip-tools

venv 在簡單的場景下大概足夠了，你也可以直接進入虛擬環境導出 requirements.txt 或手寫個 pyproject.toml 來聲明依賴。但是你可能不太喜歡這種完全“手動擋”的模式，而是希望有一些更加方便的工具，可以讓你直接輸入一個 xxx-tool install 命令就直接檢測項目目錄下的 requirements.txt 或 pyproject.toml，利用里邊寫明的依賴自動生成一個虛擬環境，如果已經有虛擬環境就安裝缺少的庫/移除不再需要的庫，然后使用 xxx-tool add lib1 這種命令就能自動更新 requirements.txt 或 pyproject.toml并自動在虛擬環境中安裝 lib1。
于是2013年，社區發布了pip-tools，它提供兩個命令：pip-compile 用于生成和操作依賴清單（requirements.txt，注意這個 requirements.txt 和 Python 舊標準中的同名文件所功能不一樣，在 pip-tools 中它更類似于一個 lockfile），pip-sync 用于根據依賴清單將其內容與當前虛擬環境同步。但是 pip-tools 本身不會做更多事情了，它只聚焦于提供這兩個命令——如果你需要添加/刪除一個包或將某個包更新到與原本不兼容的版本，你需要先操作 pyproject.toml、使用 pip-compile 重新生成 requirements.txt，然后再用 pip-sync 同步進去。pip-tools 本身也只是同步當前的 pip 環境，不關心虛擬環境的事情，如果你要與 venv 一起使用，得先激活 venv 在里邊操作 pip-tools 才行。

4. 2014年，pyenv

隨著python版本的更新，越來越多的開發者需要同時在不同的python版本下工作，手動切換總是很麻煩。社區在2014年發布了pyenv，pyenv 是一個純Python版本管理工具（非依賴管理），pyenv 完全由純 Shell 腳本實現，不依賴 Python。 主要用于管理多個 Python 版本，而不是直接管理包，但它可以用來設置特定版本的 Python 環境，進而使用其他包管理工具。

5. 2017年，pipenv

目前開發工具集就是pip+venv+pip-tools+pyenv，雖然解決了需求，但是實際操作起來還是很麻煩。更復雜的是當你試圖編寫一個庫并發布到 PyPI 的時候——此時你需要一個構建工具、一個打包工具和一個負責把包發布到 PyPI 的工具。如果你需要一套標準流程，全部利用 Python 文檔中推薦的東西大概需要結合 setuptools + python -m build + Twine（分別負責構建、打包和發布到 PyPI）。
此時迫切的需要一個新的工具把這一連串的流程全打通，2017年，requests庫的作者Kenneth Reitz大神出品了pipenv，首次整合pip+virtualenv的革命性工具，引入Pipfile和Pipfile.lock管理依賴。 Python 官方曾推薦的依賴管理工具。

6. 2018年，poetry

但pipenv并不穩定，2018年，社區發布了poetry，這是最早可用的現代化項目管理工具，基于pyproject.toml，進行全生命周期管理（依賴+打包+發布），是開源庫開發的首選。

7. 2020年，PDM

Poetry 的問題首先在于它并不完全符合標準，典型的如它默認的 pyproject.toml 格式不符合 PEP 621（盡管目前已有實驗性支持）——因為 Poetry 的出現比 PEP 621 更早，自然不能未卜先知。另一個問題在于 Poetry 在解析依賴上的性能不盡如人意，一個 poetry add 常常需要花幾十秒時間，這顯然不夠理想。
所以自然出現了“更符合標準”的工具，2020年，社區推出了PEP 582標準實踐者PDM。

8. 2023年，Rye

這些工具各有各的特點，也各有各的問題。首先是這些工具作為針對單個項目的依賴管理工具與構建工具，本身并不管理 Python 本身——許多用戶是有客觀的同時使用多個版本 Python 的需求的，有些人會用 pyenv 編譯安裝多個版本的 Python，有些人直接用包管理器切換 shims，有些人則直接使用 Conda——這個需求顯然是這些項目管理工具做不到的；其次是工具安裝的問題，有時我們會需要用 pip 安裝一些命令行工具，比如 black 和 ruff，但直接使用 pip 安裝到全局環境中很容易產生依賴沖突，也會污染全局依賴，所以有了 pipx 這樣的項目用于為每個工具創建單獨的隔離虛擬環境。
所以我們看到至少還有兩個需求，即 pyenv 與 pipx 的任務可以進一步整合進來。2023年，Astral.sh大神發布了基于Rust的Rye，它不僅整合了 Poetry 的功能，也可以像 pyenv 或 Conda 一樣在你的機器上管理多個 Python 版本、像 pipx 一樣以隔離環境安裝工具，也整合了 ruff 作為開箱即用的 Linter 和 Formatter，對 pytest 也提供了支持。Rye 實際上不像 Poetry/Hatch/PDM 一樣實現了自己的依賴解析系統和構建后端，而只是將各種工具（uv/pip-tools、Hatchling、build、Twine 等）整合到一起，讓它們能夠協同工作，更近似一個“前端”項目。

9. 2024年，uv

由于pip的速度較慢，Astral.sh于2024年2月發布了uv，一開始只是一個更快的包安裝工具和依賴解析工具，用 Rust 編寫，旨在作為 pip 和 pip-tools 性能更好的替代品。在發布之后Rye于同月把包管理由pip替換為了uv。
后來，rye的初始作者最近把項目移交給uv團隊了, 相當于兩個項目合并。在 0.3.0 (2024/08) 加入了 python 環境管理和項目管理。到現在，已經完全可以用uv替代Rye了。

至此，python的依賴管理工具終于迎來了短暫的終局，以后隨著python的發展和社區的發展，可能會繼續出現新的劃時代的工具

10. 科學計算

科學計算環境下，由于需要用到各種語言的庫，是一個單獨的領域，就統一說一下。

• 2012年，Conda/miniconda，跨語言包與環境管理（Python/R/CUDA）
• 2020年，Anaconda 收費后，conda-forge社區發布了Miniforge
• 2019年，Mamba，作為Conda的輕量級替代品
• 2024年，pixi，Conda的現代替代品，基于Rust構建。

九、2025年工具選型黃金法則

1. 初學者或簡單項目：先拿pip+venv練手，掌握基本原理
2. 庫開發者：堅持 Poetry（生態最成熟，PyPI發布無縫銜接）
3. 數據科學： 傳統是Conda，非Python依賴（如CUDA、MKL）必須靠它。 如果同時使用PyPI庫和團隊協作就用Pixi
4. Python2舊項目：Virtualenv管理環境，uv管理庫，
5. 重構舊項目：用pipreqs+pipdeptree，先精準分析依賴，再解決沖突
6. 其他：一律推薦uv，無論腳本還是工程，Rust工具鏈的速度與體驗碾壓傳統方案。

后記

未來趨勢預測

1. Rust工具鏈統治：uv安裝量已占PyPI流量25%（2025數據），Rye/Pixi等Rust工具將逐步取代Python實現工具。
2. 標準趨同：pyproject.toml成為依賴聲明事實標準（Poetry/PDM/UV/Rye/Pixi均已支持）。
3. AI輔助依賴協商：GPT-DependencySolver等工具將自動解決版本沖突（實驗階段）。
4. 容器化融合：uv run已支持直接啟動隔離容器環境，未來工具鏈將深度整合Docker。

---

官網聚合

pypa Github
pip GitHub
virtualenv GitHub
pyenv GitHub
pipenv GitHub
poetry GitHub
pdm GitHub
Rye GitHub
uv GitHub
conda GitHub
mamba GitHub
miniforge GitHub
pixi GitHub
pip-tools GitHub
pipreqs GitHub
pigar GitHub
pipdeptree GitHub

---

參考文獻

Python環境管理大比拼：venv、Virtualenv、Conda、Pipenv、Poetry、UV，如何選擇，全在這里了？
Python虛擬環境和包管理，到底怎么選？
pip、venv、pipenv、poetry、conda、uv的區別
好學編程：11款Python虛擬環境管理器詳細攻略，總有一款適合你！
從混沌到秩序：Python的依賴管理工具分析
寫 Python 時，你是會選擇 venv、Conda、Poetry 還是 Rye ？
rye 與 uv 的功能演化概述
Python環境管理大比拼：pip、Conda、Pyenv、Rye、Virtualenv、PDM、Poetry等工具

---

喜歡的點個關注吧><！祝你永無bug~

/*_ooOoo_o8888888o88" . "88(| -_- |)O\  =  /O____/`---'\____.'  \\|     |//  `./  \\|||  :  |||//  \/  _||||| -:- |||||-  \|   | \\\  -  /// |   || \_|  ''\---/''  |   |\  .-\__  `-`  ___/-. /___`. .'  /--.--\  `. . __."" '<  `.___\_<|>_/___.'  >'"".| | :  `- \`.;`\ _ /`;.`/ - ` : | |\  \ `-.   \_ __\ /__ _/   .-` /  /
======`-.____`-.___\_____/___.-`____.-'======`=---='
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^佛祖保佑       永無BUG
*/