新電腦裝完 Python我干的第一件事不是去寫代碼而是先把虛擬環(huán)境這套東西給配齊。不是我有潔癖而是被環(huán)境折騰過的 Python 開發(fā)者心里都清楚手上的項目一多版本一亂遲早要翻車。這邊項目 A 需要老版本的爬蟲庫那邊項目 B 的框架撞車再加上某個項目對 Python 小版本還挑三揀四環(huán)境一旦混在一起光是排查ImportError就能浪費你一下午。所以虛擬環(huán)境這件事真的是 Python 開發(fā)避不開的第一課。這篇博客把 venv、conda 和 Python 版本選擇放在一起講透因為這三件事本身就是一環(huán)扣著一環(huán)的選錯 Python 版本后面建什么環(huán)境都是埋雷不會用虛擬環(huán)境版本隔離無從談起分不清 venv 和 conda 的邊界就容易在錯誤的方向上較勁。文章會從隔離原理講起把兩條主流路線的實操細節(jié)、踩坑點和選型策略都過一遍。剛入門沒幾天、還在給系統(tǒng) Python 亂裝包的新手可以看被多版本 Python 和依賴沖突搞到頭禿的老手也能找到一些可以直接落地的思路。1. 為什么需要虛擬環(huán)境先理解隔離的本質1.1 Python 環(huán)境混亂的典型慘案先講幾個我親眼見過、也親身踩過的例子。第一個場景你本地跑著一個個人博客項目用requests老版本寫死的邏輯后來接手一個同事的爬蟲項目里頭requests要求新版于是你pip install --upgrade requests博客項目立刻開始報奇奇怪怪的兼容錯誤。更麻煩的是你根本想不起來是哪些包被動過。第二個場景某開發(fā)者在服務器上直接用系統(tǒng) Python手上沒權限就用sudo pip install往全局塞包后來系統(tǒng)工具升級直接把某個關鍵依賴覆蓋成了不兼容的版本服務起不來運維查了半天才發(fā)現是 Python 全局環(huán)境被玩壞了。第三個場景發(fā)生在我自己身上要跑一個深度學習項目依賴里面有包只支持某個 Python 小版本我又舍不得把系統(tǒng)默認版本改掉結果每次運行前都要折騰PYTHONPATH和一堆環(huán)境變量最后還是全亂了。這三個案例指向同一個結論Python 包的默認安裝位置是全局的多個項目共用一份site-packages版本沖突是必然事件只是什么時候爆的問題。虛擬環(huán)境的價值就是給每個項目一個獨立的小地盤互不干擾。1.2 虛擬環(huán)境隔離了什么解釋器路徑、site-packages 與 PATH要搞清楚它是怎么做到的先理解 Python 在 import 一個模塊時到底去哪兒找包。解釋器會按照sys.path里的目錄逐個搜索通常就是標準庫路徑、site-packages還有環(huán)境變量PYTHONPATH里列的目錄。你裝一個第三方包默認就落進當前 Python 對應的site-packages里。全局 Python 的site-packages只有一個所有項目裝的包都堆在這里互相覆蓋就是分分鐘的事。venv 做的事可以拆成三塊。第一在新目錄里放一個指向目標 Python 解釋器的軟鏈接Windows 下通常是復制一份讓“當前 Python 是誰”變得可控第二在新環(huán)境里創(chuàng)建獨立的site-packages目錄讓新裝的包落在這里而不是全局目錄第三提供一個activate腳本修改 PATH 環(huán)境變量讓python和pip命令優(yōu)先找到虛擬環(huán)境里的那一份。激活之后你敲which python路徑已經變成.venv/bin/pythonpip裝的包自然就進到.venv/lib/python3.x/site-packages里了。不激活也行直接.venv/bin/python xxx.py效果一樣只是命令寫得麻煩點。conda 的隔離思路就不太一樣。它不僅僅管 Python 的包還會把 Python 解釋器本身、依賴的 C/C 庫、可執(zhí)行文件目錄、頭文件全部放進同一個“前綴目錄”里。一個 conda 環(huán)境就是一個相對完整的小系統(tǒng)bin/、lib/、include/各司其職。之前我用 conda 建環(huán)境的時候打開目錄看過里面不但有python還有一堆編譯鏈接庫。這種“環(huán)境即前綴”的思路決定了它能管理的東西遠超出純 Python 包的范圍。1.3 venv 與 conda 的隔離機制差異表面上 venv 和 conda 都在做環(huán)境隔離但底層不是一個物種。venv 是 Python 自帶的官方工具它不負責管 Python 本體。你用python3.10 -m venv建出來的環(huán)境里面的解釋器就是 3.10換個python3.11再建一個才能得到 3.11 的環(huán)境。它的隔離主要是給“同一個 Python 版本”的依賴提供獨立空間。如果你的需求只是兩個項目共用 Python 3.11 但依賴不同版本venv 非常合適輕量、快、干凈。conda 把 Python 本身也看成一個“包”。你可以在創(chuàng)建環(huán)境時直接指定python3.10conda 會從包倉庫里把對應版本的 Python 解釋器連同依賴一起裝進環(huán)境。如果項目需要 CUDA、MKL 這類非 Python 的底層庫conda 也能管因為它有自己的包格式和依賴求解器會把二進制層面的依賴一并解析好。付出的代價是環(huán)境體積大、命令操作更重、依賴求解經常要等。我用一句話總結兩者的邊界venv 解決的是“同一 Python 版本下的依賴打架”conda 解決的是“不同 Python 版本和不同底層庫之間的組合博弈”。前者像給每個房間換了把鎖后者像直接把整層樓按戶型分開裝修。2. Python 版本選擇從源頭避免兼容性噩夢2.1 版本號與 ABI為什么不能隨手拿最新版很多新手有個誤區(qū)Python 出新版本我直接裝上用最新的豈不是美滋滋等到某個包在安裝時報“找不到匹配版本”或編譯報錯時才意識到問題不簡單。這里有個關鍵概念叫 ABI應用二進制接口。CPython 每次大版本更新擴展模塊的二進制接口都可能變化。你自己import的純 Python 包沒問題但那些用 C/C 寫的擴展包尤其是打包成 wheel 的在安裝時會校驗平臺的 ABI 標志。你可以留意一下 wheel 包的文件名很多長這樣numpy-1.26.0-cp311-cp311-win_amd64.whl里面有cp311說明這個包預編譯產物只對 Python 3.11 生效。你把 Python 升到 3.12沒有對應的 wheel 就得現場拉源碼編譯如果系統(tǒng)還缺編譯工具鏈直接一堆紅色報錯。更麻煩的是很多大生態(tài)庫對新版本 Python 的支持是有滯后期的。深度學習的框架、科學計算類的重量級庫往往要等幾個月甚至大半年才跟進新的 Python 版本。盲目追新導致的結果就是你的代碼本身沒啥問題但環(huán)境湊不齊天天在裝依賴上耗時間。2.2 兩條多版本管理路線pyenv 與 conda既然不同項目需要不同的 Python 版本就得有人管住“系統(tǒng)里到底裝了哪些 Python”。這條路主要有兩個主流做法。第一種是 pyenv。它能在用戶目錄下編譯或下載多個 Python 版本然后用pyenv local、pyenv global之類命令切換。裝好之后你隨時可以pyenv install 3.10.13裝一個指定小版本再通過python3.10 -m venv .venv建立項目環(huán)境。pyenv 的優(yōu)勢是貼近原生 Python 的體驗但 Windows 上支持比較弱通常建議在 Linux/macOS 或 WSL 里用。第二種就是 conda。創(chuàng)建環(huán)境時直接指定 Python 版本比如conda create -n py311 python3.11conda 會去倉庫拉一個編譯好的 CPython 解釋器放進環(huán)境。好處是不同版本之間切換非常自然不需要額外工具壞處是它連 Python 解釋器都是“包”的思路整個體系比裸 Python 重。我個人的習慣是如果是純 Python 項目用 pyenv 管版本再用 venv 建環(huán)境如果項目涉及科學計算或底層庫直接 conda省心。2.3 選版本的實操策略版本這塊我踩過不少坑現在遵循一套自己的策略按優(yōu)先級排序先去查依賴庫的支持矩陣。項目里如果引用了比較重的第三方庫就直接去官方文檔看它支持的 Python 版本范圍。比如某個深度學習框架在某個時期只支持到 Python 3.10那新環(huán)境就別選 3.11選了就是自找麻煩。新項目不要盲目選最新發(fā)布版。一般選當前生態(tài)已經穩(wěn)定適配一年以上的版本比如現在 3.10、3.11、3.12 這類已經過了磨合期的版本都是穩(wěn)妥選擇除非你的依賴明確要求更高版本。老項目則完全以項目配置文件、CI 配置和依賴鎖定的requires-python為準別憑感覺升級。原則是能用 venv 解決的別拉 conda 進場需要 conda 管底層庫的就好好用 conda 從頭管到尾。這樣比“用 conda 建環(huán)境再用 pip 硬裝一切”要穩(wěn)定太多。3. venv 全流程實操從建環(huán)境到發(fā)布依賴3.1 創(chuàng)建、激活與退出命令背后的機制venv 的基本操作其實五分鐘就能學會但很多入門資料只教你敲命令不說背后的門道。我多看了一層所以踩坑少一些。創(chuàng)建環(huán)境# 進入項目目錄后執(zhí)行 python -m venv .venv這里有個小細節(jié)值得說命令里的python是你當前默認的 Python 版本。如果系統(tǒng)里同時裝了 3.10 和 3.11你想建 3.10 的環(huán)境最好用python3.10 -m venv .venv。別想著先建了再升級venv 沒有自動換解釋器的能力--upgrade只能在同一大版本里打補丁建錯版本刪掉重來最干凈。激活環(huán)境# Unix / macOS / Linux 下 source .venv/bin/activate # Windows 的 cmd 或 PowerShell 下 .venv\Scripts\activate.bat .venv\Scripts\Activate.ps1激活后命令提示符前面會出現(.venv)此時which python指向環(huán)境內的解釋器。pip install進來的包全部落在.venv/lib/python3.x/site-packages。退出環(huán)境用的是deactivate這是個 shell 函數不是可執(zhí)行文件所以別去which找路徑找不到很正常。創(chuàng)建好環(huán)境后你進目錄看一眼結構會看到bin/Windows 是Scripts/、lib/python3.x/site-packages/還有根目錄下的pyvenv.cfg。這個配置文件記錄了 home指向宿主的 Python 安裝路徑、version 和是否使用系統(tǒng)包。如果你想用.venv/bin/python直接跑腳本而不激活也是完全可以的很多 CI 腳本就是這么干的更少受 shell 環(huán)境干擾。3.2 依賴鎖定與復現requirements.txt 的坑與更穩(wěn)的做法裝完依賴下一步就是讓環(huán)境可復現。最常見的做法是pip freeze requirements.txt但這項操作有幾個坑我都要說清楚。pip freeze會把環(huán)境里所有包全部列出來包括間接依賴這沒問題問題在于它會把一些本地開發(fā)模式的包也輸出成-e git...或-e /path/to/pkg的形式這種行在別處復現環(huán)境時會失敗。另外它導出的版本號是當前環(huán)境鎖死的結果跨平臺時未必完全可靠。我更推薦用 pip-tools 這套流程。先用requirements.in記錄頂層依賴你自己主動裝的那些包然后執(zhí)行pip-compile requirements.in -o requirements.txt pip install -r requirements.txtpip-compile會解析依賴樹并鎖定所有間接版本還會自帶合理的約束注釋。相比手工維護requirements.txt這樣生成的鎖定文件更干凈、更可審查。每次想升級某個包改requirements.in里的版本范圍重新跑一遍編譯即可。如果你在團隊里維護項目我建議把鎖定文件納入版本控制并在 README 里寫明“用哪版 Python 如何建環(huán)境”。否則換個同事、換臺電腦環(huán)境又要重新猜一遍失去虛擬環(huán)境的意義了。3.3 到底要不要用 --system-site-packagesvenv 建環(huán)境默認隔離所有 site-packages但有一個可選參數叫--system-site-packages意思是在你新環(huán)境的sys.path里額外包含系統(tǒng) Python 的包目錄。聽起來很方便系統(tǒng)里已經裝好的大包環(huán)境里直接復用省得重復下載。但代價是你的環(huán)境不再“純凈”系統(tǒng)里任何包的變動都會影響這個項目隔離的初衷就破功了。我個人的建議是除非你強烈需要一個系統(tǒng)級安裝的大型包比如某些公司內網源里的私有 wheel放在系統(tǒng) site-packages 里方便多環(huán)境共用否則別用這個參數。正常情況下每個環(huán)境各裝各的磁盤多占一點但換來的是確定性和安全感。4. conda 實操與依賴解析科學計算場景的底層邏輯4.1 用 conda 創(chuàng)建環(huán)境和指定 Python 版本conda 的環(huán)境管理命令比 venv 多幾層但核心邏輯依然清晰。我平時用得最多的是下面這段# 創(chuàng)建環(huán)境指定 Python 版本和常用 channel conda create -n pyproject python3.10 -c conda-forge # 激活 conda activate pyproject # 安裝依賴 conda install numpy pandas # 退出 conda deactivate注意到沒有創(chuàng)建環(huán)境時直接把 Python 版本寫在了命令行里。你想建 3.9 就python3.9想建 3.12 就python3.12。conda 會根據你的指定去倉庫拉對應解釋器同時替你做依賴求解把解釋器自身依賴的底層庫一并處理好。這種體驗和 venv 完全不同venv 是先有解釋器再談隔離conda 是環(huán)境定義了解釋器。因為 conda 的依賴求解開銷不小命令執(zhí)行經常得等十幾秒甚至更久。我一般優(yōu)先裝好 mambaconda install mamba -n base之后都用mamba create、mamba install代替 conda 對應命令求解速度快得多命令語法幾乎一致?？茖W計算項目里依賴動輒幾十上百個包這個提升是實打實的。4.2 conda 與 pip 共存的風險為什么混用容易炸conda 和 pip 在同一環(huán)境里混用屬于高風險操作搞懂原因你才知道怎么避開。conda 裝包時使用自己的依賴求解器會檢查環(huán)境里已經裝過的 conda 包并維護一套元數據。pip 裝包時只跟 Python 的 site-packages 打交道完全不知道 conda 的存在。兩邊各寫各的環(huán)境里就可能出現兩個同名包的不同副本一個在 conda 管理的目錄一個在 site-packages 的 pip 目錄import 時先命中哪一個取決于sys.path的順序結果就是玄學報錯。我之前處理過這樣的案例某項目在 conda 環(huán)境里已經裝好某個數值計算庫后面有人用 pip 補裝另一個包結果 pip 先把相關依賴升級了一遍把一個底層庫換成了不兼容的版本整個環(huán)境的 “conda 視角” 和 “pip 視角” 徹底分叉最后只能重建環(huán)境。正確姿勢是能用 conda 解決的依賴優(yōu)先 condaconda 倉庫里沒有或版本太老再考慮 pip。一旦這個環(huán)境已經大量用 pip 裝過包就盡量別再回頭用 conda install 添加新依賴至少別動已有依賴的底層庫。4.3 環(huán)境導出與復現environment.yml 的正確打開方式conda 導環(huán)境最常見的是conda env export但這個命令導出的文件包含每個包的具體構建號、內部版本跨平臺復現差。你要在別人電腦上重建大概率對不上。我更推薦兩種組合# 只導出你顯式指定的包干凈很多 conda env export --from-history environment.yml這個--from-history非常實用它只列出創(chuàng)建環(huán)境和后續(xù)conda install時你真正寫下的包名不包含所有被動裝進來的依賴。文件小而清晰適合當項目級別的“頂層依賴聲明”。在此基礎上還需要精確復現鎖定時用 conda-lock 生成帶哈希的完整鎖定文件或者把 pip 依賴單獨用requirements.txt管理兩邊配合。環(huán)境文件里還可以標注 channel 和 pip 依賴name: pyproject channels: - conda-forge dependencies: - python3.10 - numpy - pandas - pip - pip: - requests - -r requirements.txt關鍵點是用這個文件創(chuàng)建環(huán)境后所有包都從 conda 和 pip 兩個來源各裝各的團隊的初始狀態(tài)相對可復現后續(xù)維護也方便。5. venv 還是 conda選型對比與混合使用策略5.1 六個維度看透差異很多人糾結“到底用哪個”其實糾結的原因是沒把問題拆開。我把評估維度整理成一張表你看完基本就能自己判斷。維度venv pipconda核心定位Python 標準虛擬環(huán)境工具跨語言環(huán)境與包管理器Python 版本管理靠宿主機已有解釋器不自動下載環(huán)境內可直接指定任意版本非 Python 依賴基本不管能安裝 C/C 庫、GPU 驅動層組件等依賴解析能力pip 只解析 Python 包conda 自建求解器兼顧二進制層環(huán)境體積小、輕量大、更重團隊協作友好度requirements 文件直觀environment.yml 稍復雜但完整從這個表能看出它不是“誰替代誰”的關系而是誰更適合什么場景的問題。venv 輕、簡單、夠用conda 重、全、能力強。如果你做的是普通的 Web 項目、腳本工具、爬蟲、后端服務venv 完全夠了不必為了“統(tǒng)一工具”把 conda 綁進來反而拖慢上手速度。5.2 按項目類型選路線的直接建議我的具體建議可以歸納成三條路線第一純 Python 項目、Web 項目、自動化腳本用系統(tǒng) Python或 pyenv 裝好的某版本配合 venv依賴用 pip pip-tools 管理。團隊里所有人都用相同流程成本最低。第二數據科學、機器學習、需要 GPU 加速、依賴大量本地二進制庫的項目直接 miniconda mamba。別想用 venv 硬撐C 庫層面的問題是 venv 管不動的。這時候 conda 的跨語言依賴管理真香。第三需要在多個 Python 版本之間同時做兼容測試的庫項目用 pyenv 裝多個版本每個版本下分別建 venv 去跑測試。如果你喜歡 conda 的手感也可以建多個 conda 環(huán)境各有各的 Python 版本邏輯一樣就是更占磁盤。5.3 我實際環(huán)境里的組織方式我在自己的開發(fā)機上長期保持一套固定的組合系統(tǒng) Python 只作為基礎不下手裝任何第三方包pyenv 負責安裝和維護多個 Python 小版本日常項目一律.venv起步涉及科學計算再切到 miniconda。有個小提醒如果你已經在 conda 環(huán)境里開發(fā)某個項目就沒有必要再在里面建一個 venv 來疊加隔離。我踩過的坑是某同事在 conda 環(huán)境里為了跑一段臨時腳本又建了個 venv結果兩套依賴體系嵌套在一起pip 裝的東西到底歸誰管得澄清半天。一個項目定一種隔離方案從一而終。另外不同團隊協作時所有環(huán)境相關命令最好寫進 README 或者 Makefile統(tǒng)一一條路徑。環(huán)境管理最怕的不是復雜而是每個成員都有自己的一套合到一起就是災難現場。6. 常見問題與排查技巧實錄6.1 激活失敗與 shell 配置問題最常見的激活失敗是執(zhí)行source activate pyproject報錯或者進了環(huán)境但python還是老路徑。這多半是因為 conda 的初始化沒有寫入當前 shell 配置文件。解決方式很簡單先執(zhí)行conda init bash或對應你的 shell比如 zsh 用conda init zsh然后重新開一個終端。venv 的激活腳本不會遇到這個問題因為它本來就是直接 source 腳本。Windows 上的 PowerShell 用戶經常會碰到“無法加載文件 Activate.ps1因為在此系統(tǒng)上禁止運行腳本”。這是 PowerShell 執(zhí)行策略的限制管理員身份執(zhí)行Set-ExecutionPolicy RemoteSigned可以解掉或者干脆不用激活腳本直接用.venv\Scripts\python.exe調用環(huán)境內的解釋器反而更省事。排查環(huán)境到底有沒有生效不要光看提示符前的括號直接執(zhí)行which pythonWindows 是where python看路徑是否落在環(huán)境目錄內。有時候 shell 的緩存會作怪別名路徑老轉發(fā)到舊解釋器用hash -r清理一下再看。6.2 幽靈依賴與 PYTHONPATH 污染有種詭異場景你明明激活了虛擬環(huán)境pip list里也沒看到某個包但import xxx居然成功了。十有八九是環(huán)境變量PYTHONPATH在搗鬼。它里面列的目錄優(yōu)先級很高會把虛擬環(huán)境外的包混進來。排查方法很簡單echo $PYTHONPATH如果非空就得警惕。我個人習慣是默認不設置這個變量需要導入自定義代碼時用包結構配合pip install -e .解決而不是靠PYTHONPATH硬加路徑。還有一個更隱蔽的坑忘了激活環(huán)境然后直接pip install。此時包被裝進全局 Python項目跑起來報錯你還沒頭緒。以后養(yǎng)成習慣先確認pip --version的路徑屬于當前項目環(huán)境再執(zhí)行安裝。也可以在項目里直接用.venv/bin/pip install。如果你懷疑某個包到底裝在哪里pip show 包名會顯示 Location 字段指向它實際落地的 site-packages一眼就能看出是不是當前環(huán)境。6.3 依賴沖突與編譯失敗的處理思路pip 裝包時報“ERROR: Cannot install packages because of conflicting dependencies”很常見別一股腦--force-reinstall硬上那樣只會把環(huán)境搞得更亂?？梢韵扔胮ip check診斷哪些包之間依賴不一致把沖突的包找出來再決定降級某方或升級某方。依賴關系復雜的場景用 pip-tools 生成鎖定文件比手工調版本穩(wěn)定得多。編譯類報錯比如error: command gcc failed: No such file or directory大概率是你要裝的包沒有當前 Python 版本的預編譯 wheel?？磮箦e里的綠色提示通常會說“Failed building wheel for xxx”說明它在現場編譯。解決思路有三條優(yōu)先級先找有沒有對應版本的離線 wheel沒有就換低一檔 Python 版本重試最后才考慮補編譯工具鏈硬編。多數情況下換 Python 版本比裝一堆編譯依賴快得多。如果 conda install 求解時間長得離譜先別取消先想想是不是沒有用 mamba。換成 mamba 之后大部分項目的安裝等待時間能壓到 1 分鐘內親測有效。6.4 磁盤占用與重建環(huán)境的實用技巧conda 環(huán)境一個就能占幾個 GB裝多了磁盤告急是常事。conda clean --all能清掉緩存和沒用的包pip cache purge清 pip 緩存。我通常每月跑一次能清理出不少空間。環(huán)境如果徹底壞了也不要執(zhí)著于修復直接conda env remove -n 環(huán)境名刪掉重建只要鎖定文件還在重建比排查壞環(huán)境靠譜得多。venv 同理.venv目錄刪掉重新python -m venv .venv加上 requirements 文件幾分鐘又是一條好漢。還有個小技巧conda 環(huán)境用conda clone復制一份來做升級測試比直接升級原來的安全。我在給生產項目升級 numpy 的時候就是這么干的克隆環(huán)境、在里面跑測試、確認沒問題再動原環(huán)境。我個人在實際操作中的體會是虛擬環(huán)境這件事和寫代碼的水平沒有直接關系它更多是“工程習慣”。你可以在一年內不碰到依賴沖突但只要碰到一次那一次就足以讓你記住所有教訓。我現在無論項目多小哪怕是臨時寫個小腳本也會先建一個虛擬環(huán)境再動手。不是儀式感是為了讓“在我電腦上能跑”這個結論至少可復現、可繼承、可排查。環(huán)境管理花的時間其實是在給未來的自己省時間。