NSSM 和 WinSW 是两个广泛使用的 开源工具，用于在 Windows 系统上将任意可执行程序（尤其是 Java、Python、Node.js 等后台应用）注册为 Windows 服务（Windows Service）。它们解决了“如何让一个普通程序像系统服务一样开机自启、后台运行、自动恢复”的问题。

虽然目标相似，但两者在设计哲学、实现方式和适用场景上有明显区别。下面分别详解，并做对比。

---

一、NSSM（Non-Sucking Service Manager）

🔹 简介

• 全称：Non-Sucking Service Manager
• 官网：https://nssm.cc/
• 开源协议：Public Domain（无版权约束）
• 作者：Andy Wicks
• 特点：轻量、简单、命令行驱动、零依赖

🔹 核心功能

NSSM 是一个 独立的 .exe 工具，通过命令行将任何程序包装成 Windows 服务。

基本用法示例：

1# 安装服务
2nssm install MyJavaApp "C:\myapp\jre\bin\java.exe" "-jar myapp.jar"
3
4# 启动服务
5net start MyJavaApp
6
7# 卸载服务
8nssm remove MyJavaApp confirm

🔹 关键特性

功能	说明
重定向 stdout/stderr	可指定日志文件（如 C:\logs\app.log）
环境变量设置	支持为服务进程设置自定义环境变量
工作目录	可指定启动时的当前目录
重启策略	支持失败后自动重启（通过 Windows 服务恢复机制）
无 GUI 配置界面	纯命令行或修改注册表

🔹 适用场景

• 快速将 Java/Python/Go 等程序转为服务
• DevOps 自动化脚本中集成（如 Ansible、Chef）
• 不需要复杂配置的轻量级部署

✅ 优点：极简、稳定、几乎不更新（因为“够用就好”）
❌ 缺点：配置不够灵活，高级功能（如用户切换、依赖服务）需手动调注册表

---

二、WinSW（Windows Service Wrapper）

🔹 简介

• 全称：Windows Service Wrapper
• GitHub：https://github.com/winsw/winsw
• 开源协议：MIT
• 起源：最初为 Jenkins CI 设计，后独立为通用工具
• 特点：基于 XML 配置、功能丰富、支持 .NET

🔹 核心机制

WinSW 本身是一个 .exe（如 WinSW.exe），配合一个同名的 XML 配置文件（如 myapp.xml）工作。

目录结构示例：

1myapp/
2├── WinSW.exe          ← 重命名为 myapp.exe
3├── myapp.xml          ← 配置文件（必须同名）
4├── app.jar
5└── logs/

myapp.xml 示例：

1<service>
2  <id>MyJavaApp</id>
3  <name>My Java Application</name>
4  <description>A background Java service.</description>
5  <executable>C:\myapp\jre\bin\java.exe</executable>
6  <arguments>-jar "C:\myapp\app.jar"</arguments>
7  <logpath>C:\myapp\logs</logpath>
8  <log mode="roll-by-size-time">
9    <sizeThreshold>10240</sizeThreshold> <!-- 10MB -->
10    <pattern>yyyyMMdd</pattern>
11  </log>
12  <startmode>Automatic</startmode>
13  <depend>Winmgmt</depend> <!-- 依赖其他服务 -->
14  <serviceaccount>
15    <domain>.\LocalSystem</domain>
16  </serviceaccount>
17</service>

安装服务：

1myapp.exe install   # 读取 myapp.xml 并注册服务
2myapp.exe start
3myapp.exe stop
4myapp.exe uninstall

🔹 关键特性

功能	说明
XML 配置驱动	所有参数集中管理，版本可控
日志轮转	支持按大小/时间自动分割日志
服务依赖	可声明依赖其他 Windows 服务
用户上下文	支持以特定用户身份运行（包括密码加密存储）
扩展性	支持启动/停止前后的脚本钩子（pre/post scripts）
.NET 实现	可作为库嵌入其他 .NET 应用

🔹 适用场景

• 企业级 Java 应用部署（如 Spring Boot 后台服务）
• 需要精细控制服务行为（日志、权限、依赖）
• 配置需纳入版本管理（XML 文件可 Git 跟踪）

✅ 优点：配置强大、日志管理优秀、社区活跃
❌ 缺点：依赖 .NET Framework（旧版）或 .NET Runtime（新版），体积略大

---

三、NSSM vs WinSW 对比总结

特性	NSSM	WinSW
配置方式	命令行参数 / 注册表	XML 文件
日志管理	简单重定向到文件	支持轮转、归档、时间戳
安装复杂度	极简（一行命令）	需准备 XML
依赖	无（纯 Win32）	需 .NET（v2+ 需 .NET 4.6.1+ 或 .NET 6+）
服务账户支持	有限（需命令行指定）	完整（XML 中配置，支持加密密码）
钩子脚本	❌ 不支持	✅ 支持 pre-start / post-stop 脚本
跨平台	❌ Windows only	❌ Windows only
典型用户	运维工程师、自动化脚本	Java 企业应用、CI/CD（如 Jenkins）

---

四、与 WinRun4J 的关系

• WinRun4J：自身是 Java 启动器 + 内置服务支持（EXE 直接注册服务）
• NSSM / WinSW：外部包装器，不关心内部是什么程序（Java/Python/Node 均可）

🔄 迁移建议：

• 若你已用 WinRun4J 且运行稳定 → 可继续使用
• 若需更强日志/配置管理，或迁移到 Java 17+ → 推荐 WinSW + jpackage 生成的 exe
• 若追求极简快速 → 用 NSSM

---

五、现代替代方案（补充）

• Windows 内置方案：
  • sc.exe：Windows 自带服务创建工具，但配置繁琐
  • PowerShell：New-Service cmdlet，适合简单场景
• 容器化：
  • 使用 Docker Desktop for Windows + --restart=always
  • 或 Windows Container 运行 Java 应用（适合云原生架构）

---

总结

工具	定位	推荐场景
NSSM	“瑞士军刀式”轻量服务包装器	快速部署、脚本自动化
WinSW	“企业级”服务管理器	Java 应用生产部署、需日志轮转/权限控制
WinRun4J	Java 专用启动器+服务	老旧 Java 8 项目，无需外部依赖

💡 最佳实践：对于新项目，推荐 jpackage 打包 + WinSW 管理服务，兼顾独立性、安全性和可维护性。