如果你現在只是想把 OpenClaw 先跑起來，最容易卡住的地方通常不是安裝命令本身，而是第一步就選錯了路。

很多人第一次搜這個專案時，腦子裡的問題其實都差不多：到底該裝在自己電腦上，還是直接扔到雲伺服器？原始碼安裝是不是更“正統”？Docker 會不會更簡單？結果一圈資料看下來，選項越來越多，人反而更猶豫。

我把 OpenClaw 官方 README 和官方 Docker 檔案重新過了一遍，最後的感覺很明確：這不是一個“哪條命令更帥”的問題，而是一個“你現在到底想使用它，還是想接管它”的問題。只要先把這件事想清楚，後面的路其實沒那麼繞。

先想清楚：你是想用它，還是想接管它

如果你只是普通使用者，目標很簡單，就是今天把 OpenClaw 裝起來，先看看它到底適不適合自己，那我真的不建議你一上來就選原始碼安裝。官方 README 現在給的新手入口，本來就是 Node 24，或者至少 Node 22.16+ 的環境裡，直接先裝 CLI：

npm install -g openclaw@latest
openclaw onboard --install-daemon

這條路的味道很明顯，它更像“正常使用者入口”。你先把 CLI 裝好，跑 onboarding，把閘道器和初始設定一步步走完，先讓東西跑起來。它不是在逼你先理解整個專案怎麼 build，也不是在讓你先接手一套開發環境。

原始碼安裝就完全不是這個氣質了。官方給的那組命令是從儲存庫開始，git clone、pnpm install、pnpm ui:build、pnpm build，後面再繼續跑 pnpm openclaw onboard --install-daemon 和 pnpm gateway:watch。你光看這個流程就知道，它更像是給準備深入折騰的人留的。你如果後面要看實現、改行為、跟儲存庫節奏、自己除錯，那當然很合適；但如果你只是想先體驗一下，這條路通常只會把開局變重。

很多人第一次選路時，容易有一個誤會，覺得原始碼安裝既然更“底層”，那肯定也更“完整”。但對普通人來說，這種完整很多時候只是多背了一層維護成本。Node 版本、依賴裝沒裝好、UI 有沒有 build 過、後面升級會不會卡住，這些事情都會提前落到你頭上。你如果本來只是想確認 OpenClaw 好不好用，這個代價不太划算。

Docker 不是自動更輕：本地和雲端是兩回事

Docker 也是一樣，別一聽容器化就覺得它自動更輕。OpenClaw 官方 Docker 檔案開頭其實說得很直白，Docker 是 optional。它更適合你想把 Gateway 放進一個隔離環境裡，或者你本來就是準備把它跑在一台更像部署主機的機器上。反過來說，如果你已經坐在自己的電腦前，只是想盡快開始用，官方反而更偏向普通安裝流。

這點我覺得特別重要，因為它直接把“本地電腦”和“雲端伺服器”分成了兩類事情。在自己電腦上，Docker 很多時候不是最快路徑。你還得先有 Docker Desktop 或 Docker Engine，要確認 Compose v2 沒問題，還得留足夠的資源給鏡像建置。官方檔案甚至專門提醒過，鏡像建置至少建議 2 GB 記憶體，不然 pnpm install 可能就會因為記憶體不夠被系統殺掉。你如果只是想先開箱體驗，這套前置動作未必比 CLI 更省事。

但如果你是在雲端，情況就會一下子變得不一樣。你如果本來就準備把 Gateway 長期掛在一台 Linux 機器上，這時候 Docker 反而很順手。不是因為它更高階，而是因為它更像一條正經部署路徑。你把執行環境包起來，後面遷移、重建、刪了重來，思路都會乾淨一些。它不代表沒有維護成本，只是這些成本更符合“伺服器在跑一個服務”這個場景。

而且 OpenClaw 官方 Docker 檔案本身，也不是那種“一條 docker run 就完事”的寫法。它給的主流程，是在儲存庫根目錄裡跑 ./scripts/docker/setup.sh，讓腳本去處理鏡像、onboarding、.env 和 Docker Compose 啟動。如果你不想自己本地建置，也可以先匯出預建置鏡像：

export OPENCLAW_IMAGE="ghcr.io/openclaw/openclaw:latest"
./scripts/docker/setup.sh

這其實已經說明很多了。Docker 這條路不是為了把所有東西藏起來，而是為了把執行環境收進容器裡。它更像“部署模式”，不太像“安裝模式”。檔案裡還有個細節也挺說明問題，在這套流程裡，openclaw-cli 更像容器起來之後繼續操作的工具，而不是從零開始的安裝器。有些 setup-time 的動作，官方就是讓你透過 openclaw-gateway 去做的。

一句話總結：選路就是選維護成本

所以如果現在讓我用一句很白的話總結，我大概會這麼說。你如果只是想在自己電腦上先把 OpenClaw 跑起來，先用官方 CLI，別急著碰原始碼。你如果準備把它放在雲端長期跑，那就認真看 Docker，因為那條路更像部署。至於原始碼安裝，只有當你已經很確定自己後面會看程式碼、改實現、追版本、自己扛建置時，它才真有意義。

說到底，原始碼安裝和 Docker 部署差的根本不是命令多兩行少兩行，而是你準備把後續維護成本放在哪。原始碼路徑的好處是透明，專案結構和建置過程都在你眼前，離問題更近，也更方便改；代價是 Node、依賴、UI 建置、開發腳本這些事情都會變成你的日常。Docker 路徑則是把執行時包起來，對雲端特別友好，但你還是得管持久化、埠、健康檢查、鏡像更新和存取面。官方檔案裡會提到 healthz、readyz、lan、loopback，甚至還會提醒公開主機上的 Docker 防火牆策略，這些都在說明一件事：這條路服務的是部署者，不是第一次裝軟體的人。

四個最常見的坑

普通人最容易踩的坑，其實也無非就這幾種。第一種是把原始碼安裝當成預設安裝，結果剛開始就被依賴和 build 繞暈。第二種是把 Docker 想得過於輕鬆，尤其是在本地電腦上，最後發現容器環境本身反而成了門檻。第三種是低估執行時要求，比如 Node 版本這種看起來不起眼的東西，一旦不對，後面很多問題都只是連鎖反應。還有一種特別常見，就是伺服器上終於跑起來了，就覺得事情結束了，結果後面遷移或重建時才發現，真正麻煩的根本不是容器，而是資料和設定。

如果你真打算把 OpenClaw 長期放在伺服器上，這時候順手把備份和還原路線一起想一下，會比後面補救輕鬆很多。像我前面寫過的 Docker 資料卷自動備份到 GitHub：適合 1Panel 的低成本容災方案，其實就是這種思路。別一開始就想做得多大，先保證出問題時還有一條能回來的路。

我自己看完 OpenClaw 這套檔案後，最直觀的感受其實就一句話：它給的不是一條安裝路，而是幾條面向不同人的路。你只要別把“我要先用它”和“我要自己接管它”混在一起，整個部署問題就會簡單很多。

如果你平時也在整理自己的部署路線，可以順手看一下這個站裡的 部署主題頁。我後面還會繼續把這類“本地怎麼裝、雲端怎麼放、什麼時候該容器化”的實戰文章慢慢補起來。