谁会遇到问题：要在新笔记本、WSL2、Linux 服务器或 Windows 上装 OpenClaw，默认会走官方 curl / PowerShell 一键脚本，但在企业代理、证书替换、执行策略或 PATH 未刷新时，脚本「跑完却找不到 openclaw」或版本与团队基线不一致。本文结论：把《三平台安装与部署总览》当叙事地图，把本文当双轨安装与版本治理 Runbook：脚本轨成功则快，失败则切 npm install -g 并 pin；装后先做 PATH/Node 自检，再接《doctor 与装后排错》。结构：六类坑 → 对照表 → 命令片段 → 六步 Runbook → 三指标 → 选型收束。
官方安装器会尝试检测 Node、拉取脚本、写入全局 CLI，但非交互环境与企业 TLS 策略会让「成功」只停留在下载层：openclaw 实际落在用户 prefix，而 CI 用的服务账号 PATH 未包含；或脚本安装了全局包，但 shell 初始化文件未在非登录 shell 中加载。下面六条是交付现场最常见的误判。
node -v 与官方安装文档的硬性下限写进基线表，而不是「能跑 npm 就行」。npm i -g openclaw@latest，which openclaw 可能指向不同 prefix；排障时先看真实路径再谈配置。curl | bash 失败时反复重试 curl 往往无效；应切 npm 轨并显式配置 HTTPS_PROXY、npm config set cafile 或内网 registry 镜像（需安全评审）。@latest，Gateway 行为在夜间滚动升级后漂移；与《Gateway 无回复与模型错误分诊》里看到的「通道正常但模型侧突然报错」常同源。把安装轨选择与《三平台总览》里的部署拓扑绑定：本机开发可容忍脚本快路径，无人值守构建机应优先可 pin 的 npm 轨或内网制品，并在变更单里写明 Node 与 CLI 版本对。
若组织使用 pnpm / corepack 作为标准，可把「全局 CLI」改为受控的 pnpm dlx 或私有 registry 中的封装包，但原则不变：入口命令必须落在审计过的路径，且与 systemd/launchd 单元里的 Environment 一致。不要在文档中混用「官方示例里的 latest」与「内部清单里的 pin」而不写迁移步骤，否则新同事照抄官网就会把集群打回漂移态。
对于同时运行多个 Node 项目的构建机，建议用版本管理器把「系统级 openclaw」与「业务项目的 Node」隔离：openclaw 所在的主版本单独升级，避免业务依赖被连带 bump；这与多项目资源池类文章中的队列隔离思路一致，只是对象换成 Node 运行时。
按「是否能稳定访问脚本域名」「是否需要可审计版本」「是否无人值守」三要素打勾，而不是按个人喜好。
| 维度 | 官方 curl / bash 或 PowerShell 轨 | npm / pnpm 全局轨 |
|---|---|---|
| 首装速度 | 通常最少步骤，适合联网良好的个人机 | 需先保证 Node 与包管理器就绪，步骤略多 |
| 企业代理友好度 | 依赖脚本域名与证书链，失败时噪声大 | 可拆分 registry、cafile、strict-ssl 与 pin，审计友好 |
| 版本可重复性 | 若总是 latest，漂移风险与脚本轨相同 | 显式 [email protected] 可写入 lockfile 式内部清单 |
| 无人值守/CI | 需确保非交互与 PATH 一致 | 更易与容器基础镜像或 golden AMI 对齐 |
| 回滚 | 依赖安装器提供的卸载/覆盖策略 | 可安装上一确切版本并替换软链，配合变更单 |
把输出粘到变更单或 Wiki；远程 Mac 上建议由 provisioning 用户在与守护进程相同的登录上下文中执行。
node -v command -v openclaw openclaw --version 2>/dev/null || openclaw version 2>/dev/null || true # npm 轨示例（版本号请替换为团队基线） # npm install -g [email protected] # npm config get registry # npm config get cafile
注意：在文档或工单中引用安装命令时，请使用团队已评审的镜像或版本号占位符；不要把含内网凭证的 .npmrc 片段贴进公开仓库。
curl -fsSL … | bash 入口，Windows 使用文档中的 PowerShell 一行；失败时保存完整 TLS 报错。cafile 后执行 npm install -g openclaw@<pin>；用 npm ls -g --depth=0 确认单版本。Environment 或 Runner 环境，而不是仅写进交互式 shell rc。若使用配置管理（Ansible、Salt 等）批量下发安装，请把「探测是否已装目标版本」写成幂等任务：重复执行不应默默升级到 latest。对 Windows 场域，建议把 PowerShell 执行策略与 npm global 路径写入 GPO 说明页，并在试点 OU 验证后再全量推送，避免大规模锁死脚本入口却无人知晓如何改走 npm。
openclaw doctor 通过的间隔：拉长通常意味着 PATH、权限或代理而非模型配置问题。npm ls -g --depth=0 | grep -c openclaw 类检查应恒为 1；大于 1 立即标红。工程对齐说明（非基准测试数据）：在 2025–2026 的企业交付中，「脚本轨 + 无 pin」组合在跨三五十台构建机扩展时，夜间自动升级导致的 Gateway 行为漂移工单明显高于「npm 轨 + 明确 pin + 变更窗」组合；差异主要体现在排障可重复性而非峰值算力。
当 OpenClaw 与 iOS 构建链共享同一远程 Mac 时，建议把 Node/OpenClaw 升级窗与 Xcode 大版本升级窗错开至少一个维护周期，避免同一晚叠加两类工具链变更，导致值班无法用二分法定位。
在只读构建机上，可把「安装指纹三行」输出写入每次 job 的摘要块（注意脱敏），与 Gateway 进程启动时间戳对照；若指纹未变而行为变，应优先怀疑模型侧配额或通道配置，而不是重装一遍 openclaw。这样能把《Gateway 无回复》篇里的四层分流树真正落地成可观测信号。
个人笔记本可以容忍反复试错，但生产或 CI 需要可审计的安装轨、可回滚的 pin、与守护进程一致的 PATH；临时云主机若每次重建都用 @latest，排障会退化为「猜今晚上游发了什么」。对要把 Gateway 长期跑在远程 Mac、并与多地区出口、磁盘水位、日志轮转一起治理的团队，使用具备独占 Apple Silicon、弹性租期与可预期网络出口的专业环境，通常比频繁更换临时实例更省总拥有成本。MACCOME 提供多地区 Mac mini M4 / M4 Pro 与公开价格说明，便于把 OpenClaw 常驻与构建机放在同一区域策略下管理。
若你仍在对比「自建物理机 + 手工脚本」与「云主机随手装」，建议先用本文 Runbook 在一台试点机上固化 pin 与 PATH，再评估横向扩容；把失败指纹与《Gateway 无回复》篇的分流树对齐，可减少重复劳动。
最后提醒：安装器域名与 npm registry 都可能被做「按区域」的访问控制；把允许清单与证书更新节奏纳入季度评审，比事后在群里追问「昨晚谁改了代理」成本低一个数量级。把本文 Runbook 与内部变更模板绑定，新集群上线时少踩一半坑。
常见问题
本篇和《三平台安装与部署总览》边界在哪？
总览讲场景与端到端路径；本文讲双轨安装、代理回退与 pin。选型时可参考 租赁价格说明 评估常驻构建与 Gateway 的机型与租期。
能不能只用 Docker 跳过本地安装？
可以走容器路径，但宿主仍需一致的 CLI 与卷权限策略；详见 Docker 生产 Runbook。本文仍有助于理解 Node 与 CLI 版本在宿主层的来源。
WSL2 与原生 Linux 命令有差异吗？
有：systemd 可用性、路径映射与 Windows 侧代理继承都会影响脚本轨；失败时优先切 npm 轨并在 WSL 内单独配置代理与 cafile。