許多團隊在 Windows 桌面用 WSL2 取得接近 Linux 的工具鏈，再把建置與簽章交給 MacCloud 上的真機。OpenClaw 若跑在 WSL 內，真正折磨人的往往不是業務程式碼，而是路徑互操作、行尾符與網路堆疊。
一、發行版與核心
優先選 Ubuntu 22.04 / 24.04 LTS，先 sudo apt update && sudo apt upgrade。確保 WSL2 核心夠新，舊核心在虛擬網卡上更容易出現「偶發斷連、DNS 逾時」。
二、專案放哪：~/ 還是 /mnt/c
把版本庫放在 WSL 原生路徑（如 ~/projects），而不是 /mnt/c，I/O 與檔案監聽會舒適許多。若必須讀 Windows 側檔案，注意跨檔案系統時權限位元與可執行旗標可能不一致，腳本別硬依賴 chmod +x 的語意。
經驗法則：需要高效能建置快取的目錄，一律留在 WSL 檔案系統內。
三、SSH 到 MacCloud
在 WSL 裡單獨產生 SSH 金鑰，把公鑰寫入雲端 Mac 的 authorized_keys。VS Code Remote 建議分別為 Windows 與 WSL 設定擴充功能與金鑰路徑，避免「明明有 key，擴充功能卻找不到」的問題。
四、DNS、VPN 與公司網路
若解析異常，檢查 WSL 的 DNS 策略與 resolv.conf 是否被覆寫。與公司 VPN 並存時，盡量在宿主機做分流，讓 WSL 繼承穩定路由；別把結論建立在「家裡網路正常」單一情境。
五、與 Linux／macOS 文件的關係
WSL 更接近 Linux 側實踐：服務託管可參考Linux 部署；真正跑 GUI 或 Xcode 相關步驟請在 Mac 上完成，並讀macOS 安裝與MacCloud 實踐。
六、自檢清單
- 目前 shell 下
pwd是否在WSL 原生磁碟？ ssh -v到 MacCloud 是否走你預期的金鑰？- 公司 VPN 開關前後，
ping／curl是否都做過對照？
把 WSL 當「編排與指令稿側」、把 MacCloud 當「真機建置側」，邊界畫清楚後，排錯會快很多。
