NSSM软件介绍

先把 NSSM 讲透，再给你 10 款同类工具的“五优五缺 + 可靠/安全排序”。结论先放前面：NSSM 是“能用、好用、但不适合再作为生产首选”的经典工具，新项目建议优先考虑 WinSW 或更现代的封装方案。

一、NSSM 到底是什么

NSSM（Non-Sucking Service Manager，官方 2.26 起改名 Native System Service Manager）本质是一个服务外壳：你把 nssm.exe 注册成 Windows 服务，它负责跟 SCM（服务控制管理器）通信，真正跑起来的是被它 fork 出来的子进程（你的 exe / 脚本 / jar / py）。

核心能力就四条：

• 把任意控制台程序包装成标准 Windows 服务
• 监控子进程，挂了按策略拉起（带退避节流）
• 重定向 stdout/stderr 到日志文件，支持按大小轮转
• 优雅停止：Ctrl+C → WM_CLOSE → WM_QUIT → 强杀

官方定位和健康检查边界说得很清楚：它只看“进程死没死”，不做业务级健康检查。

二、NSSM 的优点

1. 零依赖单文件
   ：纯 C 写的原生 exe，300KB 左右，不挑运行时，Win7 到 Server 2025 都能跑，老机器救急神器。
2. GUI + CLI 双模式
   ：nssm install 弹图形界面改参数，nssm set/get 走脚本，运维和自动化都顺手。
3. 进程级自愈
   ：不是 srvany 那种“假运行”，子进程崩了真重启，还支持退出码区分（0=正常退出不拉起，非0=异常重启）、重启节流（1.5s→2s→指数退避到256s）。
4. 日志与停止信号到位
   ：stdout/stderr 落盘 + 事件查看器，停止时先发信号再强杀，比 sc 直接 TerminateProcess 温柔得多。
5. 公共域授权
   ：public domain，随便改、随便嵌，没有授权负担。

三、NSSM 的缺点（生产环境必须知道的坑）

1. 实质停更
   ：正式稳定版停在 2.24（2014-08-31），之后只有 2017 年的预发布构建，没有持续维护节奏。新 Windows 的兼容 bug 靠社区自己绕。
2. 已知未修 bug 堆积
   ：Win10 1703+ 启动失败需 AppNoConsole=1、XP 崩溃、>4GB 日志轮转失效、重启时线程句柄泄漏、无管理员权限时可能死循环——这些在 2.24 里都列着，得用预发布版才修。
3. 无数字签名 + 易被杀软误报
   ：官网二进制没 Authenticode 签名，企业环境常被 Defender/EDR 标成“风险工具/黑客工具”，红队也拿它做持久化，供应链风险偏高。
4. 安全模型落后
   ：启动参数、环境变量、凭证明文存在 HKLM\SYSTEM\CurrentControlSet\Services\Parameters 注册表，本地任意用户可读；没有凭据加密、没有每服务隔离边界。
5. 只管“进程活着”不管“业务健康”
   ：程序假死、端口没监听、内存泄漏、子进程孤儿化——NSSM 眼里全是“运行中”。也没有 CPU/内存上限、没有健康检查、没有资源隔离。

四、为什么停更这么久（讲人话版）

不是技术难题，是项目性质决定的：

• 个人开源项目
  ：作者 Iain Patterson 一个人维护，没有商业公司背书，没有 SLA。
• 需求边界清晰且“做完”了
  ：服务包装器的核心协议（SCM 通信、进程守护、日志重定向）在 2.24 时代就基本定型，没有持续迭代的业务动力。
• Windows 服务模型本身在边缘化
  ：微软主推的是 .NET Worker Service、容器、云原生，而不是“把老 exe 塞进服务”。NSSM 是典型的“过渡期工具”。
• 预发布分支其实有修，只是不发包
  ：git 里能看到 2.25 的修复，但作者不认为达到了“正式 release”的标准，所以官网稳定版一直没动。
• 安全加固不是个人项目能轻松扛的
  ：代码签名、SBOM、漏洞响应、CVE 流程，这些要花钱花人力，个人维护者很难持续。

实操建议：NSSM 可以继续用，但只用在内部临时运维、开发机、边缘设备；生产服务器要么用预发布新版（2.24-101+），要么换下面推荐的现代方案。

五、十款同类/替代工具（按可靠性+安全性综合排序）

排序逻辑：先排“出事概率”（崩溃恢复、权限隔离、签名供应链），再排“安全模型”（明文/加密、最小权限、审计），功能多寡放后面。

🥇 1. WinSW（最均衡的开源首选）

优点

1. XML 配置可进 Git，版本化、可审计、可 CI/CD 分发
2. 活跃维护，Jenkins 官方同款，社区问题容易搜到
3. 日志轮转、pre/post 钩子、失败恢复策略比 NSSM 细
4. 支持服务账号、环境变量隔离、优雅停止命令
5. 有签名构建，企业环境落地阻力小

缺点

1. 依赖 .NET（新版要 .NET 6+，老系统得选 NET4 构建）
2. 没有图形化管理界面，排障靠读 XML 和日志
3. 配置错误时服务卡 START_PENDING，新手排查成本略高
4. XML 里密码/环境变量仍是明文，需配合 DPAPI 或外部密钥管理
5. 多实例批量管理没有原生集中控制台

新项目默认选它。

🥈 2. FireDaemon Pro（商业·企业级最稳）

优点

1. Job Objects 管整个进程树，子进程清理干净，不留僵尸
2. 支持 gMSA/dMSA、per-service DACL、Service SID，最小权限做得专业
3. 崩溃/挂起/内存超限都能触发恢复，ETW 日志 + 实时资源监控
4. 数字签名 + VirusTotal 验证 + 25 年生产验证，供应链可信
5. Fusion 中心化管理 + REST API，多机集群好运维

缺点

1. 商业授权，单机 $75/年，企业版不便宜
2. 功能多意味着配置面复杂，小场景用起来偏重
3. 闭源，安全审计只能信厂商
4. 深度依赖 Windows 生态，跨平台无解
5. OEM/批量部署要单独谈授权

金融、医疗、工控这类“宕机=事故”的场景首选。

🥉 3. AlwaysUp（商业·易用性最好）

优点

1. GUI 极度友好，填路径+名字就能跑，非运维也能用
2. 除崩溃重启外，还能检测“假死/吃内存/卡对话框”并自动恢复
3. 邮件/事件日志告警，支持自定义 sanity check 脚本
4. 无 Java/.NET 运行时依赖，原生轻量
5. 企业安全：本地存储、Group Policy 下发、Defender/BitLocker 兼容

缺点

1. 闭源商业，单授权约 $49.99 一次性（批量另算）
2. 配置不版本化，多环境迁移靠导出/手动
3. 高级隔离（per-service DACL、gMSA）不如 FireDaemon 细
4. 观察性弱于 FireDaemon，没有实时资源图
5. 过度依赖 GUI，纯自动化流水线要额外封装

4. Servy（新兴开源·安全设计最现代）

优点

1. 每服务隔离边界 + DPAPI/AES-256 加密参数，解决 NSSM 明文注册表痛点
2. GUI + CLI + PowerShell 三件套，CI/CD 友好
3. 健康检查、心跳 URL、Webhook/Slack/Teams 告警原生支持
4. 进程树清理、实时 CPU/内存图、日志流式预览
5. 签名发布 + SBOM + 漏洞扫描，开源里安全姿势最正

缺点

1. 项目较新（2025 起），生产案例和社区厚度不如 WinSW
2. 文档和边缘场景覆盖还在补全
3. 功能堆得多，简单场景反而觉得重
4. 依赖 Windows 7+ x64，老 Win32 环境不支持
5. 生态插件/第三方集成暂不及前两者

愿意尝鲜、重视安全合规的团队可以上。

5. sc.exe + 原生服务（最稳但门槛最高）

优点

1. 系统自带，零第三方依赖，攻击面最小
2. 原生服务协议，SCM 交互最标准，没有中间层
3. 权限模型清晰，可用虚拟服务账号/托管服务账号
4. 无额外进程常驻，性能损耗最低
5. 组策略、审计、WSUS 全链路原生可管

缺点

1. 只适用于“程序本身实现了 ServiceMain”的二进制，普通 exe 直接注册会 1053 报错
2. 没有进程守护，程序崩了就是崩了，得靠 sc failure 配恢复
3. 配置在注册表，不直观，批量分发靠脚本
4. 日志、环境变量、工作目录都要自己写
5. 对开发侧要求高，运维不能独立搞定

6. TopShelf / .NET Worker Service（开发态最优）

优点

1. 代码即服务，启动/停止/暂停全生命周期类型安全
2. 天然接入 .NET 日志（Serilog、OpenTelemetry）、DI、配置系统
3. 可跨 Windows/Linux 容器，未来迁移不绑死 Windows
4. 支持优雅关闭、健康检查、BackgroundService 模式
5. 配合 dotnet publish 自包含部署，无运行时依赖

缺点

1. 只适合 .NET 技术栈，非 .NET 程序用不了
2. 要改代码，不能“裸包一个现有 exe”
3. TopShelf 已逐步被 Microsoft.Extensions.Hosting 取代，旧项目有迁移成本
4. 权限、日志轮转仍要自己接
5. 对小脚本/遗留程序属于杀鸡用牛刀

7. 任务计划程序（Task Scheduler）

优点

1. 系统原生，无需任何第三方工具
2. “计算机启动时/登录时”触发，支持失败重试、最长运行时间
3. 可指定运行账号、权限级别、是否仅在网络可用时跑
4. 适合“跑完就退”的脚本，不会像 NSSM 那样死循环拉起
5. 审计策略、组策略统一管理方便

缺点

1. 不是真服务，不在服务列表里，不能被其他服务依赖
2. 进程守护弱，崩溃后重启策略粗粒度
3. 停止时难以优雅通知子进程
4. 日志、输出重定向全靠自己
5. Session 0 隔离下行为诡异，GUI 程序基本不可控

定时任务/一次性作业用它，常驻服务别用。

8. NSSM（你自己问的，排这里）

优点：见上文（零依赖、快、GUI、自愈）

缺点：见上文（停更、无签名、明文、无健康检查）

定位：开发机/内网临时托管，别再作为生产标准。

9. srvany + instsrv（微软遗产，基本淘汰）

优点

1. 微软旧版 Resource Kit 官方工具，历史兼容性好
2. 极小体积，两个 exe 搞定
3. 原理简单，容易理解
4. 不挑程序语言
5. 适合维护 2003/2008 老系统的存量包袱

缺点

1. 微软已放弃维护，新 Windows 无官方支持
2. 无进程监控，程序崩了服务仍显示“已启动”
3. 无日志、无优雅停止、无重启策略
4. 配置靠手改注册表，易错
5. 权限/隔离能力几乎为零

只剩“老系统不敢动”的场景才碰。

10. 自研 ServiceBase 包装器 / RunAsSvc 类小众工具

优点

1. 完全可控，想怎么管就怎么管
2. 可内建健康检查、指标上报、密钥拉取
3. 无第三方信任链风险（代码自己签）
4. 能针对业务做精细化生命周期钩子
5. 可嵌入产品安装包，用户体验“无感”

缺点

1. 开发维护成本最高，容易写出新 bug
2. SCM 协议细节多，停止/暂停/继续状态机难写对
3. 没有社区兜底，出问题自己查
4. 小众工具（RunAsSvc 等）成熟度、签名、更新都不稳定
5. 安全模型要自己从头做，稍漏就是漏洞

六、选型速查表

七、生产落地的几条硬建议

• 永远别用 LocalSystem 跑业务服务
  ：建专用低权账号或虚拟服务账号，只给程序目录+所需端口。
• NSSM/WinSW 的配置文件、注册表参数里别塞明文密码
  ：用 Windows Credential Store、DPAPI、或外部密钥管理（比如你们做邮件服务器时同理，凭证走系统凭据库）。
• 服务化前先确认程序不需要桌面交互
  ：Session 0 里弹窗=卡死，有 GUI 的用 FireDaemon Zero 之类桥接。
• 健康检查要自己补一层
  ：包装器只管进程，业务健康用 /health 接口或外部探针（Prometheus node_exporter + 黑盒探测）。
• 日志轮转必须开
  ：NSSM 的 AppRotateBytes、WinSW 的 logmode，别让 stdout 把盘写满。
• 杀软白名单提前申请
  ：第三方服务包装器 exe 在上线前先过 EDR 策略，不然半夜被删。

接下来你更想先看哪类实操内容：部署配置模板，还是安全加固清单？