Windows 用 WSL2 部署 OpenClaw 与 systemd 常驻

1. 为什么 OpenClaw 这套东西值得放在 WSL2 里跑折腾过 OpenClaw 的人大概都有同一个感受这东西在 Windows 上不是装不上是装上之后到处都不对劲。我前后在原生 Windows、WSL2、以及一台闲置的纯 Linux 小主机上各跑过一轮最后长期留在 WSL2 上。所以这篇不打算写成一份“照抄就能跑”的命令清单而是把 Windows 下用 WSL 安装与配置 OpenClaw 这条路上哪些地方必须做、哪些地方可以偷懒、哪些地方一偷懒就翻车掰开揉碎讲一遍。先把话说在前面OpenClaw 这类自托管的开源助手网关本质是一个长期驻留的后台服务——它对外要保持和消息通道的长连接对内要维护会话状态、读写本地文件、偶尔调用模型接口。这种“常驻 有状态 跨进程通信”的形态天生和 Linux 的服务管理模型更合拍。你在 Windows 上当然能硬跑但你会发现它跟你熟悉的那些东西systemd、POSIX 权限、符号链接、inotify 文件监听全是错位的。WSL2 恰好把这些错位抹平了同时又保留了 Windows 的桌面体验。我第一次装的时候踩的最大一个坑是把整个项目 clone 到了/mnt/c/Users/xxx/projects下面。装依赖那一步卡了将近二十分钟我还以为是网络问题后来才知道是跨文件系统的 IO 开销——node_modules动辄十几万个小文件每读写一次都要穿过一层文件系统桥接。搬到 WSL 自己的 ext4 分区里同样的pnpm install两分半跑完。这个教训我后面会在目录规划那节再展开。所以这篇适合谁看三类人一是第一次碰 OpenClaw、想在自己 Windows 机器上跑起来的二是已经装上了但总有莫名其妙小毛病的三是准备把它当长期服务挂着、需要开机自启和日志排查的。基础的 Linux 命令我不逐条解释但每一步在干什么、为什么这么干我会说清楚。1.1 OpenClaw 到底是个什么形态的程序先把它的运行形态讲清楚后面所有配置取舍才有依据。OpenClaw 是一个自托管的开源个人助手网关用 Node.js 写的跑起来之后会在本机起一个服务进程对外听一个本地端口提供 Web 控制台对内挂若干条通道适配器——比如你常用的即时通讯软件、命令行会话、或者别的什么入口。消息进来之后它按你配置的规则路由到不同的会话上下文再决定调哪个模型、带哪些工具、回什么内容。这个形态决定了三件事。第一它必须有稳定的本地文件系统因为会话历史、凭证、日志都是落盘的而且经常是几十上百个小文件频繁读写。第二它必须有能被外部访问的网络入口你在 Windows 浏览器里打开http://localhost:端口要能看到控制台这一步靠 WSL2 的 localhost 转发就能白嫖。第三它必须能作为后台服务常驻不能你关掉终端窗口它就死了。我见过太多人卡在第三点上pnpm start在终端里跑得好好的一按 CtrlC 或者关掉 Windows Terminal服务没了然后开始怀疑是不是装错了。这不是装错了这是你把一个应该放进 systemd 的守护进程当成前台脚本在跑。1.2 原生 Windows 的三条路以及各自会卡在哪真要在原生 Windows 上跑路线无非三条我把它们和 WSL2 放在一起横向比一下方案优点主要问题适合场景原生 Windows Node装得快路径直观服务常驻要靠计划任务或第三方守护文件监听、符号链接、权限模型都与 Linux 侧不完全一致部分依赖可能触发原生模块编译只想临时试用几分钟原生 Windows 容器环境隔离干净文件挂载目录的读写性能同样会掉一档容器内访问宿主机服务的配置项不少调试链路变长已经有一套容器工作流的人WSL2 Ubuntu与官方部署文档基本一致systemd、权限、路径都对齐localhost 转发免费首次配置略繁琐内存和磁盘需要手动限额长期使用、跑后台服务纯 Linux 小主机最省心要额外一台机器或者双系统切换麻烦有闲置硬件我最后选 WSL2核心理由是它把“跟文档一致”这件事的成本降到了最低。官方文档写的是 Linux 路径、Linux 服务管理、Linux 环境变量那你就给它一个 Linux剩下的事全都不需要翻译。而 WSL2 的代价仅仅是一次性的限额配置写完.wslconfig之后就再也不用管了。1.3 整体架构先画在脑子里在动手之前脑子里得有一张图不然容易在细节里迷路。数据流大致是这样Windows 侧浏览器访问localhost:3000假设是这个端口WSL2 的 localhost 转发把它送到 Ubuntu 里的 Node 进程Node 进程用 systemd 拉起用户级服务配合 linger 保证没登录也能启动进程读写的数据落在 WSL 的 ext4 虚拟磁盘里也就是~/下面而你要编辑配置文件的时候既可以在 Ubuntu 里用nano也可以从 Windows 侧用 VS Code 的 Remote 打开两者操作的是同一份文件。理解这张图的价值在于出问题的时候你能快速判断是哪一层断的。浏览器打不开控制台可能是 Node 进程没起来也可能是起来了但只监听了 127.0.0.1 而没有走转发也可能是 Windows 侧防火墙拦了。这三件事的排查方法完全不同但表现症状一模一样。2. 开工前的环境盘点与目录规划动手之前先花五分钟盘一下自己的机器比装到一半发现版本不对再回滚要省事得多。这一节我把硬件要求、软件版本、目录结构一次性说清楚。2.1 硬件与系统版本的最低要求OpenClaw 本身不算吃资源但它是个“长期挂着”的服务加上 Node 生态的依赖体积实际占用会比你想的高一截。我给一张我实际测下来的参考表项目勉强能跑舒服说明物理内存8 GB16 GB 及以上WSL2 虚拟机会独占一部分宿主机还要留给浏览器磁盘剩余15 GB40 GB 及以上虚拟磁盘是动态增长的不会自动收缩CPU 核心2 核4 核及以上首次安装依赖时编译类任务吃核心Windows 版本支持 WSL2 的版本即可较新的 Windows 11较新版本对 systemd 与图形转发的支持更完整内存这块我建议提前算一笔账别等 WSL 把宿主机吃干净了再回头查。经验算法是给 WSL 分配的物理内存不超过宿主机总内存的一半且至少留 6 GB 给 Windows 本体。我手上这台是 32 GBWSL 给 12 GB剩 20 GB 给宿主同时开着浏览器、编辑器、几个聊天窗口都不紧张。如果你是 16 GB 的机器给 WSL 分 6 到 8 GB 比较合适8 GB 的机器就分 4 GB然后把宿主机上不用的东西关掉。磁盘也一样要提前想。WSL2 的虚拟磁盘文件ext4.vhdx只会长大不会自己缩小你删了文件它也不会还给你。跑一段时间之后从 10 GB 涨到 40 GB 是常态所以别把系统盘塞得太满。2.2 目录规划为什么我坚决不把项目放在 /mnt/c上面提过一次这里展开讲因为这是新手最容易做错、后果又最隐蔽的一步。Windows 的盘符在 WSL 里映射成/mnt/c、/mnt/d看起来很方便很多人顺手就把项目 clone 到那里。但/mnt/c走的是一层跨系统的文件桥接小文件随机读写的开销比原生 ext4 高一个数量级。node_modules是什么特征十几万个小文件、每个几百字节到几 KB、安装时全量写入、运行时高频读取。这正好是最吃亏的负载模式。我实测过同一个项目放在/mnt/c下装依赖用了十几分钟中途还因为文件锁问题失败过一次放到~/projects下两分半干净跑完。所以我的目录规划是这样的源码、依赖、数据、日志全部在 WSL 的~/下面具体点就是~/apps/openclaw。Windows 侧怎么访问用 VS Code 的远程连接或者直接在文件资源管理器地址栏敲\\wsl$\发行版名\home\用户名\apps\openclaw一样能看到、能编辑只是打开速度会慢一点点。编辑走 Windows 侧、运行走 WSL 侧这个组合是最舒服的。提示不要把数据目录也放在/mnt/c。会话历史和日志是持续写入的放在桥接文件系统上不仅慢还容易出现写入不完整。如果确实想备份到 Windows 盘用定时任务拷贝别直接把服务指向那里。2.3 先把该装的装齐需要的东西其实就三样WSL2 本体、一个 Ubuntu 发行版、一个顺手的终端。终端这块Windows 自带的终端用起来完全够标签页、分屏、字体都行没必要额外折腾。编辑器我推荐带远程能力的那个装个插件就能直接在 WSL 里开目录语法高亮和配置文件的 JSON 校验都能用上。有一点容易被忽略确认你的虚拟化功能是开着的。WSL2 底层依赖虚拟化如果 BIOS 里没开或者被某些安全软件拦了wsl --install会在最后一步报一个不太好懂的错。判断方法很简单WSL 装完之后跑wsl --status看默认版本是不是 2不是的话就是没走对路。3. WSL2 与 Ubuntu 的落地配置这一节是实操的第一段我尽量把每条命令的目的说清楚而不是让你无脑粘贴。3.1 一条命令装完 WSL2 与发行版现在的 Windows 已经把安装流程收得很紧了管理员权限的 PowerShell 里一条命令搞定wsl --install -d Ubuntu-24.04这条命令干了三件事启用 WSL 相关的可选组件、下载安装 WSL2 内核、拉取指定的 Ubuntu 发行版。跑完要重启一次重启之后会自动弹出一个 Ubuntu 窗口让你设用户名和密码。设密码的时候有个小细节输入时屏幕不显示任何字符不是卡住了是正常的。设完这个密码要记住后面所有sudo操作都要用。重启完先做个基础确认wsl --status wsl --list --verbose第一条看默认版本是不是 2第二条看发行版状态是不是 Running、版本是不是 2。如果--list显示版本是 1用wsl --set-version Ubuntu-24.04 2转一下不过转换过程会慢能重装就重装。顺手把 WSL 本体也更新一下新版本对 systemd、网络转发、磁盘回收的支持都更好wsl --update3.2 进系统之后的第一轮清理与设置进入 Ubuntu 之后别急着装 OpenClaw先把系统本身理顺。第一步更新软件索引sudo apt update sudo apt upgrade -y第二步设置时区。这一步看起来无关紧要实际上非常关键——OpenClaw 会记录会话时间戳、做消息去重、算定时任务的触发点。如果系统时间是 UTC而你以为它是本地时间那些按“每天几点执行”配置的任务会全部偏八个小时排查起来极其折磨。sudo timedatectl set-timezone Asia/Shanghai timedatectl第三步确认 locale避免后面某些工具输出中文或特殊字符时乱码sudo apt install -y locales sudo locale-gen en_US.UTF-8 zh_CN.UTF-8这一步做完你的环境就和一个正常的 Linux 服务器没什么区别了后面所有操作都可以直接参照官方 Linux 文档。3.3 开启 systemd这是后台常驻的前提这一节我认为是整篇里最不能跳过的一步。WSL 默认不启用 systemd没有 systemd 你就没法用systemctl管服务只能靠nohup或者screen硬撑那套东西在长期运行场景下非常不靠谱。开启方式是在 WSL 里编辑/etc/wsl.confsudo tee /etc/wsl.conf /dev/null EOF [boot] systemdtrue [interop] appendWindowsPathtrue EOF[boot]段开启 systemd[interop]段保留 Windows 路径的自动追加有些工具会用到。写完必须从 Windows 侧彻底重启 WSL只在 Ubuntu 里重启没用wsl --shutdown等几秒再重新进入验证一下systemctl --version ps -p 1 -o comm第二条命令应该输出systemd。如果输出的是init或者别的说明配置没生效回去检查文件路径和语法注意那两段方括号不能少。注意wsl --shutdown会杀掉所有 WSL 实例包括正在跑的服务。养成习惯重启之前先确认没有重要任务在跑。3.4 内存与 swap 限额别让 WSL 吃掉你的宿主机WSL2 默认会按宿主机内存的一个比例来分配这个默认值在老版本上比较激进容易让宿主机卡顿。解决办法是在 Windows 用户目录下建一个.wslconfig路径是C:\Users\你的用户名\.wslconfig内容[wsl2] memory12GB processors8 swap8GB swapFileC:\\Users\\你的用户名\\wsl-swap.vhdx localhostForwardingtrue逐行解释一下为什么要这么写。memory是虚拟机内存上限按前面说的“不超过宿主一半、至少留 6 GB”来定32 GB 机器给 12 GB、16 GB 机器给 6~8 GB。processors是虚拟 CPU 数量一般给物理核心数的一半到三分之二给太多反而会和宿主机抢。swap是交换分区给物理内存的一半左右比较稳太小了容易 OOM太大了掩盖内存泄漏问题。swapFile单独指定路径方便你以后清理。最后一行localhostForwardingtrue是重点它保证了在 WSL 里监听的端口Windows 侧用localhost就能直接访问不用去查那个每次重启都可能变的虚拟 IP。改完照样要wsl --shutdown重启才生效进去之后用free -h和nproc验证。4. Node.js 运行时与包管理器的选型安装OpenClaw 是 Node 项目运行时版本选不对后面会出各种语法层面的报错而且报错信息通常不会直白告诉你“版本太低”。4.1 为什么不用 apt 装 NodeUbuntu 仓库里的 Node 版本往往落后主线好几个大版本。用apt install nodejs装出来的版本很可能连项目要求的语法特性都不支持装依赖阶段就会报一堆看不懂的解析错误。而且 apt 装的 Node 和 npm 是打包在一起的版本被锁死想升级就得动系统包非常别扭。我选的是版本管理器方案好处是同一个系统里能共存多个 Node 版本切项目的时候nvm use一下就行永远不会互相干扰。具体用哪个版本管理器不重要nvm 生态最成熟fnm 更快但用得少一些看你顺手。4.2 装 Node 与锁定版本版本管理器一般通过安装脚本部署脚本下载下来执行就行。具体脚本地址官方仓库里都有我不在这里贴 URL你在项目发布页找到安装脚本用bash跑一遍它会往你的 shell 配置文件里写几行初始化代码。这里有个小提醒装完之后要么重开终端要么source ~/.bashrc不然nvm命令会提示找不到。我见过不止一个人在这里卡住以为装失败了。然后装 Node。版本上至少用当前活跃的 LTS 主线2026 年这个时间点建议直接上最新的 LTS。项目package.json里一般会写engines字段先看一眼那个再决定cd ~/apps/openclaw cat package.json | grep -A3 engines nvm install --lts nvm use --lts nvm alias default lts/*最后一行是设默认版本这样新开的终端自动就是它不用每次手动nvm use。4.3 包管理器优先跟项目走的那个Node 生态现在主流是 pnpm速度快、磁盘占用低很多新项目直接用它。判断方法很简单看项目根目录有没有pnpm-lock.yaml有就用 pnpm有yarn.lock就用 yarn有package-lock.json就用 npm。混用是会出事的——不同包管理器生成的依赖树结构不一样混着用会出现“本地能跑、重装就崩”的诡异现象。装 pnpm 有两条路我推荐用 Node 自带的 corepack 来开版本跟项目绑定更干净corepack enable corepack prepare pnpmlatest --activate pnpm -v如果 corepack 在你的 Node 版本上有问题退回到全局安装也行npm install -g pnpm这里提一个实际会遇到的场景如果你的网络访问公共包源比较慢可以给包管理器配一个离你更近的镜像源配置文件写在~/.npmrc里。这件事我只说方法具体地址你自己找配之前先ping一下确认可达。配完之后记得偶尔清一下缓存避免拿到过期的包元数据。4.4 什么时候才需要装编译工具链这一步很多人一上来就装其实不一定需要。只有当依赖里有原生模块需要node-gyp编译的那种才会用到build-essential、python3、make、g这一套。判断方法先不装直接跑依赖安装如果报错里出现gyp、node-gyp、make: command not found、Python not found这类关键词再补装sudo apt install -y build-essential python3 make g这样能省掉几百 MB 的无关依赖也让环境更干净。我第一次装的时候无脑把这一套装上了后来发现根本没用上纯属心理安慰。5. 拉源码、装依赖、跑起来环境准备好了进入正题。这一节是整篇的核心我把每一步的意图都写出来。5.1 获取源码与目录结构速览先把目录建好位置就在上一节说的~/apps下面mkdir -p ~/apps cd ~/apps git clone 项目仓库地址 openclaw cd openclawclone 下来先别急着装依赖花两分钟看一眼目录结构你对这个项目的理解会完全不一样ls -la一般来说你会看到这几类东西package.json和锁文件依赖定义、src或packages源码、docs或README.md文档、.env.example或config目录配置模板、以及可能的scripts目录构建和启动脚本。优先读package.json的scripts段这是最可靠的信息源比任何教程都准。你会看到build、dev、start之类的脚本它们分别对应什么动作直接决定了你后面怎么跑。我见过有人照着某篇旧教程敲了一个不存在的命令折腾半天其实只要看一眼scripts就明白了。5.2 依赖安装与构建几个脚本的真实含义装依赖pnpm install这一步会读锁文件、下载全部依赖、跑必要的 postinstall 钩子。第一次会比较慢几分钟到十几分钟都有可能取决于网络和机器。中间如果出现某些包的可选依赖安装失败比如某些平台专属的二进制包通常可以忽略不影响主流程。然后是构建pnpm build这一步在 TypeScript 项目里就是把src编译成dist里的 JS如果项目带前端控制台还会打包静态资源。很多人跳过这一步直接start结果报模块找不到——因为start跑的是构建产物产物不存在当然找不到。开发模式和生产模式要分清。pnpm dev一般是带热重载的改代码自动重启适合调试pnpm start跑构建好的产物适合长期运行。你要把它当后台服务挂用后者。5.3 配置文件的写法与关键字段这一步是真正决定“能不能用”的地方。项目通常会提供一个配置模板复制一份改成自己的cp .env.example .env或者有的项目用 JSON / YAML 配置文件位置一般在config/目录或者用户目录下的隐藏文件夹里。不管哪种形式核心字段无非这几类我按重要性排一下配置类别作用常见坑模型服务的接口地址与密钥决定它调哪个模型、用哪个账号密钥写错不会立刻报错而是等到第一次对话才失败监听端口与绑定地址决定控制台能不能从 Windows 侧访问绑到127.0.0.1之外的地址要注意暴露面数据目录会话历史、缓存落在哪指向/mnt/c会拖慢一切通道适配器配置接哪几个消息入口每个通道的鉴权方式都不一样别照抄日志级别出问题时调debug长期开debug会把磁盘写满配置写完之后先做一次语法校验。JSON 文件用编辑器自带的校验或者node -e JSON.parse(require(fs).readFileSync(config.json))这种土办法.env文件注意不要有多余空格和引号。配置文件的格式错误是最常见的启动失败原因而且报错信息往往指向很奇怪的位置让你以为是代码问题。注意.env里存的是密钥务必确认它被写进了.gitignore。我见过有人在 fork 之后直接把密钥提交上去虽然后来删了但历史记录里还在。5.4 首次启动与控制台验证前面都顺了可以先在前台跑一次看看日志输出pnpm start正常情况下你会看到一串启动日志加载配置、初始化数据库、启动 HTTP 服务、连接各个通道。盯着看有没有error或者warn级别的输出尤其是通道连接那一块很多通道连不上会一直重试日志会反复刷同一段内容。跑起来之后另外开一个终端验证端口ss -ltnp | grep node应该能看到你的 Node 进程监听在某个端口上。然后在 Windows 的浏览器里打开http://localhost:那个端口能看到控制台界面就说明整条链路通了。如果浏览器打不开按这个顺序排查先在 WSL 里curl -I http://127.0.0.1:端口看服务本身通不通通了再看绑定的地址是不是0.0.0.0或者::绑127.0.0.1在部分配置下转发会失效最后看 Windows 侧防火墙有没有拦。这个顺序能帮你省掉大量瞎猜的时间。6. 让它长期稳定驻留守护进程与日志前台跑通只是“能用”离“好用”还差一步。真正的目标是关掉终端它还在跑重启电脑它自己起来出问题你知道去哪看日志。6.1 前台、nohup、systemd 三选一我列一下三者的差别你就知道为什么必须上 systemd方式关终端后开机自启崩溃重启日志管理前台pnpm start进程退出无无终端里滚动关了就没nohup ... 存活要手写启动项无重定向到文件得自己切分systemd 用户服务存活支持支持journald 统一管理可查历史nohup看起来能用但它没有崩溃重启也没有日志轮转进程悄悄死掉你都不知道。既然 WSL 里已经开了 systemd就用它。6.2 用户级 systemd unit 的完整写法因为这是个人环境不需要 root用用户级服务最合适。先建目录mkdir -p ~/.config/systemd/user然后写 unit 文件~/.config/systemd/user/openclaw.service[Unit] DescriptionOpenClaw Gateway Afternetwork-online.target Wantsnetwork-online.target [Service] Typesimple WorkingDirectory%h/apps/openclaw ExecStart/bin/bash -lc pnpm start Restartalways RestartSec5 StandardOutputjournal StandardErrorjournal EnvironmentNODE_ENVproduction [Install] WantedBydefault.target几处值得单独说。WorkingDirectory%h/apps/openclaw里的%h是当前用户家目录的占位符比写死绝对路径更省事。ExecStart用/bin/bash -lc包一层很关键——因为pnpm是通过版本管理器装到 shell 环境里的systemd 直接调会找不到命令-lc让它走一次登录 shell把PATH加载进来。这个坑我踩过报错是pnpm: command not found但你在终端里手动敲明明是有的。Restartalways加RestartSec5是让它崩了自动拉起来但别设成 0 秒否则一个必然启动失败的配置会让你陷入疯狂重启。启用并启动systemctl --user daemon-reload systemctl --user enable --now openclaw systemctl --user status openclaw6.3 让服务在没登录时也能跑这一步是用户级服务的专属坑。默认情况下用户级服务会随用户会话结束而停止而 WSL 在没有活动终端的时候会认为会话结束了。解决办法是开启 lingerloginctl enable-linger $USER开启之后即使你不开任何终端服务也会保持运行。验证方法把终端全关掉从 Windows 侧wsl -d Ubuntu-24.04 -- ps aux | grep node看一眼进程还在不在。6.4 日志的三个查看入口出问题的时候看日志的顺序决定了排查效率。我一般按这个顺序来第一步看服务状态systemctl --user status openclaw它会告诉你进程在不在、最近几行输出是什么、退出码是多少。如果看到status1/FAILURE配上某段错误基本直接定位。第二步看实时日志journalctl --user -u openclaw -f-f是持续跟踪。调配置的时候我会一直开着这个窗口改完重启服务日志立刻就能看到反应。第三步看历史日志journalctl --user -u openclaw --since 1 hour ago或者--since today。有些问题是间歇性的得回溯才能看出规律比如每隔半小时报一次错那多半是某个定时任务或心跳超时。再加一个实用技巧journalctl默认会分页按q退出很多人第一次用以为卡死了。日志量大的时候加上--no-pager | tail -100更顺手。7. 排障实录与升级回滚前面几节是“顺利路径”这一节讲“不顺利的时候”。我把这两年反复遇到的、以及帮别人看过的典型问题整理出来。7.1 高频问题速查表现象最可能的原因处理方式pnpm: command not found服务里systemd 没加载 shell 环境unit 里用bash -lc包一层浏览器打不开控制台绑定地址不对 / 服务未启动curl 127.0.0.1:端口分层验证装依赖极慢或失败项目在/mnt/c下迁到~/下重装关终端后服务停了没开 lingerloginctl enable-linger $USER磁盘越用越满虚拟磁盘不会自动收缩清理后手动压缩 vhdx日志里时间戳对不上时区没设timedatectl set-timezone文件改动了但不热重载inotify 监听数上限调高fs.inotify.max_user_watches突然大量网络请求失败WSL 长时间休眠后时钟漂移重启 WSL 或同步时间7.2 几个我印象深刻的坑时钟漂移。笔记本合盖休眠一整晚第二天打开WSL 里的系统时间可能还停在昨晚。表现是什么调用外部接口时握手失败日志里是一堆看起来毫无关联的超时错误或者消息时间戳全部错乱导致去重逻辑把新消息当成旧的丢掉。这个问题的恶心之处在于它不会自报家门。我现在养成的习惯是只要笔记本休眠过进 WSL 第一件事就是校准时间或者干脆wsl --shutdown重来一次。文件监听失效。OpenClaw 在开发模式下会监听配置文件和会话目录的变化。监听数不够的时候它不报错只是默默不响应改动你会以为是自己改错了地方。调高上限echo fs.inotify.max_user_watches524288 | sudo tee -a /etc/sysctl.conf sudo sysctl -p内存被慢慢吃光。长期运行的服务最容易出这个问题尤其是缓存不设上限的那种。表现是跑几天之后宿主机开始卡free -h一看 WSL 里内存快满了。这时候别急着怪 OpenClaw先看看.wslconfig里的上限是不是设得太大再检查日志级别是不是一直开着debug。日志膨胀和内存膨胀经常是同一个原因。端口被占。有时候你会遇到“服务启动成功但访问报错”其实是上一次的僵尸进程还占着端口。ss -ltnp | grep 端口查出来 PIDkill掉再启动。如果频繁出现说明 systemd 的重启策略和服务自身的退出处理有冲突得去看看Restart配置。7.3 升级与回滚的稳妥做法OpenClaw 这类项目迭代很快隔一阵就有新版本。升级之前我固定做三件事做完再动手出问题十分钟内能恢复。第一件记下当前版本。git log -1 --format%H %ci或者git describe --tags把这行输出存到笔记里。第二件打一个本地标签快照git tag backup-$(date %Y%m%d)这样回滚就是一条命令。第三件备份数据目录和配置文件尤其是.envcp -r data ~/backup/data-$(date %Y%m%d)。然后才升级git fetch --all --tags git checkout 目标版本标签 pnpm install pnpm build systemctl --user restart openclaw journalctl --user -u openclaw -f升级后必须盯一会儿日志别重启完就关窗口。新版本最常见的问题是配置字段改名或新增必填项日志里会明确告诉你哪个字段缺了。看到这种提示别慌对照新版本的配置模板补上就行。回滚更简单git checkout backup-20260101 pnpm install pnpm build systemctl --user restart openclaw依赖也要重装因为不同版本的锁文件内容不一样光切代码不切依赖一样会崩。我个人在实际操作中的体会是这套东西真正难的不是哪一条命令而是搞清楚每一层在负责什么。Windows 负责终端和浏览器WSL 负责跑 Linux 进程systemd 负责让它活着Node 负责跑业务逻辑配置文件决定它连哪儿。任何一次故障先定位是哪一层出了问题再去那一层找答案比盲目重装快十倍。我最开始那几次“装坏了就删了重来”事后回头看八成的问题都出在.wslconfig和 unit 文件那两个地方改两行就好了。最后分享一个我一直在用的小习惯在~/apps/openclaw下放一个NOTES.md每次改了什么配置、遇到什么问题、怎么解决的随手记一行。这东西看着土但等你三个月后回来改配置或者换台机器重装的时候它就是最靠谱的文档——比任何教程都贴合你自己的环境。