openclaw首次启动卡在“正在等待 gateway 就绪”是正常冷启动过程，需完成模型下载、gpu显存初始化、redis启动、vllm编译、配置加载五项并行操作，耗时1–3分钟；cpu高占用、磁盘活跃、显存已分配即属正常，切勿重启。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
OpenClaw首次启动时界面卡在“正在等待 Gateway 就绪”，看似停滞，实则是多层系统服务并行初始化的必经阶段——模型远程下载、GPU 显存上下文构建、Redis 依赖就绪、vLLM 引擎编译、环境变量热加载全部同步触发，任一环节延迟都会拖慢整体响应。
为什么第一次启动必须等1-3分钟
这不是程序卡死，而是 OpenClaw 在冷启动状态下强制执行五类不可跳过的底层操作：从 Hugging Face 下载基础大模型（通常 4.2–8.7GB）、用 CUDA 初始化 GPU 显存分配策略、启动 Redis 缓存服务并完成健康探活、编译 vLLM 推理引擎的 kernel 并绑定设备、生成并加载 ~/.openclaw/openclaw.json 中的 runtime 配置。这五件事无法串行压缩，且默认超时阈值设为 120 秒，低于实际耗时就会报错。
若你看到进度条不动但 CPU 占用率持续高于 65%、磁盘 I/O 活跃、nvidia-smi 显示显存已分配但未使用，说明它正在解压模型或编译 CUDA kernel——这是正常现象，【不要关闭窗口或强制重启】。
Gateway 就绪前的三个关键检测点
第一步：确认 Gateway 进程是否真在运行，而非假死
打开命令提示符（以管理员身份），进入 OpenClaw 安装目录（如 D:\OpenClaw），执行：openclaw gateway status --deep。如果返回 rpc: unreachable 或长时间无输出，说明 Gateway 虽启动但未进入事件循环。
第二步：检查端口 18789 是否被真实监听
执行：netstat -ano | findstr :18789。若无结果，说明 Gateway 绑定失败；若有结果但 PID 对应进程不是 openclaw.exe，说明端口被其他软件（如 Docker Desktop、旧版 Clash、某款远程控制工具）抢占。
第三步：验证 gateway.mode 配置是否生效
OpenClaw 跨平台配置备份与网关监控。自动备份 openclaw.json，每分钟检测 gateway 状态，宕机时自动恢复。支持 Linux/macOS/Windows。触发：配置备份、gateway 监控、自动恢复、看门狗、watchdog。
打开 %USERPROFILE%\.openclaw\openclaw.json，确认存在 "gateway": {"mode": "local"} 字段。若缺失或值为空，Gateway 将拒绝就绪，前端永远等待。
加速首次加载的实操干预路径
方法一：预下载模型包，绕过网络瓶颈
访问 https://huggingface.co/openclaw/model-v2.7.8/tree/main ，手动下载 model.safetensors 和 config.json 到本地；解压后放入 D:\OpenClaw\resources\models\default\（路径需与 .env 中 MODEL_PATH 一致）；再启动，跳过远程拉取阶段。
方法二：调高超时阈值，避免 prematurely abort
编辑 D:\OpenClaw\.env，将 REQUEST_TIMEOUT=120 改为 REQUEST_TIMEOUT=600；同时在 openclaw-config.yaml 中设置 gateway.timeout: 600 和 vllm.init_timeout: 480。
方法三：强制启用流式初始化，改善感知延迟
启动时追加参数：双击快捷方式 → 右键属性 → 目标栏末尾添加 --stream-init，例如："D:\OpenClaw\Openclaw Windows 一键启动.exe" --stream-init。这会让前端分阶段渲染 UI，不再黑屏等待。
