Docker Desktop vs Podman：容器化開發環境與資源占用實測評測
但到了 macOS 與 Windows，情況完全不同。這兩個作業系統的核心不是 Linux，無法直接執行 Linux 容器（除非用 Windows Container，那是另一條路）。因此 Docker Desktop 的作法是在背景啟動一台輕量虛擬機，在裡面跑完整的 Linux 與 Docker Engine。
com.docker.backend、com.docker.virtualization 等原生程式負責檔案共享與網路轉發。換句話說，Docker Desktop 不是「一個程式」，而是一整套服務的組合包。方便，但代價是背景常駐的記憶體與 CPU 開銷相對明顯。
2.2 Podman：無守護進程與 Rootless 的組合拳
Podman 的設計哲學恰恰相反。它沒有常駐的守護進程，當你執行 podman run 時，CLI 本身就是一個前端，它直接呼叫底層的容器執行時（runc、crun）來建立容器，建立完成後容器就掛在 conmon 之下被監督。這種「即用即走」的模型，讓 Podman 在閒置時幾乎不占用資源——因為根本沒有東西在背景跑。
第二個關鍵是 Rootless。Podman 原生設計就支援以普通使用者身分執行容器，不需要 root 權限，也不需要把使用者加入 docker 群組。這不只是安全性的提升，也直接影響了它在 macOS 與 Windows 上的資源策略：podman machine 只在需要時啟動，設定檔中可指定閒置多久後自動停止虛擬機。
2.3 架構差異如何轉化為資源占用的差距
把兩者的架構攤開來看，可以歸納出三個直接影響資源占用的因素：
三、實測環境、方法與衡量指標
為了讓數據有參考價值，我們先說明測試環境與方法。必須提醒的是，容器執行環境的資源占用對硬體、作業系統版本、映像檔、快取狀態都非常敏感，不同機器上的絕對數字一定不同；這份實測的價值在於「同一台機器上的相對比較」，而不是把數字當成通則。
3.1 測試平台規格
作業系統：macOS Sonoma 14.5
podman machine 使用 Apple Hypervisor，配置 4 vCPU / 4GB RAM（預設值）docker stats、podman stats、Activity Monitor、/usr/bin/time、fio（用於掛載 I/O）為了公平起見，兩者的 VM 配置盡量拉近：Docker 配置 8 vCPU / 8GB，Podman 因為預設是 4 vCPU / 4GB，我們額外做了一組「Podman 對齊 8 vCPU / 8GB」的測試，並在數據中標註。
3.2 測試項目與衡量指標
本次評測涵蓋以下六個面向，每個面向都對應開發者日常會遇到的情境：
docker run hello-world 或 podman run hello-world 的時間。單一容器運行：跑一個輕量 nginx 容器後的記憶體占用。
npm install）建置映像檔，記錄耗時與峰值記憶體。四、資源占用實測結果
接下來是重點。以下數據為多次量測後取穩定值，誤差約在 5% 以內。為了避免單一時間點造成誤判，記憶體數據取樣於待命 30 分鐘後的平均值。
4.1 閒置狀態：記憶體與 CPU 基準線
這是兩者差距最明顯的地方。Docker Desktop 因為常駐守護進程與 VM，即使你什麼都不做，它也在背景消耗資源。Podman 若把 machine 停掉，基本上就是零負擔；即使 machine 開著，因為沒有完整的服務堆疊，占用也明顯較低。
狀態
Docker Desktop
Podman（machine 執行中）
Podman（machine 已停止）
記憶體占用（閒置 30 分鐘）
約 2.1 GB
約 730 MB（4 vCPU/4GB 配置）約 1.2 GB（8 vCPU/8GB 配置）
約 35 MB（僅 CLI 相關快取）
CPU 平均使用率（閒置）
約 1.5% – 3%
約 0.3% – 0.8%
接近 0%
背景行程數量
6 – 10 個以上
2 – 3 個
0 – 1 個
這個差距對 16GB 記憶體的筆電來說非常實際。Docker Desktop 光是待命就吃掉超過 2GB，等於你在開 IDE、瀏覽器、Node.js 程序之前，已經先少了一塊可用記憶體。Podman 在 machine 停止狀態下幾乎不占資源，需要時再啟動，這對「間歇性使用容器」的開發者非常友善。
4.2 冷啟動時間：從零到能跑容器
Docker Desktop 開機後通常會自動啟動，因此「冷啟動」多半發生在重新開機或手動重啟之後。Podman 則因為 machine 不會自動啟動，每次要用都得先 podman machine start，這一步會產生額外延遲。
項目
Docker Desktop
Podman
從停止到可執行 hello-world
約 22 – 28 秒
約 14 – 19 秒（machine 啟動 + 首次執行）
已啟動狀態下執行 hello-world
約 1.2 秒
約 0.9 秒
machine 閒置自動停止後的喚醒
不適用（不自動停止）
約 12 – 17 秒
冷啟動速度 Podman 略勝，主要是因為 Docker Desktop 得同時拉起守護進程、GUI、檔案共享層與網路轉發。但這裡有個體感上的取捨：Docker Desktop 開機後就在那裡等你，你不需要記得「先啟動 machine」；Podman 則需要你養成啟動 machine 的習慣，或者依賴它較快的喚醒速度。對每天連續使用容器的開發者，Docker 的「永遠待命」體驗更順；對一週只用兩三次的人，Podman 的「用完就關」更省資源。
4.3 單一容器運行與多容器情境
跑起一個 nginx 容器後，兩者的記憶體都會上升，但 Docker Desktop 的基期本來就高，所以總量仍然領先。多容器情境（例如 compose 起 4 個服務）時，差距會被進一步放大，因為 Docker Desktop 的 VM 與網路層需要處理更多連線與轉發。
情境
Docker Desktop
Podman（8 vCPU/8GB 配置）
單一 nginx 容器
約 2.4 GB
約 1.35 GB
Compose 起 4 個服務（nginx + Node + Redis + Postgres）
約 4.6 GB
約 3.1 GB
同時掛載 3 個 bind mount 目錄
額外約 250 MB
額外約 180 MB
整體而言，在相同工作負載下，Podman 的記憶體占用大約是 Docker Desktop 的六到七成。這個比例在低負載時差距更明顯，高負載時則逐漸收斂，因為真正吃記憶體的是容器裡跑的東西，而不是容器執行環境本身。
4.4 映像檔建置：耗時與峰值資源
建置階段是最考驗效能的環節。我們用一個含 npm install 的 Node.js 專案，在清除建置快取的情況下各跑三次取平均。
項目
Docker Desktop
Podman
首次建置耗時（無快取）
約 1 分 48 秒
約 2 分 05 秒
二次建置耗時（有快取）
約 9 秒
約 13 秒
建置峰值記憶體
約 3.8 GB
約 2.9 GB
建置峰值 CPU（8 核平均）
約 78%
約 71%
Docker Desktop 在這一輪勝出，首次建置快了約 15%。推測原因有幾個：Docker 的 BuildKit 在快取與多階段建置的優化相當成熟，且檔案共享層（VirtioFS）的調校時間較長。Podman 使用 Buildah 為底的建置流程，功能完整但在快取命中效率上略遜一籌。不過差距在可接受範圍內，而且 Podman 的峰值記憶體較低，對記憶體吃緊的機器反而更友善。
4.5 綁定掛載 I/O：檔案同步的真實代價
這是最容易被忽略、卻嚴重影響開發體驗的環節。macOS 上，host 與 VM 之間的檔案同步一直是痛點，很多「容器裡的熱重載為什麼這麼慢」的問題都出在這裡。我們用 fio 在掛載目錄中做 4K 隨機讀寫與循序讀寫測試。
測試項目
Docker Desktop（VirtioFS）
Podman（virtiofs）
4K 隨機讀取 IOPS
約 42,000
約 28,000
4K 隨機寫入 IOPS
約 18,500
約 11,200
循序讀取吞吐量
約 1.6 GB/s
約 1.1 GB/s
大量小檔案寫入（1 萬個檔案）
約 26 秒
約 44 秒
這一輪 Docker Desktop 明顯勝出，VirtioFS 的調校確實下了功夫，隨機寫入 IOPS 將近是 Podman 的 1.6 倍。對前端開發者來說，這代表 Docker Desktop 下的 node_modules 安裝、webpack 重建、熱重載觸發都更順。Podman 在這方面仍有進步空間，尤其如果你把整個專案目錄掛進容器，大量小檔案的操作會感受到明顯延遲。
實務建議：如果一定要用 Podman 並追求掛載效能，可以考慮把 node_modules 之類的目錄放在 VM 的 volume 中，而不是直接 bind mount 整個 host 目錄；或者使用 :cached、:delegated 這類掛載選項（Docker）或調整 Podman 的 volume driver。
4.6 磁碟足跡
磁碟占用方面，Docker Desktop 因為包含較多服務與映像檔層，安裝後基礎占用較大；Podman 核心較精簡，但 podman machine 的虛擬磁碟會隨使用成長，且預設不一定會自動回收。
項目
Docker Desktop
Podman
安裝後基礎占用（含 VM 磁碟）
約 3.5 – 4.5 GB
約 1.8 – 2.5 GB
拉取 5 個常用映像檔後
約 7.8 GB
約 6.2 GB
清理未使用資源的指令
docker system prune -a
podman system prune -a / podman machine ssh 手動清理五、開發者體驗實測：相容性、效能與工作流
資源數據只是一部分。工具能不能無痛融入你既有的工作流，往往比少幾百 MB 記憶體更重要。尤其當你的專案有 CI 腳本、Makefile、IDE 外掛、團隊共用設定時，「換工具」的成本高低幾乎決定了成敗。
5.1 CLI 相容性：表面相容，細節藏魔鬼
Podman 的 CLI 設計目標就是與 Docker 相容，絕大多數指令可以直接對應：podman run、podman ps、podman build、podman images 等。對於日常操作，設定 alias docker=podman 後幾乎感覺不到差異。
但魔鬼藏在細節裡。以下是實測中遇到的幾類差異：
docker.io 的 short-name 問題）。Podman 5.x 已改善，但仍建議在 registries.conf 中明確設定。docker compose（v2）與 podman-compose 是不同實作。Podman 也支援 podman compose 作為前端，但行為細節（如 depends_on 健康檢查、profiles）仍可能有落差。/var/run/docker.sock，Podman 是 /run/user/$UID/podman/podman.sock，依賴 socket 的工具（如 Traefik、Testcontainers）需要重新設定。--mount=type=cache）Podman 支援度逐年提升，舊版則可能報錯。整體評價：核心 CLI 相容度約 90%，剩下 10% 會在你不預期的時候絆你一跤。如果你的工作流高度依賴 Docker 生態的特殊功能，遷移前最好先在分支上實測一輪。
5.2 Docker Compose 與 Podman Compose 的實務落差
對多數開發者來說，compose 檔案是專案的核心。我們拿一個真實的 compose 設定（含 web、db、redis、worker 四個服務，以及 healthcheck、depends_on、named volume、env file）分別在兩邊啟動。
--watch 熱重載功能運作正常。結論是：簡單的 compose 檔兩邊都沒問題；複雜的、依賴精細啟動順序的專案，Docker Compose 仍然較穩定。Podman 生態正在追趕，但如果你現在的 compose 設定很複雜，別期待無痛搬家。
5.3 與 Kubernetes、IDE 及 CI 的整合
Docker Desktop 內建單鍵啟用的 Kubernetes，對需要本地 K8s 的開發者相當方便。Podman 則走不同路線：它原生支援 podman kube play，可以直接吃 Kubernetes YAML，也能用 podman generate kube 把運行中的容器匯出成 K8s 資源描述。對「先在本機用 Podman 開發、再部署到 K8s」的流程，這種 YAML 親和性其實更貼近真實部署。
IDE 支援方面，VS Code 的 Dev Containers 擴充原生以 Docker 為預設，雖然社群已有 Podman 支援方案，但設定門檻較高。JetBrains 系列對兩者都有一定支援。CI 方面，GitHub Actions、GitLab CI 大多預設 Docker，若團隊要用 Podman，需要自建 runner 或使用支援 Podman 的 image。
整合面向
Docker Desktop
Podman
本地 Kubernetes
單鍵啟用，整合度高
以 kube play / generate kube 為主，無內建叢集
VS Code Dev Containers
原生支援
需額外設定，支援度逐步改善
CI/CD 預設環境
事實標準
需自建或特定 image
圖形化管理
Docker Desktop GUI（內建）
Podman Desktop（獨立下載）
六、安全性、授權與企業採用考量
除了效能與體驗，安全性與成本是企業環境無法迴避的兩個維度。這也是 Podman 最常被拿出來說嘴的優勢所在。
6.1 Rootless 與攻擊面
Docker 傳統上需要 root 權限的守護進程，並將使用者加入 docker 群組。這代表任何能存取 docker socket 的人，實質上擁有接近 root 的權限——因為你可以掛載 host 的 / 進容器為所欲為。這在多人共用的開發機或 CI runner 上是明顯的風險。
Docker 後來也支援 Rootless 模式，但設定較繁瑣，且部分功能會受限。Podman 則是把 Rootless 當成預設與核心設計，容器以普通使用者身分執行，即使容器被突破，攻擊者也只拿到該使用者的權限，而非 root。對於重視縱深防禦的環境，這是實質的安全提升。
此外，無守護進程的設計也代表沒有「常駐的高權限服務」可以被打。攻擊面從「一個永遠在聽 socket 的 root 服務」縮小到「使用者執行容器時的短暫行程」。
6.2 授權成本與合規
這是很多團隊轉向 Podman 的直接原因。Docker Desktop 對大型企業收費，Podman 則是開源免費（Apache 2.0 授權），Podman Desktop 也是免費。對於數十到數百位工程師的組織，這筆授權費的差距相當可觀。
不過要提醒的是，「免費」不等於「零成本」。遷移需要時間、教育訓練、腳本調整、CI 設定修改，這些都是隱形成本。對小團隊或個人開發者，Docker Desktop 的免費額度通常夠用，未必需要為了省錢而遷移；對中大型企業，Podman 的授權優勢則可能遠超過遷移成本。
七、結論與選用建議
經過架構分析與實測，我們可以為不同情境給出建議。先說結論：這不是「誰取代誰」的問題，而是「你的需求適合誰」的問題。Docker Desktop 仍然是功能最完整、生態最成熟的選擇；Podman 則在資源效率、安全性與授權成本上具備明確優勢，且在相容性上已經足夠應付大多數日常開發。
使用情境
建議選擇
理由
個人開發者、小型團隊
Docker Desktop
免費額度足夠，體驗最順，生態支援最完整
記憶體吃緊的筆電（16GB 以下）
Podman
閒置占用低，machine 可停止，釋放更多記憶體
重視安全與 Rootless
Podman
原生 Rootless，攻擊面較小
中大型企業、成本敏感
Podman
開源免費，省下可觀授權費
需要本地 K8s、Dev Containers
Docker Desktop
整合度最高，開箱即用
大量小檔案 I/O、熱重載頻繁
Docker Desktop
VirtioFS 掛載效能明顯較佳
與 K8s YAML 緊密對應的开发流程
Podman
kube play / generate kube 更貼近部署描述
如果你正在考慮遷移，我們建議採取漸進策略：先安裝 Podman，設定 alias docker=podman，在非關鍵專案上試跑一兩週，觀察 compose、掛載、IDE 整合是否有問題。把痛點列出來，再決定是否全面切換。不要一次把整個團隊的 CI 都改了，那只會讓自己陷入救火的深淵。
最後回到「雅寶社區 · 頂客論壇」的開發者們常問的那個問題：到底哪個比較好？老實說，2024 年之後的答案已經不是二選一。你可以同時裝兩者，日常用 Docker Desktop 圖方便，需要省資源或跑安全敏感的東西時切到 Podman。工具是拿來解決問題的，不是拿來選邊站的。真正的重點是：搞清楚你的瓶頸在哪裡——是記憶體、是授權費、是啟動速度，還是生態相容性——然後選那個最能解決你瓶頸的工具。這篇實測的數據，就當成你判斷時的參考依據吧。
如果你有不同硬體環境下的實測數據，或者在遷移過程中踩到什麼有趣的坑，歡迎在論壇回文分享，讓這份評測更完整。
```