企业官网建设流程全解析

1. 项目概述：为什么 Winsw 是 Windows 服务部署的“隐形冠军”

你有没有遇到过这样的场景：写好了一个 Python 脚本，或者打包好的 Java 后端 jar 包，又或是 Node.js 的 Web 服务，本地双击就能跑，但一关掉命令行窗口，服务就立刻停了；想让它开机自启、后台静默运行、崩溃自动重启——翻遍教程，不是要改注册表，就是得写一堆 PowerShell 脚本，还要手动配置服务描述、启动类型、恢复策略，稍有不慎，服务状态就显示“已停止”，日志里连报错都找不到。这时候，Winsw 就像一个被低估的瑞士军刀：它不抢眼，不依赖 .NET Framework 或 Windows SDK，单个 exe 文件（或 jar）就能把任意可执行程序包装成标准 Windows 服务，全程无需管理员权限安装（开发调试阶段）、支持 XML/YAML 配置、自带日志重定向、进程守护、优雅关闭钩子，甚至能通过 HTTP 端口暴露健康检查接口。我第一次在某高校实验室的边缘计算节点上用它部署一个采集温湿度数据的 Python 脚本时，从下载到服务注册成功，确实只用了不到 5 分钟——不是营销话术，是真实计时器记录的结果。它解决的不是“能不能做”，而是“要不要花两小时查文档、试错、重装系统服务”的问题。适合谁？刚接触 Windows 系统运维的开发者、需要快速交付内部工具的测试工程师、不想被 IIS 或 Apache 吞噬学习成本的嵌入式方案工程师，以及所有厌倦了每次部署都要重写一遍 sc.exe 命令的人。核心关键词——Winsw、Windows 服务、零基础、5分钟、应用部署——每一个都直指痛点：它不教你怎么写代码，只帮你把写好的东西，稳稳当当地“钉”进 Windows 系统服务管理器里。

2. 核心设计逻辑与方案选型深度拆解

2.1 为什么不是 sc.exe？为什么不是 NSSM？为什么偏偏是 Winsw？

很多人会问：Windows 自带 sc.exe 不就能创建服务吗？没错，但 sc.exe 只是服务管理的“遥控器”，它不负责进程生命周期管理。你用sc create注册一个服务后，如果主进程意外退出，sc.exe 不会拉起它；如果程序需要读取命令行参数或环境变量，sc.exe 本身不提供配置入口；更麻烦的是，它不接管 stdout/stderr——这意味着你的 Python print() 或 Java System.out.println() 全部丢进黑洞，查日志得靠 Event Viewer 里晦涩的“服务未响应”事件。而 NSSM（Non-Sucking Service Manager）确实是 Winsw 的主要竞品，功能强大，支持 GUI 配置，但它的二进制体积大（>2MB），依赖 Visual C++ 运行库，在老旧工控机或精简版 Windows Server 上常因 DLL 缺失失败；更重要的是，NSSM 的配置文件是纯文本 INI 格式，不支持结构化参数（比如无法直接定义“当进程退出码为3时，等待10秒后重启”这种细粒度策略）。Winsw 则完全不同：它本质是一个“服务包装器”（Service Wrapper），设计理念是“最小侵入、最大兼容”。它不修改目标程序任何一行代码，也不要求你重新编译；它通过 Windows API 的 CreateProcess + SetServiceStatus 机制，把自己变成服务宿主进程，再以子进程方式启动你的应用，并全程监听其状态。官方提供的 winsw-x64.exe（约 1.2MB）是静态链接的，不依赖外部 DLL；配置文件采用 XML 或 YAML，天然支持嵌套结构和注释，比如你可以清晰地写：

<service> <id>data-collector</id> <name>Data Collector Service</name> <description>Collects sensor data every 30s and writes to local DB</description> <executable>C:\python\python.exe</executable> <arguments>C:\scripts\collector.py --mode=prod</arguments> <logpath>C:\logs\collector</logpath> <logmode>roll</logmode> <onfailure action="restart" delay="10000"/> <extensions> <extension enabled="true" className="winsw.Plugins.RunawayProcessKiller"> <priorityThreshold>7</priorityThreshold> </extension> </extensions> </service>

这段配置里，“onfailure”定义了崩溃后的重启行为，“extensions”启用了进程失控保护插件——这些能力，sc.exe 原生根本不支持，NSSM 要靠额外脚本模拟。Winsw 的另一个隐藏优势是“热重载”：修改 XML 配置后，无需卸载重装服务，只需执行winsw.exe update即可生效，这对频繁迭代的开发环境极其友好。我曾在一个物联网网关项目中，用 Winsw 管理 7 个不同语言写的微服务模块（Python、Go、C# CLI），全部共用同一套启动/停止/日志规范，运维同学只需要记住winsw.exe start/stop/status三个命令，就完成了整套系统的启停调度——这种一致性，是碎片化工具链永远给不了的。

2.2 版本选择：.exe 还是 .jar？32位还是64位？如何避坑？

Winsw 官方提供两种分发形态：原生 Windows 可执行文件（.exe）和 Java 版本（.jar）。表面看，.jar 更“跨平台”，但实际在 Windows 服务场景下，.exe 是绝对首选。原因很实在：Java 版本必须依赖系统已安装 JRE，且启动时会多一层 JVM 初始化开销（平均增加 800ms 启动延迟），在资源受限的嵌入式 Windows 设备（如树莓派 Windows IoT Core）上，JVM 内存占用可能直接触发 OOM。而 .exe 是用 C++ 编写的，启动即用，内存占用稳定在 2–3MB，对 CPU 占用近乎为零。我实测过，在一台 2GB 内存的 Win10 IoT 设备上，用 winsw-3.1.0-net461.exe 启动一个 50MB 的 .NET Core 应用，服务注册耗时 120ms；换成 winsw-3.1.0.jar，则需先加载 JRE，总耗时跳到 950ms，且首次启动后，JVM 进程常驻内存达 180MB。所以，除非你的目标环境强制要求“全 Java 技术栈”，否则无脑选 .exe。

关于位数，原则很简单：你的目标应用是什么位数，Winsw 就选什么位数。这不是玄学，是 Windows PE 加载器的硬性规则。如果你用 32 位 Python（常见于旧版 Anaconda），却配了个 winsw-x64.exe，服务启动时会报错Error 1053: The service did not respond to the start or control request in a timely fashion——因为 64 位宿主进程无法加载 32 位 DLL（Python 的 _socket.pyd 等）。反之亦然。判断方法极简单：打开任务管理器 → 详细信息页 → 找到你的目标程序进程 → 右键属性 → 查看“体系结构”列。若显示“32 位”，就下载 winsw-3.1.0-i686.exe；若显示“64 位”，则用 winsw-3.1.0-x64.exe。这里有个易忽略的细节：Windows 10/11 默认安装的 Python 官方安装包，从 3.9 版本起已全面转向 64 位，但很多企业内网仍沿用 3.7 的 32 位版本，务必确认。另外，Winsw 3.x 系列已放弃对 Windows 7 的支持（官方明确声明），如果你还在维护 Win7 系统，必须降级使用 Winsw 2.11.0，否则服务安装时会提示The service process could not connect to the service controller。这个坑我踩过两次：一次是在客户现场升级系统后，服务批量失效；另一次是帮某公司迁移旧产线软件，发现他们的 Win7 SP1 工控机根本无法加载 Winsw 3.x 的 TLS 1.2 加密模块。教训是：部署前，先用systeminfo | findstr /B /C:"OS Name" /C:"OS Version"命令确认目标系统版本，再匹配 Winsw 版本，比事后排查快十倍。

2.3 配置范式：XML 与 YAML，哪个更适合新手？

Winsw 同时支持 XML 和 YAML 两种配置格式，官方文档对两者功能描述完全一致，但实际体验天差地别。XML 是 Winsw 的“原生语言”，所有高级特性（如<extensions>插件系统、<env>环境变量块、<serviceaccount>账户配置）都首先在 XML 中实现，YAML 是后期通过解析器映射过来的。这意味着：当你在 YAML 中尝试启用 RunawayProcessKiller 插件时，文档里写的extensions: [{enabled: true, className: "winsw.Plugins.RunawayProcessKiller"}]在 Winsw 3.0.0 版本中根本无效——因为该插件的 YAML 映射直到 3.1.0 才修复。而 XML 配置，从 2.x 到 3.x，语法向后兼容性极佳，我用 2018 年写的 XML 配置文件，在 2024 年的 Winsw 3.1.0 上依然能 100% 正常工作。对零基础用户，XML 的“冗长”反而是优势：标签名即语义（<executable>就是填程序路径，<arguments>就是填命令行参数），IDE（如 VS Code）装个 XML Tools 插件，还能实时校验格式错误；而 YAML 对缩进极度敏感，少一个空格、多一个冒号，服务就启动失败，报错信息却是笼统的Failed to parse configuration file，新手根本无从下手。我辅导过十几位刚毕业的测试工程师，让他们分别用 XML 和 YAML 配置同一个 Spring Boot jar 包，结果 100% 的人 XML 一次成功，YAML 平均调试 3 次以上——最常见的错误是arguments: java -jar app.jar写成了arguments: "java -jar app.jar"（加了引号后，Winsw 会把整个字符串当做一个参数传给 java.exe，导致找不到主类）。所以，我的建议非常明确：零基础入门，只用 XML；等你熟悉了 Winsw 的核心概念（如 logmode、onfailure、delay），再考虑 YAML 的简洁性。而且，Winsw 提供了一个极其实用的工具：winsw.exe wrapper命令，能将现有 XML 配置自动转换为 YAML，反之亦然，这让你在掌握 XML 后，可以无缝过渡到 YAML，而不是从零开始踩坑。

3. 实操全流程详解：从下载到服务稳定运行的每一步

3.1 环境准备与文件组织：一个干净的目录结构决定 80% 的成功率

很多新手卡在第一步：下载完 winsw.exe，双击没反应，或者放到脚本同目录就报错。根源在于忽略了 Windows 服务对文件路径和权限的隐性要求。Winsw 不是普通桌面程序，它是以 SYSTEM 账户身份运行的，这意味着它对文件路径的访问权限，和你当前登录用户的权限是隔离的。我见过最典型的错误，是把 winsw.exe 和 Python 脚本一起放在C:\Users\Alice\Documents\myapp\目录下，然后用管理员权限运行winsw.exe install——服务能注册成功，但启动时必然失败，日志里只有一行Failed to start process: Access is denied。因为 SYSTEM 账户默认没有读取用户文档目录的权限。正确的做法，是建立一个服务专用根目录，路径必须满足三个条件：1）不在用户个人目录下（避开 Documents、Desktop、Downloads）；2）路径不含中文和空格（避免 cmd 解析异常）；3）目录权限对NT AUTHORITY\SYSTEM开放。我推荐的标准路径是C:\svc\myapp\（svc是 service 的缩写，行业通用）。

具体操作步骤如下（请严格按顺序执行）：

1. 以管理员身份打开 PowerShell（右键开始菜单 → Windows PowerShell（管理员）），执行：

   mkdir C:\svc\myapp # 创建目录后，立即设置权限，这是关键！ icacls C:\svc\myapp /grant "NT AUTHORITY\SYSTEM:(OI)(CI)F" /T

   这条命令的意思是：给NT AUTHORITY\SYSTEM账户授予C:\svc\myapp目录及其所有子目录（/T）的完全控制权（F），且权限可继承（(OI)(CI)）。如果不执行这步，后续所有操作都是徒劳。

2. 下载并重命名 Winsw 主程序：去 Winsw GitHub Releases 页面 ，下载最新稳定版的winsw-x64.exe（假设你的应用是 64 位），保存到C:\svc\myapp\，然后必须重命名为myapp.exe（文件名需与你的服务 ID 一致，这是 Winsw 的硬性约定）。例如，如果你的服务 ID 计划叫><service> <id>myapp</id> <name>My Application Service</name> <description>A simple demo service for learning Winsw</description> <executable>python.exe</executable> <arguments>collector.py</arguments> <logpath>C:\svc\myapp\logs</logpath> <logmode>roll</logmode> <onfailure action="restart" delay="10000"/> </service>

   这个配置仅包含 6 个必填项，足够让服务跑起来。其中<logpath>必须是绝对路径，且该目录需预先存在（执行mkdir C:\svc\myapp\logs）；<logmode>roll</logmode>表示日志滚动，每天生成一个新文件，避免单个日志无限膨胀。

完成这四步，你的目录结构应该长这样：

C:\svc\myapp\ ├── myapp.exe # 重命名后的 Winsw 主程序 ├── myapp.xml # 配置文件，名称与 exe 严格一致 ├── collector.py # 你的目标应用 ├── python.exe # （可选）如果选择自带 Python └── logs\ # 日志目录，已创建

这个结构看似简单，但每一步都针对 Windows 服务的底层机制做了适配。我曾帮一个团队排查持续一周的部署失败问题，最终发现根源就是他们把所有文件放在了 OneDrive 同步文件夹里——SYSTEM 账户无法访问 OneDrive 的虚拟文件系统，导致winsw.exe根本读不到collector.py。所以，永远把服务文件放在本地物理磁盘的纯净路径下，这是铁律。

3.2 配置文件核心参数逐项解析：不只是填空，更要理解每个字段的“权力边界”

XML 配置文件是 Winsw 的灵魂，但很多教程把它当成填空游戏，只告诉你“这里填路径，那里填名字”，却不解释每个参数背后的操作系统级含义。这导致一旦出错，用户完全无法定位。下面我以一个生产环境的真实配置为例，逐字段拆解其技术原理和实操陷阱：

<service> <id>iot-gateway</id> <name>IoT Gateway Service</name> <description>Manages MQTT connections and forwards sensor data to cloud</description> <executable>C:\svc\iot-gateway\gateway.exe</executable> <arguments>--config=C:\svc\iot-gateway\config.yaml --log-level=warn</arguments> <env name="GATEWAY_ENV" value="production"/> <env name="PATH" value="C:\svc\iot-gateway;C:\Windows\system32"/> <workingdirectory>C:\svc\iot-gateway</workingdirectory> <logpath>C:\svc\iot-gateway\logs</logpath> <logmode>roll</logmode> <onfailure action="restart" delay="5000"/> <onfailure action="restart" delay="10000" if="1"/> <onfailure action="none" if="2"/> <onfailure action="reboot" if="3"/> <stoptimeout>30000</stoptimeout> <serviceaccount> <domain>NT AUTHORITY</domain> <user>LocalSystem</user> </serviceaccount> </service>

• <id>：服务在 Windows 服务管理器中的唯一标识符，也是sc query命令查询时用的名字。它不能包含空格和特殊字符（如/,\,:），否则winsw.exe install会失败。我见过有人写<id>My App v1.0</id>，结果安装时报错Invalid service name。正确写法是iot-gateway或myapp_service。

• <executable>：这是 Winsw 启动的“第一个进程”。它必须是可执行文件（.exe, .bat, .cmd, .py 等），且路径必须是绝对路径或相对于winsw.exe所在目录的相对路径。关键点在于：Winsw 不会帮你解析 PATH 环境变量。如果你写<executable>python.exe</executable>，它会在C:\svc\myapp\目录下找python.exe，而不是去系统 PATH 里搜索。所以，要么把python.exe放进服务目录，要么写绝对路径C:\Python39\python.exe。

• <arguments>：传递给<executable>的命令行参数。这里有个致命陷阱：参数中的空格会被 Winsw 当作分隔符。比如你想传--config=config.yaml --log-level=warn，如果写成<arguments>--config=config.yaml --log-level=warn</arguments>，Winsw 会把整个字符串当作一个参数传给gateway.exe，导致程序解析失败。正确写法是用双引号包裹每个含空格的参数：<arguments>--config="config.yaml" --log-level="warn"</arguments>。更稳妥的做法是，把复杂参数写进一个.bat启动脚本，然后让<executable>指向这个 bat 文件。

• <env>：定义子进程的环境变量。<env name="PATH" value="..."/>是覆盖而非追加，所以如果你写了<env name="PATH" value="C:\svc\myapp"/>，那么子进程的 PATH 就只剩这一个目录，系统C:\Windows\system32里的netstat.exe等工具将无法调用。因此，必须显式包含系统路径：value="C:\svc\myapp;C:\Windows\system32"。另一个高频问题是GATEWAY_ENV=production，这个变量在 Python 中可通过os.getenv("GATEWAY_ENV")读取，但在 Windows CMD 中，%GATEWAY_ENV%是无效的——因为 Winsw 的环境变量只注入到子进程，不注入到 CMD shell。所以，不要指望在.bat脚本里用%VAR%，而要用set VAR=value在脚本内重新设置。

• <workingdirectory>：指定子进程的工作目录。这决定了gateway.exe启动时，./config.yaml这样的相对路径从哪里开始找。如果没设，它默认是C:\Windows\System32，你的配置文件肯定找不到。所以，只要你的应用依赖相对路径读取文件，就必须设置此项。

• <logmode>：日志模式有rotate（按大小滚动）、roll（按日期滚动）、reset（每次启动清空）、append（一直追加）。roll最常用，但要注意：Winsw 默认的日志文件名是service-name-yyyy-MM-dd.log，如果你的服务 ID 是iot-gateway，日志就是iot-gateway-2024-06-15.log。有些监控系统（如 ELK）需要固定文件名，这时就得用rotate模式，并配合<logpath>下的<logsize>参数（如<logsize>10485760</logsize>表示 10MB）。

• <onfailure>：这是 Winsw 最强大的功能之一，但它不是简单的“重启”。if="1"表示“当子进程退出码为 1 时”，if="2"是退出码为 2，if="3"是退出码为 3。Winsw 会按<onfailure>标签出现的顺序，从上到下匹配第一个满足条件的策略。所以，上面的配置意思是：退出码为 1，等 5 秒重启；退出码为 2，等 10 秒重启；退出码为 3，不处理；退出码为其他值（包括 0），则执行最后一个action="reboot"（重启机器）。这个机制让你能根据应用的退出码语义，做精细化故障响应。比如，你的 Go 程序约定：退出码 1=配置错误，2=网络不可达，3=数据库连接失败。那么你就可以让配置错误时快速重启（5秒），网络问题时稍等再试（10秒），而数据库挂了就直接重启服务器——这比所有服务都无差别重启，要专业得多。

• <stoptimeout>：当执行winsw.exe stop时，Winsw 给子进程多少毫秒时间来优雅退出。默认是 15000（15秒）。如果你的应用需要 20 秒清理缓存、关闭连接，就必须把这个值调大，否则 Winsw 会强制TerminateProcess()，导致数据丢失。我曾经在一个金融数据同步服务中，因为没调大这个值，每次服务停止时，最后一笔交易日志总是缺失，排查三天才发现是stoptimeout太短。

• <serviceaccount>：定义服务以哪个 Windows 账户身份运行。LocalSystem权限最高，能访问几乎所有系统资源，但安全性最低；LocalService权限较低，适合不需要访问网络的本地服务；NetworkService可以访问网络，但不能访问本地文件系统。生产环境强烈建议不要用LocalSystem，而应创建专用服务账户（如svc-iot-gateway），并赋予其最小必要权限。Winsw 3.x 支持<serviceaccount>的密码配置，但出于安全考虑，永远不要在 XML 里明文写密码，而应使用winsw.exe configure命令交互式设置，它会把密码加密存储在 Windows 凭据管理器中。

3.3 安装、启动与日常管理：三条命令走天下

Winsw 的管理命令极简，只有install、start、stop、restart、status、uninstall六个核心动作，但每个动作背后都有 Windows 服务 API 的深度调用。新手常犯的错误，是以为install就是“一键搞定”，其实它只是注册服务，真正的考验在start。

第一步：安装服务（winsw.exe install）以管理员身份打开 PowerShell，cd到C:\svc\myapp\，执行：

.\myapp.exe install

如果看到Service 'myapp' was installed successfully.，说明注册成功。此时，打开 Windows 服务管理器（services.msc），你应该能在列表里找到 “My Application Service”。但请注意：安装成功 ≠ 服务能启动。这只是把服务元数据写入 Windows 注册表，就像在房产局登记了房子产权，但房子还没装修好。

第二步：启动服务（winsw.exe start）紧接着执行：

.\myapp.exe start

如果返回Service 'myapp' started successfully.，恭喜，服务已运行。但别急着庆祝，马上验证：

• 打开服务管理器，确认服务状态是“正在运行”；
• 进入C:\svc\myapp\logs\，查看是否有myapp-2024-06-15.log生成，打开它，里面应该有你的应用输出的第一行日志（如INFO: Starting application...）；
• 如果你的应用监听了端口（如http://localhost:8080/health），用浏览器或curl http://localhost:8080/health测试是否可访问。

如果start失败，最常见的原因是：

• Access is denied：目录权限没给NT AUTHORITY\SYSTEM（回到 3.1 节，重新执行icacls命令）；
• The service did not respond...：你的应用启动太慢，超过了 Windows 服务的默认超时（30秒）。这时需要在 XML 中添加<stoptimeout>，并确保<executable>启动的是一个“快速返回”的程序（比如用start /b python.exe collector.py启动后台进程，而不是直接python.exe collector.py，后者会阻塞 Winsw）；
• Failed to start process: The system cannot find the file specified：<executable>路径写错了，或者文件不存在。用dir C:\svc\myapp\确认文件名拼写完全一致（注意大小写，Windows 虽不区分，但 Winsw 的路径解析有时会敏感）。

第三步：日常管理（status/restart/uninstall）

• .\myapp.exe status：返回RUNNING或STOPPED，这是最轻量的健康检查，比打开服务管理器快十倍；
• .\myapp.exe restart：等价于stop+start，但 Winsw 会确保原子性，不会出现“stop 成功但 start 失败，服务处于半死不活状态”的情况；
• .\myapp.exe uninstall：卸载服务，但不会删除你的配置文件和应用文件，只是从注册表移除服务项。这是安全的，可以随时重装。

还有一个隐藏技巧：Winsw 支持“调试模式”。当你不确定服务为何启动失败时，不要直接start，而是用：

.\myapp.exe start --debug

它会以控制台模式启动子进程（不进入服务会话），所有日志直接打印在 PowerShell 窗口里，你能实时看到ImportError或ConnectionRefusedError这类原始错误，比查日志快得多。我几乎每次部署新应用，都会先用--debug模式跑通，再切回正式服务模式。

4. 故障排查实战手册：从日志黑盒到精准定位的完整链路

4.1 日志分析三板斧：定位问题的黄金组合

Winsw 的日志系统是分层的，新手常误以为“看myapp.log就够了”，其实这是最大的认知盲区。Winsw 生成三类日志，必须协同分析：

1. Winsw 自身日志（winsw.log）：位于C:\svc\myapp\目录下（与 exe 同级），记录 Winsw 引擎的操作，如Installing service...、Starting process...、Process exited with code 1。这是第一道防线。如果服务启动失败，先看它。常见错误：

   • Failed to load configuration file：XML 文件名不匹配，或 XML 格式错误（如标签没闭合）；
   • Failed to start process: The parameter is incorrect：<arguments>里有非法字符，或路径含中文；
   • Failed to set service description：<description>标签内容超过 256 字符（Windows 限制），需截断。

2. 应用标准输出日志（myapp-yyyy-MM-dd.log）：这是你的应用print()或console.log()输出的地方。但如果应用崩溃太快（如启动时就import error），这条日志可能为空，因为 Winsw 还没来得及重定向 stdout。

3. Windows 事件查看器日志：这是终极兜底。当 Winsw 自身日志和应用日志都沉默时，打开eventvwr.msc→ Windows 日志 → 系统，筛选“来源”为Service Control Manager，查找事件 ID 7000（服务启动失败）、7009（服务响应超时）、7024（服务意外终止）。例如，事件 ID 7009 的详细信息里会写The iot-gateway service did not respond to the start or control request in a timely fashion，这直接告诉你：你的应用启动时间 > 30 秒，必须优化启动逻辑或增大stoptimeout。

我总结了一个“日志诊断决策树”，实操中百试百灵：

• 如果winsw.log有Process exited with code X，就去查你的应用文档，X 代表什么错误；
• 如果winsw.log显示Starting process...但没后续，而myapp.log为空，说明应用在 Winsw 重定向 stdout 前就崩溃了，此时必须用--debug模式；
• 如果winsw.log和myapp.log都正常，但服务管理器显示“正在启动”然后变“已停止”，一定是事件查看器里的 7009 错误，启动超时。

4.2 典型问题速查表：那些年我们共同踩过的坑

4.3 高级技巧：让 Winsw 服务具备“自我诊断”能力

Winsw 本身不提供 HTTP 健康检查接口，但你可以通过<extensions>插件系统，轻松集成。Winsw 3.x 内置了HttpHealthCheckExtension，只需在 XML 中添加几行配置，你的服务就拥有了/health端点：

<extensions> <extension enabled="true" className="winsw.Extensions.HttpHealthCheckExtension"> <port>9090</port> <path>/health</path> <response>OK</response> </extension> </extensions>

配置后，Winsw 会启动一个内置的 HTTP 服务器，监听localhost:9090/health