部署到服务器:Windows / Linux 双轨并行，一小时上线

一、代码写完，怎么让它一直跑

本地跑 npm start 只是“能跑”,关掉终端就没了。真正的部署，是要让这个进程在服务器上无人值守地长期跑——重启后自启、崩溃了自愈、有日志、有探活、有 TLS。这些能力不是靠 Node 自己解决的，而是把它交给系统级服务托管:Linux 上是 systemd,Windows 上是 NSSM 或 Scheduled Task。这两条路线看似平等，实际有差异:systemd 是操作系统内建的一等公民,Nginx/Docker/大部分开源软件都为它写好了单元文件;NSSM 是社区工具，胜在把任意 exe 都能包成服务，但每个字段都要你自己填。选谁不是能力问题，是“你的机器提供了什么”的问题。经验之谈:只要能上 Linux,就上 Linux——服务化生态足够干净，官方与社区文档也远比 Windows 侧丰富。

AISTOC 内部有一段血泪:去年我们把一个内部小工具部署到 Windows Server 上，直接跑在了当前用户的 PowerShell 里。跑了三周都没事，直到某个下午运维同学去做安全巡检，把管理员账号密码改了，机器要求重新登录——那一刻，进程就没了。后来我们才理清楚“登出 = 进程结束”这条隐蔽的默认行为，回头补 NSSM 又花了半天。这种“看起来能跑但一停就没”的部署，是新手最容易踩的坑，也是本期最想帮你避掉的第一件事。让服务活下去的第一步，是让它脱离你的登录会话——所有生产化的部署套路，本质上都在解决这一件事。

还有一条被反复问的路线:WSL2 里跑 Linux 部署。技术上没问题，但据官方文档提示,Windows 2024-2025 的 WSL 版本存在 15-20 秒 idle-terminate 的默认行为——你登出 Windows 后,WSL 里的 systemd 服务会被杀掉。解决办法是启用 enable-linger 并搭配一个 Task Scheduler 任务把 dbus 保活。不复杂，但初次踩必然懵——所以如果你需要长期稳定，建议直接找一台真 Linux VPS,别在 WSL 里死磕。

本机 node server.js 与生产部署之间，隔着的其实是七八件外围工程:服务托管、反向代理、TLS、日志、探活、备份、平滑升级。看似只是“再跑一遍”,实则每一环都在暴露 MVP 里被忽略的假设。E05 结尾我们说过:写代码是艺术，部署是工程。这一集就是把那一句话变成动作。

二、双轨对照:先挑一条走完，再看另一条

选哪条?简单粗暴:你手上的服务器是什么系统，就走哪条。别自我为难非要跨系统折腾。真到“跨平台部署都要熟”的地步，是 SRE 的事，不是 MVP 阶段的功课。

对刚上手的读者，还有一条建议:先用一台便宜的 5 USD 级 VPS 走完全流程，比在本地反复模拟服务器环境有价值得多。Hetzner CX22(约 4 美元/月)、DigitalOcean Basic 1 GB(6 美元/月)、Oracle Always Free ARM(长期免费但注册需要一点耐心)都是不错的起点。云服务价格随促销/汇率变化，读者按需以官网为准。跑上一次真环境，你才会真正明白反向代理、TLS、日志、探活这些概念为什么存在——书本上永远说不清楚。

三、Windows 轨:NSSM + Nginx 一条脚本部署

在 Windows Server 上，把一个 Node 进程做成服务的最短路径是 NSSM(Non-Sucking Service Manager)——一款社区维护的老牌工具，把任意可执行文件包成 Windows Service。前置准备三条命令:

接着一条脚本部署到位。AISTOC 内部实测(Windows Server 2022 · Node v24.14.1):

脚本会依次做七件事:验环境 → 复制源码到 C:\Services\ → 建数据目录并收紧 ACL → 卸掉旧同名服务 → nssm install 注册 → 打开 stdout/stderr 日志轮转 → 启动并 Invoke-RestMethod /healthz 探活。跑完 services.msc 里就能看到 oc-todo-web 状态 Running。特别提醒:本教程 Windows 部分的脚本已经在沙盒目录做过 PowerShell 语法校验 + MVP 本机 :18590 三层探活，但 AISTOC 团队没有在生产 Windows Server 上真注册 NSSM 服务、也没有改本机 Nginx——真到你自己的机器上跑之前，建议先在测试机走一遍。凡是“改系统级配置”的动作，都值得多一分敬畏。

Nginx 反代的最小配置:

nginx -t 校验通过后 nginx -s reload,浏览器打开 http://todo.local,MVP UI 就在那儿。整个过程从 winget install 到浏览器看到界面,AISTOC 内部实测约 15 分钟——大头是 Node 与 Nginx 安装的下载时间，脚本本身只花不到一分钟。

一个容易被忽略的细节:脚本会把数据目录的 ACL 收紧到“仅当前用户 + SYSTEM”。这是“进程即使被攻破，数据也不至于被任意读写”的最小成本防御。Windows 上做这件事没有 Linux 那么优雅，但只要写在脚本里，跑一次就管一辈子。

四、Linux 轨:systemd + certbot 一条命令 HTTPS

Linux 的部署主流是 systemd 用户级或系统级服务。个人用建议走用户级——把 ~/.config/systemd/user/oc-todo-web.service 落好后 systemctl --user enable --now 即可，不需要 sudo;多用户或需要开机自启的服务器场景，切换到系统级。核心都是一份 .service 单元文件:

这几行硬化配置还想补一句:NoNewPrivileges 阻止子进程通过 setuid 提权、ProtectSystem=strict 把整个 / 挂成只读、ProtectHome 屏蔽用户 home、PrivateTmp 独享 /tmp。最后一条 ReadWritePaths 是唯一豁口，只允许写数据目录与日志目录。四行加起来，把“进程被攻破”的伤害面压到最低。

签证书一条命令:

Let’s Encrypt 90 天续期,certbot 会自动装一个 systemd timer,无需你操心——这也是 Let’s Encrypt 生态最大的红利之一:证书这件事一次配置终身自动化，比早年间手动买证书、导出私钥、装到 Nginx 里的时代方便了整整一个数量级。生产上唯一要留意的是“过期告警”,我们放到 E07 里一起讲。据AISTOC 团队的观察，这条流水线在 5 USD 级 VPS 上跑得都很稳。1 GB 内存的机器记得加 2 GB swap,否则 npm install 阶段会 OOM——这是所有低配 VPS 的通病。

如果你在国内网络环境部署，还有两个额外提醒:其一,deb.nodesource.com 直连可能超时，用 nvm 或国内 Node 镜像更稳;其二,Docker Hub / GHCR 拉镜像慢，配一个官方或第三方的镜像加速地址即可。这些环境适配的动作不难，但少了它们，部署脚本会在你没预料到的环节卡住。

五、探活的三层含义

一个 /healthz 端点，跑通三层各自的“自证”:

1. 后端自证:curl -s http://127.0.0.1:8080/healthz 返 {"ok":true,"ts":...}——服务本身活着。
2. 反代自证:curl -H "Host: todo.example.com" http://127.0.0.1/healthz——Nginx 能正确转发。
3. TLS 自证:curl https://todo.example.com/healthz——证书链、SNI、协议版本全通。

真出问题时，三层依次 curl 一遍，故障点马上定位——比看日志快十倍。这是一条工程直觉，也是本期部署篇最想传递的心法。

更进一步说，探活的价值不只是“故障时排查”,它还是让 systemd/NSSM 敢自动重启的前提。Restart=on-failure 依赖进程 exit code;健康探针的意义是“进程在跑，但服务真的还能响应”。两者叠加，才组成“进程自愈”的完整闭环。Docker 官方镜像自带 HEALTHCHECK、Kubernetes 分 liveness/readiness,思路都是一样的——能被外部机械观察到的健康，才是真的健康。这条思想放在个人小服务上也一样成立——健康探针的成本是 20 行代码，收益是“你不用凌晨爬起来手动 systemctl restart”,值得。

六、四个最容易翻车的坑

四条坑加起来，其实指向的是同一个道理:部署环节最贵的 debug 时间，都花在“配置写得没错但组合不对”上。别指望一次通关，多留一份 nginx -t、journalctl -f、nssm status 的耐心，比 review 十遍配置文件更管用。

七、要不要顺便把 OpenClaw dashboard 也反代出去

很多人有一个自然的想法:既然 Nginx 都装上了，那把 OpenClaw dashboard(Gateway 18789)也反代出去多方便。AISTOC 建议:默认别这么做。OpenClaw 的官方铁律是”loopback-only unless you’re sure you need a bind”——把它绑在本机 127.0.0.1,用 SSH 隧道或 Tailscale Serve 远程访问，就已经足够安全。要放公网，就必须启用 gateway.auth 的 token/password 或 trusted-proxy 模式，再叠一层 Nginx basic auth + IP allowlist。真到那一步，你会发现——把 dashboard 关掉、直接用 Telegram/飞书 channel 收发消息，简单十倍。这也是 E01 就埋下的伏笔:把入口挪到聊天窗，本来就是 OpenClaw 最漂亮的设计选择。

最后回头看:整套部署下来，你会发现真正让服务“稳定跑”的动作，几乎不涉及业务代码本身——服务托管、反向代理、TLS、日志、探活、备份、平滑升级，每一项都在给“能跑”这两个字加一层保险。这也是写代码与做工程的分界线。AI 能帮你写 server.js,但这些外围工程的选型，还是要你自己拍板:你的团队会不会 systemd、你有没有信任 Tailscale、你能不能忍受证书过期时的 3 点电话——这些都是 AI 帮不了的判断。

八、你现在可以做的三件事

读部署篇最怕停留在“看懂了”。这一集有大量脚本片段，如果不动手，忘得比什么都快。下面三件事各占十几到二十分钟，做完你就有了一次真正跑通的部署经验。

九、下期预告

装完不管就出事。E07 补齐运维闭环——日志轮转、备份策略、告警通道、平滑升级。也会解开一个具体问题:如果告警要发出来，发到哪里最合适?提前透露一句:不要刷生产群，用 Agent 自己的 direct 或日志文件。运维闭环不做完，前面五集的努力，很容易被一次意外的宕机吞掉一半。下期见。

—— AISTOC产品团队