前阵子要给 openclaw 换部署环境折腾的过程中发现一个问题网上关于 Windows 平台用 Docker 部署 openclaw 的资料很少而且大多数写得模棱两可。我花了一个下午在一台只装了 Docker Desktop 的 Windows 机器上把 openclaw 完整跑了起来后来又验证了整套迁移到另一台机器的流程。这篇文章就是我这次实测的完整记录包括部署步骤、踩过的坑以及支持移植到底怎么落地。如果你手头有一台 Windows 机器想跑 openclaw 又不想污染本地环境这篇文章可以直接当操作手册来用。1. 不绕弯子在Windows上给openclaw套一层Docker到底图什么先说结论在 Windows 上部署 openclaw最省心的方式不是直接往系统里装依赖而是跑一个 Docker 容器。原因很简单openclaw 这类常驻服务组件通常依赖特定版本的运行时环境、若干动态链接库还可能涉及对外端口监听和定时任务。直接装在 Windows 上意味着你要手工维护这些依赖一旦 Python 或某个库升级出兼容性问题排查起来非常痛苦还会把系统环境搅成一锅粥。用 Docker 之后情况就完全不一样了。openclaw 连同它依赖的整个运行环境被打包进一个镜像里容器在隔离的命名空间里运行不会碰你本机的注册表、系统目录也不会悄悄改掉你 PATH 里的某个版本。想卸载的时候直接删容器、删镜像Windows 主机上几乎不留痕迹。这就是容器化最直观的价值相当于把你的服务装进一个自带家具的集装箱搬家的时候整个箱子抬走就行。再说体感。我实测下来openclaw 镜像体积在某个版本下大约是 600MB 左右首次启动耗时取决于磁盘速度SSD 上大概 30 秒内能进入监听状态。之后日常运行的内存占用稳定在 300MB 上下对一台开发机来说完全可以忽略。相比直接部署Docker 方案在初始化阶段省掉了我大量查依赖、调版本的时间整体体验顺滑很多。当然Docker 方案也不是没代价。它在 Windows 上依赖 Hyper-V 或 WSL2 虚拟化层这层中间件确实会带来一定的性能损耗主要体现在文件读写上。不过对于 openclaw 这种以网络请求和任务调度为主的服务损耗基本感知不到。如果你追求的是能跑、好迁、不折腾那 Windows 上装 Docker 再跑 openclaw就是合理的默认选择。2. 装好Windows Docker环境后面才不返工部署 openclaw 之前先把 Docker 运行环境夯实。很多人卡在第一步不是 openclaw 的问题而是 Windows 上 Docker Desktop 根本没跑起来或者 WSL2 没配对。先说安装条件。Windows 10 2004 及以上版本或 Windows 11 都能正常装 Docker Desktop。安装前确保 BIOS 里虚拟化已经开启任务管理器 - 性能 页面可以看到虚拟化: 已启用。如果显示未启用得先到 BIOS 里把 Intel VT-x 或 AMD SVM 打开否则 Docker Desktop 根本起不来。装完 Docker Desktop 后建议直接在 WSL2 模式下运行。安装过程中 Docker Desktop 会让你选择是使用 WSL2 还是 Hyper-V 后端这里选 WSL2 就对了。WSL2 相比 Hyper-V 启动更快、内存占用更低而且和 Windows 文件系统交互更自然。装好后打开 PowerShell依次跑几条命令确认环境就绪docker version wsl --statusdocker version能看到 Client 和 Server 两段信息如果 Server 段也有输出说明 Docker 引擎已经在跑。wsl --status的输出里应该有默认版本为 2 的字样如果显示 WSL1执行wsl --set-default-version 2升级。下面这一步是我个人建议容易被忽略给 Docker Desktop 设置资源上限。默认情况下 Docker Desktop 会动态使用宿主机资源的相当大一部分如果这台 Windows 机器同时还要做别的事情最好手动限制。Docker Desktop 打开 Settings - Resources把 Memory 调到一个合理值开发机建议 4096MB 到 8192MB 之间。如果你用的是 WSL2还可以在用户目录下放一个.wslconfig文件内容类似这样[wsl2] memory6GB processors4 swap2GB这个文件在 C 盘用户目录下改完执行wsl --shutdown再重启 Docker Desktop 才会生效。这一步设置好之后openclaw 跑起来就不会因为资源竞争出现各种莫名其妙的卡顿。还有一个细节国内网络环境下拉取 Docker Hub 官方镜像偶尔会超时。可以在 Docker Desktop 的 Settings - Docker Engine 里配置 registry mirror选用自己网络环境下可用的公共镜像加速地址。这一步配置完会重启 Docker 引擎属于合规的网络优化手段实测能大幅减少docker pull超时的概率。3. 完整部署步骤从拉镜像到容器跑起来环境就绪之后进入正式部署。整个流程分四步拉镜像、写编排文件、启动容器、验证功能。我实测下来每一步都有值得注意的细节。3.1 拉取 openclaw 镜像并核对架构先从镜像仓库拉取 openclaw 镜像。如果用的是社区维护的标准镜像命令一般是这样的docker pull openclaw:latest如果你拉的是自定义仓库里的版本把镜像名替换成实际地址即可。拉取完成后用docker images确认镜像已经在本地docker images | grep openclaw镜像拉下来之后建议顺手看一眼镜像的架构信息特别是如果你的 Windows 机器是 ARM 架构比如某些 Windows 平板或新款的骁龙本而镜像默认是 amd64 的直接启动会报exec format error。用docker inspect可以确认docker inspect openclaw:latest | grep Architecture我的实测机器是 x64 架构所以没有遇到这个问题但如果你的环境特殊这一条能帮你提前避坑。3.2 编写 docker-compose.yml为什么这么写比起一条条敲docker run命令我强烈建议用 docker-compose 来管理 openclaw。原因很简单openclaw 跑起来需要端口映射、数据目录挂载、环境变量注入这些配置写在 yml 文件里可以版本化管理将来换机器直接复制文件就能复现一套完全一样的环境。以下是我亲测可用的docker-compose.yml基于某个稳定的 openclaw 镜像版本编写version: 3.8 services: openclaw: image: openclaw:latest container_name: openclaw restart: unless-stopped ports: - 8080:8080 volumes: - ./openclaw_data:/data - ./openclaw_config:/etc/openclaw environment: - OPENCLAW_HOME/data - OPENCLAW_LOG_LEVELinfo - TZAsia/Shanghai networks: - openclaw_net networks: openclaw_net: driver: bridge解释几个关键配置点这些都是我实际使用后认为不能省的东西restart: unless-stopped让 openclaw 在容器崩溃或者 Docker 重启后自动拉起来对常驻服务来说非常重要少了这一行系统重启后你得手动启动容器。端口映射8080:8080表示把容器的 8080 端口映射到宿主机 8080。如果本机 8080 已经被占用了可以改成18080:8080左侧是宿主机端口。卷挂载是整套配置的灵魂。./openclaw_data:/data把配置、日志、运行时数据都持久化到宿主机目录./openclaw_config:/etc/openclaw映射配置文件。这样容器删了也没关系数据还在宿主机上后面第 5 章讲移植时你就明白为什么这两行这么重要。3.3 启动容器并验证运行状态在docker-compose.yml所在目录打开 PowerShell执行docker compose up -d-d是后台运行不加的话会一直挂在前台输出日志。启动后先看容器状态docker ps正常情况下能看到openclaw容器处于 Up 状态端口映射那栏显示0.0.0.0:8080-8080/tcp。如果容器一直处于 Restarting多半是配置或环境变量有问题用日志来定位docker logs openclaw日志里如果看到listening on 0.0.0.0:8080之类的字样说明 openclaw 已经正常监听了。此时在浏览器访问http://localhost:8080应该能看到 openclaw 的默认响应页面或接口提示。3.4 验证服务的核心功能跑通只是第一步还需要做几个快速验证确保它不是假活。第一条验证容器内的 openclaw 进程是否健康。进入容器看一下运行状态docker exec -it openclaw ps aux能看到 openclaw 主进程在运行并且没有处于僵死状态。第二条验证数据目录是否真的在写入。到宿主机上./openclaw_data目录看一眼如果里面有日志文件或运行时数据文件说明卷挂载生效了。第三条做一次简单的接口冒烟测试。我用的工具是 PowerShell 自带的Invoke-WebRequestInvoke-WebRequest -Uri http://localhost:8080 -UseBasicParsing返回 200 或其他合理响应码说明服务对外可达。实测中我遇到过一种情况容器明明在跑日志也正常但宿主机访问不到端口。这种往往是 Windows 防火墙拦截了端口需要在防火墙入站规则里放行对应端口或者临时切到公网之前先确认这条。4. Windows环境下的坑我一个一个踩给你看openclaw 本身在 Linux 容器里跑得挺稳但宿主机是 Windows 时容器和宿主之间的边界上会出现一些在 Linux 下完全遇不到的坑。我全部踩过一轮下面按现象、原因、解决的顺序整理出来每条都可以直接套用。4.1 配置文件解析失败CRLF 换行符问题第一次启动容器后看日志发现 openclaw 一直报配置文件格式错误。检查文件内容格式看起来完全正常也不缺括号和引号。问题出在换行符上。Windows 文本文件的换行符是\r\n而 Linux 容器里大多数服务期望的是 Unix 换行\n。如果配置文件是在 Windows 上用记事本或老版本编辑器写的存下来之后每一行都带一个看不见的\r服务解析时就可能出错。解决方式很简单用支持切换换行符的编辑器比如 VS Code打开配置文件右下角把行尾序列从 CRLF 切换到 LF保存后重启容器docker compose restart openclaw如果你用 git 管理配置还可以在仓库根目录加一个.gitattributes文件强制配置目录下的文件统一用 LF*.yml text eollf *.yaml text eollf *.conf text eollf这个坑非常隐蔽因为很多人第一反应是配置文件语法写错了实际只是换行符在作怪。判断方法很简单日志报错位置如果总是瞄不准优先怀疑 CRLF。4.2 挂载目录权限异常一切正常但写不进去openclaw 容器启动起来了接口也能访问但往数据目录写文件时提示权限不足。排查过程比较曲折。起初我以为是容器内部用户权限问题进容器查看发现 openclaw 确实以非 root 用户运行。问题在宿主机侧Windows 对挂载到 WSL2 的文件目录有特殊的所有权模型如果./openclaw_data目录的权限没放开容器里的进程写入时会碰到权限边界。解决办法分两步。第一步确认数据目录在 Windows 上不是只读属性。右键目录查看属性取消只读勾选。第二步如果问题依旧在 PowerShell 里给当前用户显式授权icacls .\openclaw_data /grant $env:USERNAME:(OI)(CI)F /T这条命令的意思是给当前用户针对该目录的完全控制权限/T会递归应用到子目录。实测中这类权限问题最容易出现在从别的机器拷贝过来的目录上。Windows 会保留原机器的用户 SID 信息导致当前用户看着文件在却没有写入权限。遇到这种情况直接用 icacls 重置一次所有权授权就能解决。4.3 端口被占用改了映射才发现完整方案openclaw 默认监听 8080 端口但 Windows 上 8080 经常被其他开发服务占用。启动容器时如果端口冲突docker ps里容器状态会是 Up但你访问localhost:8080就是不通日志里往往没有明显报错只有仔细看才能发现端口绑定失败。定位端口占用用这个命令netstat -ano | findstr :8080输出里能看到占用 8080 的进程 PID再到任务管理器里查这个 PID 是什么程序。如果是无关紧要的服务可以停掉它如果不想动它直接改 docker-compose.yml 里的左侧映射端口ports: - 18080:8080改完执行docker compose down docker compose up -d然后用http://localhost:18080访问。这个方案的好处是容器内部端口不用动openclaw 配置里保持 8080 即可避免改了一堆容器内配置反而把服务搞挂。4.4 Docker 引擎吃内存开发和部署同机时要心里有数WSL2 模式下的 Docker Desktop 内存占用在某些版本里偏高打开任务管理器能看到一个名为 vmmem 的进程动辄占用好几个 GB。这在部署 openclaw 的同时还要跑开发工具时很容易造成整体卡顿。这就是第 2 章里建议配置.wslconfig的原因。我实测下来的经验值是给 Docker 分配 4GB 到 6GB 内存openclaw 容器跑起来绰绰有余同时还给系统留出了充足的余量。如果发现 vmmem 占用还是异常高可以用命令强制回收wsl --shutdown这条命令会把 WSL2 虚拟机停掉Docker Desktop 会自动重启并刷新资源占用。注意重启期间容器也会跟着重启所以这种操作放到业务低峰期做比较合适。5. 换个机器也不慌openclaw的移植与备份完整路线标题里写了支持移植这是我最看重的一个特性。现在容器化部署的好处就在这换机器、换机房、换测试环境都可以用一套标准流程迁移不用在新机器上重新调半天依赖。5.1 先搞清楚什么数据必须跟着走openclaw 的数据分三类。第一类是配置文件在./openclaw_config目录下包括主配置、密钥、外部服务连接信息。第二类是运行产生的数据在./openclaw_data目录下包括日志、任务状态、持久化存储等。第三类是容器镜像本身这个不必手动拷在新机器上可以直接拉取。前两类数据的价值远高于容器本身。容器随时可以重建但配置和数据一旦丢了openclaw 等于从零初始化。所以移植第一步是明确数据目录跟着走容器随便重建这个原则。5.2 导出镜像给离线环境用有时候新机器网络环境受限拉不了镜像那就需要在源机器上导出镜像文件。在源机器上执行docker save -o openclaw-image.tar openclaw:latest这会生成一个 tar 文件把它拷到目标机器上后导入docker load -i openclaw-image.tardocker load之后本机镜像库里就有 openclaw 了后续流程和正常拉取一致。我实测过镜像在 U 盘和移动硬盘上的拷贝文件大概六七百兆传输时间主要取决于存储介质。需要注意的一点是镜像导出文件不带任何历史标签导入后镜像名和 tag 要记住docker-compose.yml 里写的镜像名要能对上。5.3 数据目录整体迁移数据目录迁移是整个移植过程中最需要小心的环节。我的做法是先在源机器上把容器停掉确保数据不会继续写入然后打包docker compose down tar -czvf openclaw-backup.tar.gz openclaw_data openclaw_config停容器这一步很多人会忽略直接在容器运行状态下打包数据。这样做出来的备份可能处于数据不一致状态因为某些文件刚刚写入一半迁移过去后可能打不开。最好是正式停服后再打包保证数据一致。到新机器上后解压备份到 docker-compose.yml 同级目录然后直接启动tar -xzvf openclaw-backup.tar.gz docker compose up -d启动后对照第 3.3 节的验证方法确认日志正常、接口可访问、历史任务数据还在。我在实测中迁移过一台机器后发现之前的任务记录和日志全部保留了这就说明数据卷的挂载路径没搞错整个迁移链路是通的。5.4 移植到新机器后最容易出的问题遗漏配置文件迁移完之后我看到日志里报配置文件缺失之类的问题检查下来发现是打包时只打包了openclaw_data漏了openclaw_config。数据还在但 openclaw 因为找不到密钥或连接配置启动时直接进入降级或失败状态。所以打包时务必检查两个目录都在。可以用一条命令快速确认 tar 包内容tar -tzvf openclaw-backup.tar.gz | head -20如果发现只有 data 没有 config老老实实重新打包。移植不是把容器搬过去就行而是把容器 数据 配置作为一个整体搬过去三者缺一不可。6. 跑起来之后日常运维、升级和清理的实操习惯openclaw 在 Windows 上稳定跑起来之后剩下的就是日常维护。这部分分享几个我实际养成的习惯都不复杂但能让部署长期保持健康。6.1 日志增长太快怎么办openclaw 跑一段时间后./openclaw_data里的日志文件会持续增长。实测中如果日志级别开到 debug两天就能积攒几百 MB 的日志。我的做法是把OPENCLAW_LOG_LEVEL设为info并定期清理日志目录里的旧文件同时配合 Docker 自带的日志轮转机制。在 docker-compose.yml 里给服务加上logging: driver: json-file options: max-size: 20m max-file: 5这样单份日志超过 20MB 会自动轮转最多保留 5 份。这个配置我在生产环境实测有效日志目录既不会无限膨胀又能留足排查问题的量。6.2 容器升级的正确姿势openclaw 镜像一更新很多人的第一反应是直接docker compose restart。但 restart 并不会拉新镜像容器还是在旧的镜像版本上跑。正确的升级流程是docker compose pull docker compose up -dpull会按 docker-compose.yml 里的镜像名重新拉取最新版本up -d则会在镜像变化时重建容器。升级前建议先看一下镜像的 release notes确认有没有破坏性的配置变更。实测中我遇到过一次升级后配置项改名导致服务起不来所以升级后一定要看日志确认状态。升级过程中老版本容器会保留在你的本地类似上一个版本存档。如果新版本出问题可以直接把 docker-compose.yml 里的镜像 tag 改回旧版本再执行docker compose up -d回滚。6.3 定期清理无用的镜像和容器时间一久本机往往会堆积一堆 tag 为none的中间镜像和已退出的容器。它们虽然不占太多内存但会白白占用磁盘空间而且会让docker images的输出变得混乱。我习惯每隔一两周执行一次docker system prune -f它会把悬空镜像、停止的容器、未使用的网络和缓存一并清掉。注意docker system prune -f不会动你正在运行的容器也不会删被引用的镜像所以从安全性看日常清理用它就够不需要执行-a参数。我第一次用时手快加了-a结果把一些当前没用但后面还要用的旧镜像也删了又费劲重新拉。从那以后我就只用不带-a的版本少惹麻烦。6.4 把常用命令封装成小脚本Windows 上没有 Linux 那么顺手的 shell 脚本但也能通过 PowerShell 脚本简化操作。我在项目目录下放了一个myscript.ps1里面写几个常用的函数function Start-OpenClaw { docker compose up -d } function Stop-OpenClaw { docker compose down } function Show-OpenClawLog { docker logs -f openclaw } function Backup-OpenClaw { docker compose down tar -czvf openclaw-backup-$(Get-Date -Format yyyyMMdd).tar.gz openclaw_data openclaw_config docker compose up -d }在 PowerShell 里执行脚本之后后续管理 openclaw 就是一条单词命令的事比到处找命令记命令靠谱得多。最后再分享一个小技巧做完一次成功的部署后把验证清单和常见报错对照表写在项目目录的 README 里。三个月后再回来迁移或者排障你就能直接照着自己当时的笔记操作不用再从头踩一遍坑。我这次把 openclaw 从一台机器搬到另一台的过程就是靠着上一次留下的笔记半小时内完成全部恢复。
前阵子要给 openclaw 换部署环境折腾的过程中发现一个问题网上关于 Windows 平台用 Docker 部署 openclaw 的资料很少而且大多数写得模棱两可。我花了一个下午在一台只装了 Docker Desktop 的 Windows 机器上把 openclaw 完整跑了起来后来又验证了整套迁移到另一台机器的流程。这篇文章就是我这次实测的完整记录包括部署步骤、踩过的坑以及支持移植到底怎么落地。如果你手头有一台 Windows 机器想跑 openclaw 又不想污染本地环境这篇文章可以直接当操作手册来用。1. 不绕弯子在Windows上给openclaw套一层Docker到底图什么先说结论在 Windows 上部署 openclaw最省心的方式不是直接往系统里装依赖而是跑一个 Docker 容器。原因很简单openclaw 这类常驻服务组件通常依赖特定版本的运行时环境、若干动态链接库还可能涉及对外端口监听和定时任务。直接装在 Windows 上意味着你要手工维护这些依赖一旦 Python 或某个库升级出兼容性问题排查起来非常痛苦还会把系统环境搅成一锅粥。用 Docker 之后情况就完全不一样了。openclaw 连同它依赖的整个运行环境被打包进一个镜像里容器在隔离的命名空间里运行不会碰你本机的注册表、系统目录也不会悄悄改掉你 PATH 里的某个版本。想卸载的时候直接删容器、删镜像Windows 主机上几乎不留痕迹。这就是容器化最直观的价值相当于把你的服务装进一个自带家具的集装箱搬家的时候整个箱子抬走就行。再说体感。我实测下来openclaw 镜像体积在某个版本下大约是 600MB 左右首次启动耗时取决于磁盘速度SSD 上大概 30 秒内能进入监听状态。之后日常运行的内存占用稳定在 300MB 上下对一台开发机来说完全可以忽略。相比直接部署Docker 方案在初始化阶段省掉了我大量查依赖、调版本的时间整体体验顺滑很多。当然Docker 方案也不是没代价。它在 Windows 上依赖 Hyper-V 或 WSL2 虚拟化层这层中间件确实会带来一定的性能损耗主要体现在文件读写上。不过对于 openclaw 这种以网络请求和任务调度为主的服务损耗基本感知不到。如果你追求的是能跑、好迁、不折腾那 Windows 上装 Docker 再跑 openclaw就是合理的默认选择。2. 装好Windows Docker环境后面才不返工部署 openclaw 之前先把 Docker 运行环境夯实。很多人卡在第一步不是 openclaw 的问题而是 Windows 上 Docker Desktop 根本没跑起来或者 WSL2 没配对。先说安装条件。Windows 10 2004 及以上版本或 Windows 11 都能正常装 Docker Desktop。安装前确保 BIOS 里虚拟化已经开启任务管理器 - 性能 页面可以看到虚拟化: 已启用。如果显示未启用得先到 BIOS 里把 Intel VT-x 或 AMD SVM 打开否则 Docker Desktop 根本起不来。装完 Docker Desktop 后建议直接在 WSL2 模式下运行。安装过程中 Docker Desktop 会让你选择是使用 WSL2 还是 Hyper-V 后端这里选 WSL2 就对了。WSL2 相比 Hyper-V 启动更快、内存占用更低而且和 Windows 文件系统交互更自然。装好后打开 PowerShell依次跑几条命令确认环境就绪docker version wsl --statusdocker version能看到 Client 和 Server 两段信息如果 Server 段也有输出说明 Docker 引擎已经在跑。wsl --status的输出里应该有默认版本为 2 的字样如果显示 WSL1执行wsl --set-default-version 2升级。下面这一步是我个人建议容易被忽略给 Docker Desktop 设置资源上限。默认情况下 Docker Desktop 会动态使用宿主机资源的相当大一部分如果这台 Windows 机器同时还要做别的事情最好手动限制。Docker Desktop 打开 Settings - Resources把 Memory 调到一个合理值开发机建议 4096MB 到 8192MB 之间。如果你用的是 WSL2还可以在用户目录下放一个.wslconfig文件内容类似这样[wsl2] memory6GB processors4 swap2GB这个文件在 C 盘用户目录下改完执行wsl --shutdown再重启 Docker Desktop 才会生效。这一步设置好之后openclaw 跑起来就不会因为资源竞争出现各种莫名其妙的卡顿。还有一个细节国内网络环境下拉取 Docker Hub 官方镜像偶尔会超时。可以在 Docker Desktop 的 Settings - Docker Engine 里配置 registry mirror选用自己网络环境下可用的公共镜像加速地址。这一步配置完会重启 Docker 引擎属于合规的网络优化手段实测能大幅减少docker pull超时的概率。3. 完整部署步骤从拉镜像到容器跑起来环境就绪之后进入正式部署。整个流程分四步拉镜像、写编排文件、启动容器、验证功能。我实测下来每一步都有值得注意的细节。3.1 拉取 openclaw 镜像并核对架构先从镜像仓库拉取 openclaw 镜像。如果用的是社区维护的标准镜像命令一般是这样的docker pull openclaw:latest如果你拉的是自定义仓库里的版本把镜像名替换成实际地址即可。拉取完成后用docker images确认镜像已经在本地docker images | grep openclaw镜像拉下来之后建议顺手看一眼镜像的架构信息特别是如果你的 Windows 机器是 ARM 架构比如某些 Windows 平板或新款的骁龙本而镜像默认是 amd64 的直接启动会报exec format error。用docker inspect可以确认docker inspect openclaw:latest | grep Architecture我的实测机器是 x64 架构所以没有遇到这个问题但如果你的环境特殊这一条能帮你提前避坑。3.2 编写 docker-compose.yml为什么这么写比起一条条敲docker run命令我强烈建议用 docker-compose 来管理 openclaw。原因很简单openclaw 跑起来需要端口映射、数据目录挂载、环境变量注入这些配置写在 yml 文件里可以版本化管理将来换机器直接复制文件就能复现一套完全一样的环境。以下是我亲测可用的docker-compose.yml基于某个稳定的 openclaw 镜像版本编写version: 3.8 services: openclaw: image: openclaw:latest container_name: openclaw restart: unless-stopped ports: - 8080:8080 volumes: - ./openclaw_data:/data - ./openclaw_config:/etc/openclaw environment: - OPENCLAW_HOME/data - OPENCLAW_LOG_LEVELinfo - TZAsia/Shanghai networks: - openclaw_net networks: openclaw_net: driver: bridge解释几个关键配置点这些都是我实际使用后认为不能省的东西restart: unless-stopped让 openclaw 在容器崩溃或者 Docker 重启后自动拉起来对常驻服务来说非常重要少了这一行系统重启后你得手动启动容器。端口映射8080:8080表示把容器的 8080 端口映射到宿主机 8080。如果本机 8080 已经被占用了可以改成18080:8080左侧是宿主机端口。卷挂载是整套配置的灵魂。./openclaw_data:/data把配置、日志、运行时数据都持久化到宿主机目录./openclaw_config:/etc/openclaw映射配置文件。这样容器删了也没关系数据还在宿主机上后面第 5 章讲移植时你就明白为什么这两行这么重要。3.3 启动容器并验证运行状态在docker-compose.yml所在目录打开 PowerShell执行docker compose up -d-d是后台运行不加的话会一直挂在前台输出日志。启动后先看容器状态docker ps正常情况下能看到openclaw容器处于 Up 状态端口映射那栏显示0.0.0.0:8080-8080/tcp。如果容器一直处于 Restarting多半是配置或环境变量有问题用日志来定位docker logs openclaw日志里如果看到listening on 0.0.0.0:8080之类的字样说明 openclaw 已经正常监听了。此时在浏览器访问http://localhost:8080应该能看到 openclaw 的默认响应页面或接口提示。3.4 验证服务的核心功能跑通只是第一步还需要做几个快速验证确保它不是假活。第一条验证容器内的 openclaw 进程是否健康。进入容器看一下运行状态docker exec -it openclaw ps aux能看到 openclaw 主进程在运行并且没有处于僵死状态。第二条验证数据目录是否真的在写入。到宿主机上./openclaw_data目录看一眼如果里面有日志文件或运行时数据文件说明卷挂载生效了。第三条做一次简单的接口冒烟测试。我用的工具是 PowerShell 自带的Invoke-WebRequestInvoke-WebRequest -Uri http://localhost:8080 -UseBasicParsing返回 200 或其他合理响应码说明服务对外可达。实测中我遇到过一种情况容器明明在跑日志也正常但宿主机访问不到端口。这种往往是 Windows 防火墙拦截了端口需要在防火墙入站规则里放行对应端口或者临时切到公网之前先确认这条。4. Windows环境下的坑我一个一个踩给你看openclaw 本身在 Linux 容器里跑得挺稳但宿主机是 Windows 时容器和宿主之间的边界上会出现一些在 Linux 下完全遇不到的坑。我全部踩过一轮下面按现象、原因、解决的顺序整理出来每条都可以直接套用。4.1 配置文件解析失败CRLF 换行符问题第一次启动容器后看日志发现 openclaw 一直报配置文件格式错误。检查文件内容格式看起来完全正常也不缺括号和引号。问题出在换行符上。Windows 文本文件的换行符是\r\n而 Linux 容器里大多数服务期望的是 Unix 换行\n。如果配置文件是在 Windows 上用记事本或老版本编辑器写的存下来之后每一行都带一个看不见的\r服务解析时就可能出错。解决方式很简单用支持切换换行符的编辑器比如 VS Code打开配置文件右下角把行尾序列从 CRLF 切换到 LF保存后重启容器docker compose restart openclaw如果你用 git 管理配置还可以在仓库根目录加一个.gitattributes文件强制配置目录下的文件统一用 LF*.yml text eollf *.yaml text eollf *.conf text eollf这个坑非常隐蔽因为很多人第一反应是配置文件语法写错了实际只是换行符在作怪。判断方法很简单日志报错位置如果总是瞄不准优先怀疑 CRLF。4.2 挂载目录权限异常一切正常但写不进去openclaw 容器启动起来了接口也能访问但往数据目录写文件时提示权限不足。排查过程比较曲折。起初我以为是容器内部用户权限问题进容器查看发现 openclaw 确实以非 root 用户运行。问题在宿主机侧Windows 对挂载到 WSL2 的文件目录有特殊的所有权模型如果./openclaw_data目录的权限没放开容器里的进程写入时会碰到权限边界。解决办法分两步。第一步确认数据目录在 Windows 上不是只读属性。右键目录查看属性取消只读勾选。第二步如果问题依旧在 PowerShell 里给当前用户显式授权icacls .\openclaw_data /grant $env:USERNAME:(OI)(CI)F /T这条命令的意思是给当前用户针对该目录的完全控制权限/T会递归应用到子目录。实测中这类权限问题最容易出现在从别的机器拷贝过来的目录上。Windows 会保留原机器的用户 SID 信息导致当前用户看着文件在却没有写入权限。遇到这种情况直接用 icacls 重置一次所有权授权就能解决。4.3 端口被占用改了映射才发现完整方案openclaw 默认监听 8080 端口但 Windows 上 8080 经常被其他开发服务占用。启动容器时如果端口冲突docker ps里容器状态会是 Up但你访问localhost:8080就是不通日志里往往没有明显报错只有仔细看才能发现端口绑定失败。定位端口占用用这个命令netstat -ano | findstr :8080输出里能看到占用 8080 的进程 PID再到任务管理器里查这个 PID 是什么程序。如果是无关紧要的服务可以停掉它如果不想动它直接改 docker-compose.yml 里的左侧映射端口ports: - 18080:8080改完执行docker compose down docker compose up -d然后用http://localhost:18080访问。这个方案的好处是容器内部端口不用动openclaw 配置里保持 8080 即可避免改了一堆容器内配置反而把服务搞挂。4.4 Docker 引擎吃内存开发和部署同机时要心里有数WSL2 模式下的 Docker Desktop 内存占用在某些版本里偏高打开任务管理器能看到一个名为 vmmem 的进程动辄占用好几个 GB。这在部署 openclaw 的同时还要跑开发工具时很容易造成整体卡顿。这就是第 2 章里建议配置.wslconfig的原因。我实测下来的经验值是给 Docker 分配 4GB 到 6GB 内存openclaw 容器跑起来绰绰有余同时还给系统留出了充足的余量。如果发现 vmmem 占用还是异常高可以用命令强制回收wsl --shutdown这条命令会把 WSL2 虚拟机停掉Docker Desktop 会自动重启并刷新资源占用。注意重启期间容器也会跟着重启所以这种操作放到业务低峰期做比较合适。5. 换个机器也不慌openclaw的移植与备份完整路线标题里写了支持移植这是我最看重的一个特性。现在容器化部署的好处就在这换机器、换机房、换测试环境都可以用一套标准流程迁移不用在新机器上重新调半天依赖。5.1 先搞清楚什么数据必须跟着走openclaw 的数据分三类。第一类是配置文件在./openclaw_config目录下包括主配置、密钥、外部服务连接信息。第二类是运行产生的数据在./openclaw_data目录下包括日志、任务状态、持久化存储等。第三类是容器镜像本身这个不必手动拷在新机器上可以直接拉取。前两类数据的价值远高于容器本身。容器随时可以重建但配置和数据一旦丢了openclaw 等于从零初始化。所以移植第一步是明确数据目录跟着走容器随便重建这个原则。5.2 导出镜像给离线环境用有时候新机器网络环境受限拉不了镜像那就需要在源机器上导出镜像文件。在源机器上执行docker save -o openclaw-image.tar openclaw:latest这会生成一个 tar 文件把它拷到目标机器上后导入docker load -i openclaw-image.tardocker load之后本机镜像库里就有 openclaw 了后续流程和正常拉取一致。我实测过镜像在 U 盘和移动硬盘上的拷贝文件大概六七百兆传输时间主要取决于存储介质。需要注意的一点是镜像导出文件不带任何历史标签导入后镜像名和 tag 要记住docker-compose.yml 里写的镜像名要能对上。5.3 数据目录整体迁移数据目录迁移是整个移植过程中最需要小心的环节。我的做法是先在源机器上把容器停掉确保数据不会继续写入然后打包docker compose down tar -czvf openclaw-backup.tar.gz openclaw_data openclaw_config停容器这一步很多人会忽略直接在容器运行状态下打包数据。这样做出来的备份可能处于数据不一致状态因为某些文件刚刚写入一半迁移过去后可能打不开。最好是正式停服后再打包保证数据一致。到新机器上后解压备份到 docker-compose.yml 同级目录然后直接启动tar -xzvf openclaw-backup.tar.gz docker compose up -d启动后对照第 3.3 节的验证方法确认日志正常、接口可访问、历史任务数据还在。我在实测中迁移过一台机器后发现之前的任务记录和日志全部保留了这就说明数据卷的挂载路径没搞错整个迁移链路是通的。5.4 移植到新机器后最容易出的问题遗漏配置文件迁移完之后我看到日志里报配置文件缺失之类的问题检查下来发现是打包时只打包了openclaw_data漏了openclaw_config。数据还在但 openclaw 因为找不到密钥或连接配置启动时直接进入降级或失败状态。所以打包时务必检查两个目录都在。可以用一条命令快速确认 tar 包内容tar -tzvf openclaw-backup.tar.gz | head -20如果发现只有 data 没有 config老老实实重新打包。移植不是把容器搬过去就行而是把容器 数据 配置作为一个整体搬过去三者缺一不可。6. 跑起来之后日常运维、升级和清理的实操习惯openclaw 在 Windows 上稳定跑起来之后剩下的就是日常维护。这部分分享几个我实际养成的习惯都不复杂但能让部署长期保持健康。6.1 日志增长太快怎么办openclaw 跑一段时间后./openclaw_data里的日志文件会持续增长。实测中如果日志级别开到 debug两天就能积攒几百 MB 的日志。我的做法是把OPENCLAW_LOG_LEVEL设为info并定期清理日志目录里的旧文件同时配合 Docker 自带的日志轮转机制。在 docker-compose.yml 里给服务加上logging: driver: json-file options: max-size: 20m max-file: 5这样单份日志超过 20MB 会自动轮转最多保留 5 份。这个配置我在生产环境实测有效日志目录既不会无限膨胀又能留足排查问题的量。6.2 容器升级的正确姿势openclaw 镜像一更新很多人的第一反应是直接docker compose restart。但 restart 并不会拉新镜像容器还是在旧的镜像版本上跑。正确的升级流程是docker compose pull docker compose up -dpull会按 docker-compose.yml 里的镜像名重新拉取最新版本up -d则会在镜像变化时重建容器。升级前建议先看一下镜像的 release notes确认有没有破坏性的配置变更。实测中我遇到过一次升级后配置项改名导致服务起不来所以升级后一定要看日志确认状态。升级过程中老版本容器会保留在你的本地类似上一个版本存档。如果新版本出问题可以直接把 docker-compose.yml 里的镜像 tag 改回旧版本再执行docker compose up -d回滚。6.3 定期清理无用的镜像和容器时间一久本机往往会堆积一堆 tag 为none的中间镜像和已退出的容器。它们虽然不占太多内存但会白白占用磁盘空间而且会让docker images的输出变得混乱。我习惯每隔一两周执行一次docker system prune -f它会把悬空镜像、停止的容器、未使用的网络和缓存一并清掉。注意docker system prune -f不会动你正在运行的容器也不会删被引用的镜像所以从安全性看日常清理用它就够不需要执行-a参数。我第一次用时手快加了-a结果把一些当前没用但后面还要用的旧镜像也删了又费劲重新拉。从那以后我就只用不带-a的版本少惹麻烦。6.4 把常用命令封装成小脚本Windows 上没有 Linux 那么顺手的 shell 脚本但也能通过 PowerShell 脚本简化操作。我在项目目录下放了一个myscript.ps1里面写几个常用的函数function Start-OpenClaw { docker compose up -d } function Stop-OpenClaw { docker compose down } function Show-OpenClawLog { docker logs -f openclaw } function Backup-OpenClaw { docker compose down tar -czvf openclaw-backup-$(Get-Date -Format yyyyMMdd).tar.gz openclaw_data openclaw_config docker compose up -d }在 PowerShell 里执行脚本之后后续管理 openclaw 就是一条单词命令的事比到处找命令记命令靠谱得多。最后再分享一个小技巧做完一次成功的部署后把验证清单和常见报错对照表写在项目目录的 README 里。三个月后再回来迁移或者排障你就能直接照着自己当时的笔记操作不用再从头踩一遍坑。我这次把 openclaw 从一台机器搬到另一台的过程就是靠着上一次留下的笔记半小时内完成全部恢复。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
