國(guó)內(nèi)Python圈子里一說(shuō)“建虛擬環(huán)境”好像人人都會(huì)但細(xì)問(wèn)起來(lái)十個(gè)里有八個(gè)說(shuō)不清venv、virtualenv、conda、poetry之間到底什么關(guān)系。我見(jiàn)過(guò)不少人在一個(gè)項(xiàng)目里同時(shí)裝了三套方案最后被各種環(huán)境變量和解釋器路徑折騰到重裝系統(tǒng)也有人為了跑個(gè)腳本硬是把 Anaconda 全家桶裝到公司服務(wù)器上占了好幾個(gè)G的空間。這篇就把幾種主流方式放在一起做個(gè)橫向?qū)Ρ戎v清楚它們到底在解決什么問(wèn)題、底層邏輯有什么不同、什么場(chǎng)景下該用哪個(gè)順便把我踩過(guò)的一些坑一并說(shuō)了。先說(shuō)結(jié)論放這兒虛擬環(huán)境本質(zhì)上是“隔離依賴”但不同工具的隔離粒度、依賴解析策略和工程化能力完全不同。選錯(cuò)工具后面維護(hù)起來(lái)會(huì)非常痛苦。1. 先搞清楚虛擬環(huán)境到底在解決什么問(wèn)題很多人第一次對(duì)虛擬環(huán)境“痛徹心扉”地理解往往不是因?yàn)閯?chuàng)建環(huán)境本身而是因?yàn)椤安唤ōh(huán)境”導(dǎo)致的連鎖災(zāi)難。1.1 大多數(shù)人踩過(guò)的“裸裝包”陷阱想象一下這個(gè)場(chǎng)景你在一臺(tái)電腦上同時(shí)維護(hù)兩個(gè)業(yè)務(wù)項(xiàng)目項(xiàng)目A是給別人做數(shù)據(jù)報(bào)表依賴Django 3.2項(xiàng)目B是內(nèi)部運(yùn)營(yíng)后臺(tái)架構(gòu)升級(jí)到了Django 5.0。如果兩個(gè)項(xiàng)目都在全局 Python 環(huán)境里pip install那么后裝的那個(gè)版本會(huì)把之前的覆蓋掉。表面上看 pip 只是更新了幾個(gè)包實(shí)際上項(xiàng)目A可能因?yàn)榇蟀姹旧?jí)直接跑不起來(lái)模板標(biāo)簽語(yǔ)法變了、某些 ORM 查詢寫法廢棄了甚至數(shù)據(jù)庫(kù)遷移文件都需要重新生成。更難受的是權(quán)限問(wèn)題。很多公司服務(wù)器上的 Python 是系統(tǒng)自帶的全局安裝經(jīng)常會(huì)遇到PermissionError你被迫在前面加sudo裝了之后系統(tǒng)組件可能讀寫到不干凈的包。等到你發(fā)現(xiàn)yum或apt這種操作系統(tǒng)包管理工具莫名其妙出問(wèn)題時(shí)通常就是全局 Python 的site-packages里混入了不該有的東西。我自己還碰過(guò)另一個(gè)隱蔽的坑卸載依賴時(shí)誤刪系統(tǒng)包。有個(gè)同事寫了個(gè)清理腳本直接在全局環(huán)境執(zhí)行pip freeze然后批量卸載不認(rèn)識(shí)的包結(jié)果把系統(tǒng)層依賴的一個(gè)庫(kù)給卸了最終只好重裝操作系統(tǒng)。這些混亂的根源就是“所有項(xiàng)目共用一套 Python 環(huán)境和同一套第三方庫(kù)”。虛擬環(huán)境的出現(xiàn)就是要把這種“通用性”變成“項(xiàng)目隔離性”。1.2 虛擬環(huán)境的核心原理不是復(fù)制是隔離虛擬環(huán)境不是把 Python 解釋器完整復(fù)制一份到項(xiàng)目目錄而是通過(guò)目錄結(jié)構(gòu)和環(huán)境變量做“視圖隔離”。以最經(jīng)典的venv為例你執(zhí)行python3 -m venv .venv它會(huì)生成一個(gè).venv目錄里面包含bin在 Windows 上是Scripts、lib、include等子目錄。這個(gè)目錄里有一個(gè)指向系統(tǒng) Python 的軟鏈接或拷貝版的解釋器同時(shí)lib/python3.x/site-packages是全新的空目錄。當(dāng)你執(zhí)行source .venv/bin/activate它做的事情本質(zhì)上是把.venv/bin放到PATH的最前面并設(shè)置VIRTUAL_ENV環(huán)境變量。這時(shí)你敲python實(shí)際執(zhí)行的就是.venv/bin/python而sys.path也被引導(dǎo)到當(dāng)前虛擬環(huán)境的site-packages而不是全局的。關(guān)鍵在于它沒(méi)有“復(fù)制”一套完整的 Python 解釋器只是“切換了查找路徑”?？梢赃@樣理解全局環(huán)境是你家小區(qū)門口的公共快遞柜所有住戶共用一個(gè)柜子誰(shuí)都能取走或放錯(cuò)別人的快件虛擬環(huán)境是你給自己家門后裝了一個(gè)小置物架快遞到了先用你門口的架子放只有你自己用。雖然你住的還是同一棟樓但取件流程被隔離開(kāi)來(lái)。這種輕量隔離是venv和virtualenv這類方案的核心根基。2. 主流方案全景對(duì)比建環(huán)境只是入口管理依賴才是分水嶺用一句話概括venv、virtualenv、conda、pipenv、poetry、uv這些工具雖然都叫“虛擬環(huán)境方案”但它們的定位完全不同。venv是標(biāo)準(zhǔn)庫(kù)自帶的最小隔離方案conda是重型的獨(dú)立環(huán)境方案而poetry和uv實(shí)際上已經(jīng)跨越到“依賴工程化”的層面環(huán)境管理只是其中一環(huán)。2.1 venv標(biāo)準(zhǔn)庫(kù)自帶最樸素的入門方案venv是 Python 3.3 之后官方推薦的方案零依賴隨解釋器一起提供。創(chuàng)建一個(gè)環(huán)境python3 -m venv myenv source myenv/bin/activate pip install requests deactivate它的優(yōu)勢(shì)非常明顯任何時(shí)候、任何一臺(tái)能跑 Python 3 的機(jī)器上你不需要額外安裝任何東西就能建出隔離環(huán)境。這對(duì)容器化部署、CI 流程、新手入門都非常友好。但它的問(wèn)題同樣明顯。第一venv本身不幫你做依賴解析和鎖定。你在環(huán)境里pip install某個(gè)包它只會(huì)裝最新版不會(huì)自動(dòng)生成“完整到哈希級(jí)別”的鎖定文件。就算你手動(dòng)用pip freeze requirements.txt導(dǎo)出依賴這份文件里只包含“當(dāng)前環(huán)境中所有包”的列表并不區(qū)分“直接依賴”和“間接依賴”。換一臺(tái)機(jī)器恢復(fù)環(huán)境時(shí)很可能因?yàn)槟硞€(gè)傳遞依賴的版本變動(dòng)而產(chǎn)生兼容問(wèn)題。第二venv默認(rèn)無(wú)法跨 Python 版本創(chuàng)建你的項(xiàng)目要用 Python 3.8但機(jī)器上默認(rèn)python3是 3.11你直接python3 -m venv建出來(lái)的環(huán)境就是 3.11。要解決這個(gè)你需要依賴pyenv或手動(dòng)切換解釋器路徑。所以venv適合“項(xiàng)目對(duì) Python 版本沒(méi)特殊要求對(duì)依賴鎖定沒(méi)那么敏感”的場(chǎng)景。2.2 virtualenv老牌增強(qiáng)版適用于多版本場(chǎng)景virtualenv比venv更老在 Python 3.3 之前是江湖主力即便今天很多場(chǎng)景下它仍然是比venv更順手的工具pip install virtualenv virtualenv -p python3.8 myenv source myenv/bin/activate它彌補(bǔ)了venv的最大短板——顯式指定 Python 版本。當(dāng)你機(jī)器上裝了多個(gè) Python比如 3.8、3.10、3.11virtualenv可以通過(guò)-p參數(shù)精確選擇解釋器。另外對(duì)于 Python 2 時(shí)代的遺留項(xiàng)目virtualenv幾乎是唯一選擇因?yàn)関env根本不支持 Python 2。從隔離機(jī)制上看virtualenv和venv幾乎一致都是通過(guò)bin/pythonsite-packages做路徑切換。不過(guò)virtualenv內(nèi)部還允許--copies參數(shù)強(qiáng)制用復(fù)制而不是軟鏈接這在某些不支持軟鏈接的文件系統(tǒng)比如 Docker 的部分掛載卷、某些網(wǎng)絡(luò)存儲(chǔ)上非常關(guān)鍵。如果你只是日常寫 Python 代碼venv和virtualenv的使用體驗(yàn)差異很小但如果要維護(hù)多版本環(huán)境virtualenv的-p參數(shù)真能救命。2.3 conda連編譯庫(kù)一起隔離的“復(fù)雜依賴”方案conda是另一條路線。它來(lái)自于數(shù)據(jù)科學(xué)生態(tài)和pip venv的理念完全不同。它不依賴系統(tǒng) Python而是自己管理一個(gè)獨(dú)立的軟件包分發(fā)系統(tǒng)conda create -n myenv python3.10 numpy pandas conda activate myenv關(guān)鍵區(qū)別在于conda不僅隔離 Python 包還能隔離非 Python 的二進(jìn)制依賴比如libssl、hdf5、cuda-toolkit、mkl這類底層的 C/C 庫(kù)。做機(jī)器學(xué)習(xí)或者科學(xué)計(jì)算的人一定深有體會(huì)某些包要跑起來(lái)光有pip依賴還不夠還得有匹配的底層庫(kù)。用venv建環(huán)境時(shí)你只能把 Python 包隔離了但底層二進(jìn)制庫(kù)仍然從系統(tǒng)共享用conda create建環(huán)境它會(huì)把你需要的整個(gè)軟件棧都拉到一個(gè)目錄里自包含。這種“全棧隔離”是conda最大的優(yōu)勢(shì)同時(shí)也是它最大的包袱。一個(gè)稍微完整一點(diǎn)的 conda 環(huán)境體積輕松超過(guò) 3~5 GB創(chuàng)建時(shí)還極慢因?yàn)橐馕霾煌?channel 之間的依賴關(guān)系。日常 Web 開(kāi)發(fā)用conda屬于典型的殺雞用牛刀。2.4 pipenv、poetry、uv從環(huán)境管理走向工程管理這三類工具出現(xiàn)在venv之后都試圖解決“環(huán)境建好了依賴卻管不住”的問(wèn)題。pipenv當(dāng)年主打“Python 官方推薦的依賴管理工具”理念是結(jié)合Pipfile和Pipfile.lock把依賴鎖定精確到版本poetry更進(jìn)一步通過(guò)pyproject.toml管理項(xiàng)目元數(shù)據(jù)、依賴分組和發(fā)布配置uv則是用 Rust 實(shí)現(xiàn)的極速工具把 venv 創(chuàng)建、依賴解析、包安裝全部重做了一遍速度可以比pip快幾十倍。它們的核心差異在于引入“依賴解析器”和“鎖定文件”的概念poetry add requests不只是裝包還會(huì)分析依賴樹(shù)把所有間接依賴的精確版本寫入poetry.lock之后任何人用poetry install都能得到完全一樣的虛擬環(huán)境。uv的理念類似但速度和對(duì)現(xiàn)有requirements.txt的兼容性更友好。工具核心定位依賴鎖定能力環(huán)境隔離粒度典型使用場(chǎng)景venv標(biāo)準(zhǔn)環(huán)境隔離無(wú)需組合 pip freezePython 包解釋器路徑普通項(xiàng)目、容器、CIvirtualenv多版本環(huán)境隔離無(wú)同 venvPython 包解釋器路徑多 Python 版本并存conda全棧環(huán)境隔離conda 自身環(huán)境導(dǎo)出Python 包二進(jìn)制庫(kù)數(shù)據(jù)科學(xué)、機(jī)器學(xué)習(xí)pipenv依賴管理環(huán)境Pipfile.lockPython 包簡(jiǎn)單應(yīng)用項(xiàng)目poetry工程化依賴與發(fā)布poetry.lockPython 包開(kāi)源庫(kù)、中大型項(xiàng)目uv極速環(huán)境與依賴管理uv.lock / requirementsPython 包新項(xiàng)目、CI 提速、復(fù)雜工程3. 到底選哪個(gè)按項(xiàng)目形態(tài)對(duì)號(hào)入座工具沒(méi)有絕對(duì)好壞只有合不合適。幾年下來(lái)我基本是按照下面這套邏輯來(lái)選型。3.1 Web應(yīng)用與API服務(wù)推薦 venv requirements.txt / poetryWeb 項(xiàng)目通常是交付形態(tài)最明確的一個(gè)服務(wù)、一組明確的第三方依賴、一個(gè)啟動(dòng)命令。如果是快速原型或小型 API直接用python -m venv .venv創(chuàng)建環(huán)境配合requirements.txt就足夠。但一旦項(xiàng)目進(jìn)入迭代期依賴越來(lái)越多我強(qiáng)烈建議升級(jí)到poetry它能區(qū)分“運(yùn)行依賴”和“開(kāi)發(fā)依賴”比如pytest、black這類開(kāi)發(fā)工具不該出現(xiàn)在生產(chǎn)依賴?yán)飏equirements.txt做不到這種分組poetry的pyproject.toml可以。實(shí)際部署時(shí)用poetry export -f requirements.txt --output requirements.txt生成純pip格式的鎖定文件交給容器構(gòu)建既保留了工程化的鎖定能力又不要求線上鏡像必須安裝 poetry。這是我目前認(rèn)為最平滑的過(guò)渡路徑。3.2 數(shù)據(jù)科學(xué)與機(jī)器學(xué)習(xí)推薦 conda前提是能接受體積做機(jī)器學(xué)習(xí)尤其是涉及 GPU 訓(xùn)練或復(fù)雜數(shù)值計(jì)算時(shí)conda幾乎是避不開(kāi)的。numpy、pandas、scikit-learn本身還好但一旦牽涉到pytorch、tensorflow的 CUDA 相關(guān)依賴pip安裝經(jīng)常需要手動(dòng)折騰系統(tǒng)驅(qū)動(dòng)和LD_LIBRARY_PATH非常容易翻車。conda會(huì)把 CUDA 相關(guān)的二進(jìn)制庫(kù)也納入環(huán)境管理相當(dāng)于把你的訓(xùn)練環(huán)境做成一個(gè)完全獨(dú)立的“計(jì)算沙盒”。不過(guò)要注意conda環(huán)境別過(guò)度濫用。一個(gè)服務(wù)器上建幾十個(gè) conda 環(huán)境每個(gè)都裝python3.10加一堆基礎(chǔ)包磁盤和創(chuàng)建時(shí)間都會(huì)非常感人。我個(gè)人習(xí)慣是只把 conda 用于需要在 GPU 或復(fù)雜二進(jìn)制環(huán)境下跑的項(xiàng)目其他普通 Python 任務(wù)一律不用它。3.3 自動(dòng)化腳本與工具venv 就夠別再折騰寫爬蟲腳本、數(shù)據(jù)處理腳本、內(nèi)部運(yùn)維小工具時(shí)很多人容易陷入“工具選型炫技”的怪圈動(dòng)不動(dòng)就上conda或poetry。實(shí)際上這種場(chǎng)景就一個(gè)虛擬環(huán)境加上一個(gè)requirements.txt五秒建好腳本跑完環(huán)境刪掉也不心疼。要特別注意腳本運(yùn)行環(huán)境不固定的情況你在自己機(jī)器上建好虛擬環(huán)境同事拿去跑最穩(wěn)妥的做法是在腳本頭部加一段自動(dòng)創(chuàng)建 venv 的邏輯即“檢測(cè)到?jīng)]有.venv目錄就自動(dòng)執(zhí)行python -m venv .venv pip install -r requirements.txt”省得新同事看文檔靠猜。3.4 開(kāi)源庫(kù)與要發(fā)布的項(xiàng)目poetry 或 uv鎖定一切寫庫(kù)跟寫業(yè)務(wù)代碼完全兩碼事。庫(kù)意味著別人會(huì)安裝你的代碼你無(wú)法假設(shè)使用者的環(huán)境中已經(jīng)裝了哪些傳遞依賴同時(shí)你自己的開(kāi)發(fā)環(huán)境必須能對(duì) Python 的多個(gè)版本進(jìn)行矩陣測(cè)試。poetry在pyproject.toml中聲明依賴時(shí)可以明確寫python ^3.8還支持tool.poetry.dev-dependencies分組方便tox或nox這類工具做多版本驗(yàn)證。uv是更現(xiàn)代的選擇。它的解析速度極快還能直接管理 Python 版本本身uv python install 3.11測(cè)試多個(gè) Python 版本時(shí)不用再單獨(dú)折騰 pyenv。唯一要考慮的是團(tuán)隊(duì)熟悉度問(wèn)題畢竟poetry的生態(tài)和文檔更完整uv還在快速迭代期。4. 實(shí)操中的高頻坑與排查思路選哪個(gè)方案是戰(zhàn)略問(wèn)題踩坑是戰(zhàn)術(shù)問(wèn)題。以下這些坑我基本都親身經(jīng)歷過(guò)列出來(lái)當(dāng)速查表。4.1 激活了虛擬環(huán)境pip 卻還在全局裝包這個(gè)現(xiàn)象往往發(fā)生在“重復(fù)創(chuàng)建環(huán)境”之后。比如你先運(yùn)行了source .venv/bin/activate后來(lái)又進(jìn)入另一個(gè)目錄執(zhí)行deactivate但終端提示符上還是顯示舊的環(huán)境名。原因通常是虛擬環(huán)境的activate腳本和 pip 的路徑已經(jīng)緩存了舊位置。最直接的解決方法是which python和which pip確認(rèn)一下當(dāng)前使用的是不是環(huán)境內(nèi)的路徑如果不是就重新source一次新環(huán)境的activate。另外永遠(yuǎn)不要手動(dòng)改PYTHONPATH一旦你把它指向一某個(gè)site-packages所有虛擬環(huán)境都會(huì)受到污染。4.2 換目錄、換機(jī)器后虛擬環(huán)境失效虛擬環(huán)境內(nèi)部記錄的是創(chuàng)建時(shí)的絕對(duì)路徑。你把.venv整個(gè)目錄拷貝到另一臺(tái)機(jī)器或者項(xiàng)目移了個(gè)位置軟鏈接會(huì)斷掉。典型的報(bào)錯(cuò)就是bash: ./activate: No such file or directory或者執(zhí)行 Python 時(shí)提示找不到解釋器。應(yīng)對(duì)辦法有兩種如果你是換機(jī)器部署最干凈的做法是扔掉原.venv在新機(jī)器上重新創(chuàng)建并安裝依賴。如果你只是項(xiàng)目目錄整體移動(dòng)在路徑變化不大時(shí)可以嘗試編輯.venv/bin/activate里的VIRTUAL_ENV變量還有pyvenv.cfg里的home字段把它們改成新路徑。但說(shuō)實(shí)話這個(gè)操作很容易出錯(cuò)我一般直接重建。這也是為什么項(xiàng)目必須具備“快速重建環(huán)境”能力的原因依賴清單要能一鍵恢復(fù)環(huán)境。4.3 創(chuàng)建時(shí)選錯(cuò)了 Python 解釋器很多人venv建完才意識(shí)到環(huán)境里用的不是自己想要的那個(gè) Python。比如系統(tǒng)默認(rèn)python3是 3.11但你項(xiàng)目要跑 3.8 的代碼。這個(gè)問(wèn)題提前警覺(jué)可以用python3.8 -m venv .venv指定版本創(chuàng)建。想事后補(bǔ)救就干脆rm -rf .venv重建別嘗試去替換解釋器。這里還要提一個(gè)技巧建好環(huán)境后立刻檢查python --version和which python確認(rèn)路徑已經(jīng)指向.venv/bin/python再開(kāi)始裝包。這兩個(gè)命令一秒鐘的事能避免你后面排查半天。4.4 conda 環(huán)境中 pip 用了全局路徑conda activate myenv之后環(huán)境看起來(lái)是激活了但在環(huán)境內(nèi)輸入pip --version顯示的卻是/usr/bin/pip。這種情況多發(fā)生在沒(méi)有先初始化 shell 的環(huán)境里。新版 conda 要求你執(zhí)行conda init bash # 或 conda init zsh初始化完成后重新打開(kāi)終端activate才會(huì)正確修改 PATH 前綴。另一個(gè)規(guī)矩是在 conda 環(huán)境里裝包優(yōu)先用conda install只有當(dāng)包不在 conda channel 里時(shí)才用pip install?；煊玫臅r(shí)候先裝 conda 包再裝 pip 包避免 pip 覆蓋 conda 管理的二進(jìn)制庫(kù)。4.5 依賴鎖定文件與實(shí)際環(huán)境不一致pip freeze requirements.txt是最容易產(chǎn)生“偽鎖定”的命令因?yàn)槿绻h(huán)境里有一些調(diào)試時(shí)手動(dòng)裝的包它們也會(huì)被寫入文件而某些通過(guò)--no-deps方式安裝的包又不會(huì)帶入依賴。長(zhǎng)期維護(hù)的項(xiàng)目我更推薦用pipreqs掃描項(xiàng)目實(shí)際 import 的庫(kù)來(lái)生成依賴清單或者直接轉(zhuǎn)向poetry用poetry.lock做真鎖定。有個(gè)反直覺(jué)的技巧值得留意虛擬環(huán)境裝包時(shí)盡量避免用pip install -U pip升級(jí)pip本身。雖然升級(jí) pip 通常沒(méi)問(wèn)題但在極端情況下如果新版本 pip 對(duì)某些舊包解析邏輯變化會(huì)導(dǎo)致整個(gè)環(huán)境里的依賴樹(shù)亂掉。保持 pip 版本穩(wěn)定專注于業(yè)務(wù)依賴能少很多折騰。4.6 別忘了一件事先規(guī)劃 .gitignore不管用哪種方案虛擬環(huán)境目錄都不應(yīng)該提交進(jìn)版本庫(kù)。.venv、venv、env這類目錄名直接寫進(jìn).gitignore。conda環(huán)境通常創(chuàng)建在 conda 統(tǒng)一目錄下不存在這個(gè)問(wèn)題但poetry創(chuàng)建的虛擬環(huán)境一般在用戶目錄下的Cache目錄里也無(wú)需提交。只有鎖定文件如requirements.txt、poetry.lock、uv.lock必須提交因?yàn)檫@是他人重建環(huán)境的唯一依據(jù)。# 基礎(chǔ)忽略模板 .venv/ venv/ env/如果團(tuán)隊(duì)其他人拉取代碼后環(huán)境構(gòu)建失敗90% 的原因是鎖定文件沒(méi)有正常提交或者有人手改了鎖定文件但沒(méi)裝新依賴。鎖定文件一旦被修改執(zhí)行poetry install --sync或uv sync能把環(huán)境強(qiáng)制對(duì)齊回鎖定狀態(tài)這是比手動(dòng)逐個(gè)裝包高效得多的恢復(fù)方式。個(gè)人使用小結(jié)說(shuō)回我自己現(xiàn)在的選型原則特別簡(jiǎn)單寫小工具和腳本用venv我一個(gè)人基于最快的方式搞定寫業(yè)務(wù)應(yīng)用和開(kāi)源庫(kù)用poetry因?yàn)樗岩蕾嚪纸M、版本鎖定和發(fā)布流程都管起來(lái)了團(tuán)隊(duì)協(xié)作時(shí)非常省心做數(shù)據(jù)科學(xué)相關(guān)的工作還是會(huì)老老實(shí)實(shí)回到conda因?yàn)楹芏嗟讓訋?kù)的二進(jìn)制依賴真的只有它能理清。有一次我在一臺(tái)公用測(cè)試機(jī)上同時(shí)維護(hù)著三個(gè)環(huán)境一個(gè)venv環(huán)境跑運(yùn)維腳本一個(gè)poetry環(huán)境跑業(yè)務(wù)服務(wù)端一個(gè)conda環(huán)境做數(shù)據(jù)處理實(shí)驗(yàn)。三套方案共存完全沒(méi)問(wèn)題它們各自守好自己的依賴目錄互不干擾。真正出問(wèn)題的從來(lái)不是環(huán)境工具不夠強(qiáng)大而是沒(méi)有建立“環(huán)境內(nèi)依賴清單要完整、環(huán)境本身可隨時(shí)重建”這個(gè)意識(shí)。記住一個(gè)判斷標(biāo)準(zhǔn)如果你今天把.venv目錄刪除能靠一份文件和一條命令把它恢復(fù)到一模一樣的狀態(tài)那你的環(huán)境策略就基本合格了。