openclaw源码解读（5）——server.impl.ts 真正的启动引擎 第三阶段：网络栈启动（HTTP + WS）

├─ loadGatewayTlsRuntime() // ⑩ TLS 加载（可选）

│

├─ createChannelManager() // ⑪ 通道管理器（discord/telegram/wecom...）

│

├─ createGatewayRuntimeState() // ⑫ 核心：HTTP/WS 服务器创建 ⭐⭐

│ ├─ Canvas Host（画布托管）

│ ├─ 为每个 bindHost 创建 HTTP server

│ │ ├─ Control UI 路由

│ │ ├─ OpenAI Chat Completions 路由

│ │ ├─ Hooks 路由

│ │ ├─ Plugin HTTP 路由

│ │ └─ 认证中间件 + Rate Limiter

│ ├─ new WebSocketServer({ noServer: true })

│ ├─ attachGatewayUpgradeHandler() → HTTP Upgrade → WS

│ └─ startListening() → 绑定端口

L1118-1120

加载gateway的tls。加载 gateway 的 TLS 运行时状态（证书/密钥是否可用等），不在 startup trace 里做耗时统计。

L1121-1123

配置说"启用 TLS"，但运行时加载失败（证书文件不存在、权限问题等），直接抛异常。这两个 enabled 不是"互斥"，而是配置期望 vs 运行时现实不一致——配置说能开，实际开不了。

L1124-1135 你跳过的中间变量

几个重要变量值得注意：

• startupSidecarsReady：标记所有 sidecar（通道等）是否已就绪，minimalTestGateway 模式下直接跳过
• startupAccountStartsReady：一个 Promise，用于延迟通道的自动启动，等 sidecar 都好了再放行
• gatewayInstanceDispatchReady：标记 gateway 实例是否可接收请求（bind 之后才翻 true，关闭时翻 false）

L1137-1151

创建通道管理器，通过获取运行时配置、通道日志、通道运行环境变量等所有相关信息，来建立通道管理器。

L1152

控制通道是否自动启动（比如--channel-autostart-suppression标志）。

L1159-1165

创建验证器，验证是否已经准备好，验证项包括：通道管理器（L1156）、gateway启动是否未完成(L1158)、启动未完成的原因（L1159）、获取event loop的健康状态快照（L1160）、如果运行中的环境变量中OPENCLAW_SKIP_CHANNELS/OPENCLAW_SKIP_PROVIDERS为true，则跳过通道检查

L1162-1164

createReadinessChecker返回一个getReadiness函数，检查项包括你说的那些。其中shouldSkipChannelReadiness的逻辑是：如果环境变量OPENCLAW_SKIP_CHANNELS或OPENCLAW_SKIP_PROVIDERS为 truthy，就跳过通道就绪检查。

L1166

这行只是打日志，实际的 HTTP 服务器创建还在后面的createGatewayRuntimeState里。你可以理解为"准备创建 HTTP 服务器"，真正绑端口、启动 HTTPS/WS 都在createGatewayRuntimeState内部完成。

L1167

这不是"获取 gateway 请求上下文"，而是声明一个变量，后面才会赋值。它是一个可变引用——每次请求进来时更新当前的 context。

L1168-1170

这不是"观察请求的 request 和 response"，而是声明了一个延迟绑定的处理器对象。.current字段初始为undefined，等 watch-node HTTP runtime 创建好后（约 L1308）才会赋值。

L1171-1232

创建gateway运行时状态。包括基本信息，以及gateway 钩子的配置、钩子客户端ip的配置、注册插件、注册插件路由、gateway请求上下文、如果不是最小测试那么也注册通道等

L1171-1232：createGatewayRuntimeState 的完整参数分析

L1228-1230：你问的这两行

handleWatchNodeRequest: async (req, res) =>

(await watchNodeRequestHandler.current?.(req, res)) ?? false,

这是一个延迟绑定的 HTTP 请求代理处理器。运行机制：

1. 创建时：watchNodeRequestHandler.current 是 undefined
2. 后面约 L1308：watchNodeRequestHandler.current = watchNodeHttpRuntime.handleRequest; 才绑定真正的处理函数
3. 运行时：每次有 HTTP 请求进来，如果路由匹配到 watch-node 路径，就转给 watchNodeRequestHandler.current 处理
4. ?? false：如果处理器不存在或返回 undefined，返回 false（表示"这个请求我没处理"）

为什么要用这种间接模式？因为 createGatewayRuntimeState 创建 HTTP 服务器时需要这个 handler，但真正的 watch-node HTTP runtime 依赖 HTTP 服务器创建后才能初始化——形成了循环依赖。用 .current 对象做中间层打破这个循环。

L1233 resolveWorkerGatewayEndpoint = getWorkerIngressEndpoint;

//保存 worker 入口地址，供 worker 环境服务使用

L1234 const restartRecoveryCandidates = new Map();

// 热重启时，保存可恢复的会话候选

L1235-1261 createGatewayNodeSessionRuntime({...})

// 创建「节点会话运行时」

// 管理连接到 gateway 的节点（手机、IoT 设备等）

// 返回：nodeRegistry(节点注册表)、nodeSendToSession(向节点发消息)、 nodeSubscribe/unsubscribe(订阅管理)、broadcastVoiceWakeChanged 等

L1255-1295 createWatchNodeHttpRuntime({...})

// 创建「watch-node HTTP 运行时」

// 处理节点的 HTTP 连接生命周期：

// - onNodeConnected: 节点上线 → 记录到 presence、更新 remoteNodeInfo

// - onNodeDisconnected: 节点下线 → 标记 presence、清理订阅、清除 wake 状态

// - onError: 打 warn 日志

// L1296: 关键一行！把真正的 handler 绑定到延迟引用

watchNodeRequestHandler.current = watchNodeHttpRuntime.handleRequest;

L1300-1323— 最后的运行时组件

L1297-1305 TerminalSessionManager

// 创建「终端会话管理器」

// 管理 PTY 终端会话（如 SSH 到远程机器）

// detachedSessionTimeoutSeconds 控制断连后终端保留多久(断连超时时间)

L1306 applyGatewayLaneConcurrency(...)

// 应用 gateway 并发通道（lane）限制配置同时处理的请求数(并发数）

L1308-1317 runtimeState = createGatewayServerLiveState({...})

// 创建 gateway 的「运行时状态」对象（之前只是声明变量）

// 包含：hooks 配置、cron 状态(懒加载)、活跃的 gateway 方法列表等L1318 deps.cron = runtimeState.cronState.cron;

// 把 cron 实例注入依赖图，其他模块可以通过 deps 访问

L1319 pluginHostServices 目前只有一个 cron getter

L1319-1323 const pluginHostServices = {...}

//开始构建「插件宿主服务」对象，将 cron 实例注入依赖容器，其他模块可通过 deps.cron 访问

// 插件宿主服务——给插件提供的托管能力容器，目前只有 cron，后续可能扩展

整体来看，核心主题是：HTTP 服务器已经创建好了，现在要组装所有运行在它之上的子系统——节点连接、终端会话、插件服务、cron 调度等，最后绑定到一个统一的 runtimeState 对象里。

好了，看得很清楚了。L1300 之后的代码可以分为几个清晰的阶段。我按逻辑块来解析

正在规划《OpenClaw源码解读》书籍，欢迎出版社编辑交流