軟體套件管理原理：為什麼版本鎖定
pnpm
pnpm-lock.yaml
自動產生
應用：是
內容可讀性高、支援嚴格 peer 檢查
Yarn Berry
yarn.lock
自動產生
應用：是
支援 zero-install、PnP
Poetry
poetry.lock
install 預設使用
應用：是
會記錄雜湊，需 poetry lock 更新
uv / pip-tools
uv.lock / requirements.txt需明確指定
視用法
pip 本身無原生鎖定，需靠 --require-hashes
Cargo
Cargo.lock
自動產生
應用：是；函式庫：多數建議否
單一版本解析、--locked 嚴格模式
Go modules
go.sum + go.mod
自動維護
MVS 演算法、go.sum 只校驗不鎖版本
Bundler
Gemfile.lock
自動產生
應用：是
歷史悠久，生態共識強
其中 Go 的設計特別值得玩味。go.sum 記錄的是「模組內容的雜湊」，用來校驗你下載到的模組是否被篡改；但「用哪個版本」是由 go.mod 加上 MVS 演算法決定的，而 MVS 選的是「滿足所有下限的最小版本」，本身就相對穩定。所以 Go 的鎖定哲學不是「凍結解析結果」，而是「用演算法讓解析結果可預測，再用雜湊確保內容可信」。這是一個不同思路的解法，在某些場景下反而減少了鎖定檔的維護負擔。
4-3 鎖定檔要不要進版控？
這個問題在應用程式與函式庫之間，答案截然不同，混淆兩者是最常見的錯誤。
應用程式（application）：請進版控。應用程式是最終產物，它的部署環境需要完全可重現。你的 CI、測試環境、生產環境、同事的筆電，都應該裝到同一組版本。沒有鎖定檔，你就是在賭。
函式庫（library）：多數情況下不進版控。函式庫的消費者有自己的鎖定檔，你的工作是提供合理的版本範圍（例如 ^1.2.0），讓宿主專案去解析。如果你把鎖定檔也發布出去，反而可能造成版本衝突——宿主被迫使用你鎖定的版本，即使他們的環境需要更新的版本。Cargo 的官方文件就明確建議函式庫專案不要提交 Cargo.lock（除非是 binary crate）。
至於「給應用用的框架」算哪一邊？通常看它的部署形態：如果是你自己部署的服務，就當應用處理；如果是給別人安裝的 SDK，就當函式庫處理。
五、鎖定的代價：副作用與正確姿勢
5-1 鎖太死的三種病症
版本鎖定不是「越死越好」。過度鎖定會導致另一組問題，而且這些問題往往比「版本浮動」更隱蔽、更難修。
第一種：安全補丁進不來。有些團隊把鎖定檔當成神主牌，三年不更新。結果某天掃描工具報了一堆 CVE，每個都牽涉到鎖定檔裡的老版本。這時候升級不是改一個數字，而是要處理一連串的 breaking change。原本可以每週做一次的小事，累積成一次性的災難。
第二種：依賴殭屍。鎖定檔裡躺著一些早就不需要的套件——可能是某個功能移除後忘了清、可能是某個套件的傳遞依賴被上游砍掉了，但你的鎖定檔還留著。這些殭屍依賴會增加攻擊面、拖慢安裝、混淆稽核。
第三種：升級雪崩。當你終於決定更新時，才發現有二十幾個套件需要一起升，而它們之間又有版本衝突。這種「債務一次到期」的場景，往往導致團隊乾脆放棄升級，繼續在舊版本上苟活。
這三種病症的共同解方是：持續的小幅更新，而不是一次的大跳躍。鎖定的目的不是「永不變動」，而是「讓變動成為可控、可審查、可回滾的事件」。
5-2 分層策略：應用鎖死、函式庫放寬
一套成熟團隊的版本策略，通常會依照「這個套件在系統中的角色」來分層：
1.2.3 而非 ^1.2.3），並在鎖定檔中固定。升級時要走完整的測試流程。~ 或 ^，搭配自動化 PR 審查。peerDependencies（例如 React 生態的 plugin），更要明確宣告相容範圍，而不是鎖死。這種分層的精神是：把「穩定性」留給最需要的地方，把「彈性」留給影響最小的角落。一刀切的策略——不管什麼都鎖死，或不管什麼都放寬——都會在某個地方付出代價。
5-3 自動化：讓機器幫你更新與把關
既然「持續小更新」是正解，那就不能靠人記得。現代團隊通常會導入依賴更新機器人，例如 GitHub 的 Dependabot 或社群版的 Renovate。它們的基本邏輯是：
定期檢查依賴是否有新版本。
依照更新類型（patch / minor / major）建立對應的 PR。
讓 CI 跑測試，綠燈才合併。
實務上建議的設定策略是：
minor 更新：自動建 PR，人工快速審查後合併。
同時，把安全掃描接進 CI：npm audit --audit-level=high、cargo audit、pip-audit、bundle audit，搭配 SBOM 產出（如 CycloneDX、SPDX），讓「我裝了什麼、有沒有已知漏洞」變成每次建置都會回答的問題，而不是出事後才回頭查。
六、評測視角：主流工具的行為對照與選型建議
從評測的角度看，「版本鎖定」這件事的體驗好壞，取決於四個維度：預設是否鎖定、鎖定的嚴格程度、更新鎖定的便利性、以及與 CI 的整合度。以下是針對幾個常見情境的觀察。
npm 生態：預設會產生鎖定檔，但 npm install 的行為相對寬鬆（會重新解析並可能更新鎖定檔）。團隊紀律要靠 npm ci 來維持。優點是生態成熟、工具鏈完整；缺點是鎖定檔體積大、merge conflict 頻繁，而且 node_modules 的巢狀結構讓「到底裝了哪個版本」有時需要靠 npm ls 才看得清。
pnpm：鎖定檔是 YAML 格式，可讀性明顯優於 npm 的 JSON。透過硬連結與全域儲存，安裝速度快、磁碟佔用小。對「嚴格 peer 依賴」的檢查也更積極，能提早暴露版本不相容的問題。如果你的團隊常被「幽靈依賴」（phantom dependency，也就是沒有宣告卻能 import 到的套件）困擾，pnpm 的隔離式 node_modules 結構會是明顯的改善。
Cargo：把「鎖定」與「發布」的界線劃得很清楚。Cargo.lock 對 binary crate 是必要的，對 library crate 則建議排除。--locked 旗標讓 CI 可以嚴格要求鎖定檔不得變動，--frozen 更進一步禁止任何網路存取。這種「明確旗標、明確語意」的設計，對維運團隊相當友善。
Poetry / uv：Python 生態長期缺乏原生鎖定機制，Poetry 補上了這一塊，而 uv 則以極快的解析速度與原生鎖定檔（uv.lock）快速竄起。對 Python 團隊來說，重點不是「要不要鎖定」，而是「用哪個工具來鎖定、以及如何與既有的 requirements.txt 流程整合」。
Go modules：走的是「演算法保證穩定 + 雜湊保證內容」的路線，鎖定檔的維護負擔相對低。代價是「最小版本選擇」有時會讓你停留在較舊的版本，需要靠 go get -u 主動拉抬。
選型建議很簡單：先看你的生態系，再看你的團隊紀律。如果團隊已經有良好的 CI 與自動化更新流程，任何主流工具都能運作得不錯；如果沒有，那麼「預設就嚴格」的工具（例如 CI 預設跑 npm ci、Cargo 預設產生鎖定檔）會比「靠人記得」的工具可靠得多。
結語：鎖定不是保守，而是把不確定性關進籠子
回頭看，版本鎖定的本質其實很簡單：它承認了軟體依賴是一個動態、開放、由陌生人共同維護的生態，而你無法控制它。既然無法控制，那就把「什麼時候接受變動」的主導權拿回自己手上。
這不是保守主義，也不是對開源維護者的不信任。相反地，正是因為我們信任開源生態、大量使用它，才更需要一套機制來確保「今天的成功可以複製到明天」。鎖定檔就是那份備忘錄：它記錄了某一天，你的專案在什麼樣的依賴組合下，是健康的、可運作的、經過測試的。
所以，下次當你在 code review 裡看到那一大坨鎖定檔 diff 時，不妨多看兩眼。它不只是一堆自動產生的雜訊，而是一份供應鏈的物料清單、一份除錯的責任邊界、一份對未來自己的承諾。
版本鎖定的目的，從來不是「永遠不變」，而是「每次改變，都是你決定的」。
```