把 OpenClaw 从本机开发机或上一台远程节点迁到加拿大远程 Mac M4，最容易翻车的不在「复制文件」，而在Gateway 18789 并行期、LaunchDaemon 环境差异与跨洋链路误判。本文给一套可审计的迁移剧本：先冻结旧侧，再在新机空台跑通，最后用 SSH/VNC 做「人机共读」的验收与明确回滚扳机。首次装机路径可对照 2026 OpenClaw远程Mac安装路径实战：install.sh、Homebrew与npm对照教程，加拿大M4节点Gateway 18789资源规划与常见报错排障；onboard 与守护进程基线见 OpenClaw 2026 远程 Mac 安装部署与排障：openclaw onboard、Gateway 守护进程与加拿大 M4 中高配资源规划实战。
迁移风险画像：为什么要「并行窗口」而不是连夜切换
单轨切换的问题在于：一旦新机 plist 里 PATH 与交互 shell 不一致、或 token 与上游 DNS 未同步，你会在亚太早晨看到「通道间歇失联」却找不到单一根因。并行窗口的核心是旧节点只读服务与新机候选流量并存：上游（Tunnel、反代、Tailscale 标签或内部 DNS）用权重或手工拨杆逐步偏转，而不是一次性改死。
加拿大节点通常承担北美验收窗口与夜间批跑，迁移日尽量避开对方周五晚高峰与你的周一早高峰重叠；把变更工单写成「阶段闸门」，每一闸都有可下载的验收截图或日志片段。
双轨准备：旧节点冻结快照与新机空台验收清单
旧侧：锁定写入——停止自动 npm/git 拉取，导出 npm ls --depth=0、node -v、当前 OpenClaw 版本号与配置文件哈希（shasum -a 256）。新侧：在未承接流量前完成「空台四件事」：磁盘余量 ≥18%、NTP 偏差 <500ms、本机 loopback 访问 18789 health 正常、以及专用日志目录已创建且属主正确。
| 阶段闸门 | 准入条件（最小集） | 产出物（留存） |
|---|---|---|
| G0 冻结 | 旧节点配置只读；变更工单号已分配 | 依赖树、版本号文件、配置哈希表 |
| G1 空台 | 新机磁盘/NTP/本机 health OK | 截图或文本探针记录 |
| G2 并行 | 双端 token 与上游一致；权重可回拨 | 拨杆前后请求抽样 ≥200 条 |
| G3 独吞 | 24h 无 P1；通道错误率低于阈值 | 值班签字 + 日志归档路径 |
Workspace 打包：边界、排除项与传输校验
Workspace 的目标是可复现的运行上下文，不是把整个 home 目录打成 tarball。建议拆包：配置与密钥引用（不含明文 secret）、锁文件、自定义脚本、小而稳定的静态资源。node_modules 优先在加拿大机上按锁文件重装，避免跨架构或超长路径打爆归档；若必须携带，请单独分包并记录 npm 平台标记。
rsync -avh --partial --checksum \ ./openclaw-workspace/ user@ca-m4-host:~/openclaw-workspace/
传输后在新机跑一轮 shasum 对关键文件的抽查；大包传输跨洋时务必限速，避免与 Gateway 争用峰值带宽导致误判为「服务不稳定」。上线后依赖冻结、滚动重启与磁盘日志水位可沿用站内「可控升级」手记同一套习惯，不必在迁移日新开一套口径。
Gateway 18789 切换：上游、token 与健康探针
确认文档与脚本里端口一致为18789（常见笔误 18879 会导致防火墙白放行错）。切换顺序建议：先让新机在本机 loopback 通过 health，再接 Tunnel/反代；不要把 DNS 先指过去再补 token。并行期用双上游或短时权重，并保留旧节点 10% 影子流量便于对比日志指纹。
LaunchDaemon 重建：plist、UserName、PATH 与日志落盘
交互式 SSH 与 launchd 子环境的 PATH 往往不一致；迁移时最常见的坑是「手动启动正常，重启后失联」。重建 plist 时核对：WorkingDirectory 指向新 workspace、StandardOutPath/StandardErrorPath 落在独立日志目录、必要时显式写入 EnvironmentVariables（PATH、NODE_OPTIONS、地区相关变量）。
launchctl bootout gui/$(id -u)/com.example.openclaw 2>/dev/null || true launchctl bootstrap gui/$(id -u) ~/Library/LaunchAgents/com.example.openclaw.plist launchctl kickstart -k gui/$(id -u)/com.example.openclaw
若是全局 LaunchDaemon（非 LaunchAgent），确认 UserName 与文件属主一致；权限漂移会导致「偶发写不了日志→进程假死」。
kickstart）：验证冷启动后 18789、通道握手与磁盘写入三步都能在无人工干预下恢复。
跨洋 SSH/VNC 验收矩阵与回滚扳机
SSH 适合脚本化探针与批量 tail；VNC 适合核验 GUI 授权、浏览器侧 webhook 调试与「看得见」的系统时钟/输入法状态。跨洋链路抖动时，先用同机 loopback 与跨 SSH 对比 RTT，避免把纯网络问题当成 Gateway 缺陷。
| 验收项 | SSH 侧重 | VNC 侧重 | 回滚扳机示例 |
|---|---|---|---|
| Gateway health | curl 脚本、定时探针 |
浏览器快速点验 | 连续 3 次探针失败且影子流量正常 |
| 通道握手 | 日志关键字斜率突增 | 桌面通知与权限弹窗 | 错误率 > 基线 3× 持续 15 分钟 |
| 磁盘与日志 | df、logrotate 状态 |
可视化存储压力 | 根卷 <12% 且自动降级无效 |
| 人机协作 | 批量 grep / jq | 与北美同事屏幕共读 | 业务方无法在窗口内完成一单闭环 |
回滚动作应预先写成一页纸：上游拨杆回到旧节点、冻结新机写入、保留新机日志用于复盘。不要在慌乱中删除 workspace——多数「迁移失败」实为单一环境变量未载入。
对照摘要：本地/旧节点 vs 加拿大 M4 新机
本地或旧云节点往往已有「顺手改动的全局 npm、遗留 LaunchAgent、旧 Tunnel 证书」；加拿大 M4 新机更像白纸，优势是可一次性对齐团队基线，代价是所有隐含依赖必须显式写进清单。把「曾经能跑」变成「任何人按工单能复现」，迁移才算完成。
实操上建议维护一张差异对照卡：旧节点记录「实际生效的环境变量来源」（shell profile、plist、CI 注入），新机则统一收敛到 plist 与单一 .env 引用，避免双轨配置。另将 webhook 与上游回调 URL 全部列出并标注 TTL，迁移当日只做映射切换不做即兴改名。北美同事参与验收时，提前约好 VNC 只读旁观账号与日志目录访问边界，减少临时 chmod 带来的权限隐患。
FAQ
迁移当天要不要换新 token？
不建议与迁移同一天耦合。若安全策略要求轮换，先在旧节点验证新 token，再进入 G2 并行；避免「迁移 + 密钥旋转」双变量。
18879 和 18789 哪个对？
OpenClaw Gateway 约定监听 18789。若文档出现 18879，按防火墙、plist 与上游路由三方做一次端口 grep，修正笔误后再验收。
可以把 node_modules 一起 rsync 吗？
可以但不优先。跨平台与符号链接差异会放大体积与故障面；推荐携带锁文件在加拿大机重装，仅在带宽极差且架构完全一致时例外。
旧节点什么时候关机最安全？
在 G3 独吞后至少观察一个完整业务周期（建议 ≥24h），且影子流量已归零、值班无未关闭事件，再执行关机；保留磁盘快照或镜像一周。
VNC 验收最该看什么？
系统时间、网络面板、钥匙串/浏览器证书提示、以及桌面弹窗是否被 launchd 任务掩盖——这些在纯 SSH 下容易漏检。
跨洋延迟高会不会拖垮 Gateway？
健康检查应在本机与小包路径完成；跨洋只影响你与机器的交互体感，不应成为 Gateway 本机失败的主因。若 health 失败伴随跨洋才出现，优先查 MTU、重传与中间 ACL。
回滚需要多久？
若上游拨杆与权重预案已写好，目标应在分钟级回到旧节点；长时间回滚通常卡在 DNS TTL 或未预演 Tunnel 切换。
LaunchAgent 和 LaunchDaemon 怎么选？
个人用户态服务多用 LaunchAgent；需要开机早期、全局守护时用 LaunchDaemon。无论哪种，都要用冷启动验证，而不是只看当前会话。
18789 并行切换 + LaunchDaemon 冷启动验证 + SSH/VNC 双通道验收 + 明确回滚扳机。把每一步落成闸门与留档，加拿大 M4 才能真正成为长期节点而不是临时跳板。