你已经读过站内 Ubuntu 24.04 + systemd + Tunnel 与 Docker Compose 生产 两篇「重运维形态」长文，但仍需要在 Windows / macOS / 通用 Linux 上把 OpenClaw CLI 与 Gateway 先装稳、再常驻、再验收健康检查。本文补齐这一层：三端共同前置、分端对照表、六步从安装到 daemon、常见安装阶段报错，以及与两篇生产文的边界划分，方便你在本机、WSL2 或小规格 VPS 上复现同一套心智模型。
OpenClaw Gateway 本质是长期驻留的服务进程叠加 CLI 工具链；只要前置不一致，后面 systemd、Compose 或 Tunnel 再正确也会反复踩坑。下面七条来自多平台排障的高频模式，建议写进你们内部的「安装 Runbook」而不是只存在聊天记录里。
Node 版本漂移：团队笔记本是旧 LTS，CI 又是另一种；Gateway 启动脚本在 A 机器能跑、B 机器直接语法或依赖报错。安装前用官方二进制或 nvm/fnm 把版本钉死并写进文档。
状态目录进了同步盘：把 ~/.openclaw 或等价路径放在 iCloud、OneDrive、网盘同步目录会导致锁文件、权限与冲突；应放在本地磁盘并备份策略单独设计。
Windows 原生与 WSL2 混 PATH：在 PowerShell 里装的 CLI，却在 WSL 里执行，或反之，导致「命令找不到」与证书路径错乱。选定一条主执行面并全团队统一。
macOS TCC 与应用位置：GUI 组件若不在 /Applications 或缺少辅助功能/自动化授权，会在升级后随机弹窗阻塞无人值守场景。
没有健康检查闭环：装完只看「进程在」，不 curl 不回环、不看 dashboard，生产一切换网络就 502。
默认监听 0.0.0.0：为了省事把管理面直接暴露，短期省事、长期审计与扫端口风险暴涨；应与隧道或反向代理组合。
token 写进 shell 历史：export 一行过、截图发群，等于把钥匙串贴在玻璃上；应使用受限权限文件或密钥管理。
把以上清单勾完，再进入分端对照表，你会明显减少「同样命令在三台机器上三种结果」的摩擦。若你同时需要 iOS 构建或长期图形会话，可把 Gateway 放在 Linux 或本机，而把重计算丢到独占远程 Mac 节点上，拓扑上仍保持「控制面 + 执行面」分离。
另一个隐性成本是文档分裂：有人照官方 README，有人照内部 wiki，还有人照三个月前的截图。把「支持的 Node 小版本范围、状态目录路径、daemon 安装子命令」三件事写成单一事实源（Single Source of Truth），比多写十页概念介绍更有用。
安装阶段还要预留回滚窗口：升级 CLI 或 Gateway 小版本前，先备份配置目录与 token 文件；daemon 安装失败时，应能一键回到上一版二进制或上一张镜像 digest。很多团队只在「能启动」时庆祝，却在升级夜才发现旧配置键名已废弃——这类问题靠对照变更日志与在预发布环境先跑一遍 onboard 校验可以提前消化。
若你在组织里同时推进多条 Agent 业务线，建议把「开发机上的手工安装」与「生产上的 systemd/Compose」用标签或命名空间隔开，避免开发同学把实验性插件目录同步进生产状态路径。最小可行做法是：开发用独立前缀目录，生产用只读配置挂载与只写数据卷，二者绝不软链混用。
三端都能跑同一套 Gateway，但「谁负责拉起进程、日志去哪看、升级怎么回滚」各不相同。用一张表把差异钉死，评审时就不会把 Windows 服务与 LaunchAgent 混谈。
| 平台 | 常见安装入口 | 常驻（daemon）思路 | 典型踩坑 |
|---|---|---|---|
| Windows | 官方安装包、PowerShell 一键脚本、或包管理器 | Windows Service / 任务计划（配合日志目录权限） | 原生与 WSL2 双环境、杀毒误拦、路径含空格 |
| macOS | Homebrew、curl 安装脚本、或上游发布页 | LaunchAgent / LaunchDaemon（按是否需登录会话选型） | TCC 授权、Gatekeeper、状态目录权限 |
| Linux（通用） | 包、静态二进制、或 npm 全局（依上游推荐） | systemd user/system 单元（生产长文已给范例） | SELinux/AppArmor、最小镜像缺依赖、回环只绑 127.0.0.1 却被 iptables 误伤 |
跨平台一致的不是「点哪个安装器」，而是：版本钉死、状态目录本地化、监听面收敛、健康检查可脚本化。
当你在 Linux 上要上生产级 Tunnel 与单元文件，请直接切换到 Ubuntu 24.04 + systemd + Tunnel 教程；若目标是镜像 digest 与命名卷，请用 Docker Compose 生产篇。本文停留在「把 CLI/Gateway 装对并能 daemon 化」这一层，避免三篇文章互相抢 scope。
下列步骤以「上游 CLI 已提供 onboard 与 daemon 安装子命令」为前提；若你的发行版命令名略有差异，请以 --help 输出为准，但顺序不要打乱。
锁定运行时：node -v 与上游要求对齐；不满足则先升级，再谈 Gateway。
安装 CLI：按平台选官方推荐路径（避免混用 sudo 与用户级全局目录）。
准备配置与密钥：把模型供应商密钥放进 env 文件或密钥管理，权限 600；不要写进公共仓库。
执行 onboard：生成或校验 Gateway 配置与 token；输出路径记进 Runbook。
安装 daemon：使用上游提供的 install-daemon 类子命令，把崩溃自启与日志目录一次配好。
验收：用 status / health / 本机 curl 回环三步确认「不是假 running」。
node -v openclaw --version openclaw onboard --install-daemon openclaw gateway status openclaw dashboard
提示：若 status 显示正常但外网不通，优先区分「进程问题」与「路由问题」：先本机 curl 回环，再查隧道或反向代理，与站内 Linux 长文的排障顺序一致。
Windows：若团队开发主要在 WSL2，建议在 WSL 内完成 CLI 与 Gateway，以便与 Linux 生产脚本共享同一套路径约定；需要访问 Windows 侧文件时注意 DrvFS 的 IO 与权限差异。若必须 Windows 原生服务承载，确保服务账户对状态目录与日志路径有显式 ACL。
macOS：把需要 GUI 授权的组件放在稳定路径，避免从下载目录直接运行；升级系统后复查自动化与辅助功能授权。无人值守场景尽量用 LaunchDaemon 而非绑定登录会话的 Agent，除非上游明确要求 UI。
Linux：当你已经会写 systemd unit，就不要在本文停留——直接去裸机长文抄生产模板；若选 Docker，则让容器内进程与宿主机回环/Tunnel 的职责在 Compose 文件里写清楚，避免双 Gateway 争端口。
排错时建议固定一个症状→证据→假设顺序：先把 CLI 与 Gateway 的日志级别调到可读的 verbose（注意勿长期全开以免磁盘打满），再在相同版本上复现；若仅某一台机器失败，优先比对环境变量、代理与系统时钟 skew。时钟漂移会导致 token 与 TLS 握手莫名其妙失败，这类问题与业务逻辑无关却最耗时间。
最后，别把「能打开 dashboard」当成生产就绪。dashboard 往往只验证局部链路；真正上线前仍应跑一轮最小端到端用例：从上游触发一次典型任务，经 Gateway 完整走通鉴权、路由与回调，再观察失败重试与限流是否符合预期。
注意：公开可扫描的 Gateway 管理面在 2026 年仍是高频误配来源。默认应假设攻击面存在自动化扫描，把白名单、隧道、mTLS 或内网访问当作基线而不是可选项。
以下条目用于内部对齐，不代表对第三方项目的承诺；以你实际安装的版本帮助与发布说明为准。
仅在本机或轻量 VM 上「凑合跑」Gateway，短期能演示，但睡眠策略、磁盘 IO 与网络抖动会把 Agent 工作流变成不可预测；自建机房 Mac 又要扛折旧与机房运维。对需要稳定 Apple Silicon 执行层跑构建、脚本化签名或与 Gateway 并行的自动化任务，把重负载放到合同化的远程 Mac 独占节点通常更贴近生产。综合安装复杂度与长期运维，NodeMini 的 Mac Mini 云端租赁适合作为 OpenClaw 之外的算力底座：控制面留在你熟悉的 Windows/Linux/macOS，执行面在可预期的远程 Mac 上扩容。
把采购与运维语言统一成「节点」也有助于和财务、采购对齐：按地区与磁盘档位选购、按租期做预算，而不是把笔记本摊销与云主机账单混在同一张表里。这样当 OpenClaw 流量上升时，你可以独立扩容执行层，而不必推翻整个开发机配置。
本文讲三端通用安装与 daemon 验收；Ubuntu systemd 篇与 Docker 篇讲生产拓扑。更多文章可在 OpenClaw 专栏 筛选。
Node 版本、状态目录是否在同步盘、以及当前终端属于 Windows 原生还是 WSL2。需要并行节点时先对照 租赁价格说明。
常见 SSH/VNC 与网络条目见 帮助中心；Gateway 路由与隧道仍建议回到上述两篇生产长文对照。