NSSM教程：将任意程序注册为Windows服务，实现开机自启动与崩溃恢复

1. NSSM到底是什么，为什么我们需要注册服务

提到Windows下的服务管理，很多人第一反应是“又不是不能用sc命令”，但真正折腾过的人都知道，原生sc create做出来的服务既不能方便地设置重启策略，也不能给程序配置环境变量和工作目录，更别提日志重定向这些实际部署里的刚需。NSSM，全称Non-Sucking Service Manager，翻译过来大概就是“不辣鸡的服务管理器”，它解决的问题非常直接：让你用一条命令甚至一个图形界面，把任意exe、bat、cmd、Python脚本、Node应用、Java进程注册成Windows服务，管理它的启动、停止、崩溃自动重启、日志输出，还能设置开机自启动。

我最早用NSSM是在帮同事部署一个内网工具的时候。那是一个Python写的定时任务，以前靠任务计划程序跑，但任务计划在系统重启后偶尔会丢状态，进程挂掉也不会自动拉起。换用NSSM注册成服务后，一条nssm install搞定，设置好Application、参数、日志路径，后面再没操心过。这篇文章就打算把这段时间积累的完整操作和经验写下来，从下载工具、图形化配置、命令行参数，到开机自启动的原理、常见坑的排查，一次讲清楚。

不管是运维、开发，还是自己电脑上要挂个常驻程序，这篇文章都能帮上忙。我尽量按“直接抄作业”的方式写，同时把关键步骤背后的原因也讲透，这样遇到新问题你也能自己判断。

2. 动手前的准备：NSSM下载、版本选择与基本概念

2.1 下载哪些文件，版本怎么选

NSSM是免费开源的，官方地址是nssm.cc。进去以后下载页面会给一个zip包，里面按32位和64位分成了win32和win64两个文件夹。这里有个常见的坑：不是看系统是64位就一定用win64，你要看目标程序是32位还是64位。比如你有个老旧的32位exe要注册，用64位的NSSM也能管理，但官方推荐匹配程序位数，减少某些兼容性问题。一般情况下一律建议用win64，因为绝大多数现代程序都是64位了。

还有一个细节，NSSM有两个主要分支：2.x正式版和3.x开发版。2.24是目前最稳定的版本，网上搜到的中文教程基本都以它为准。3.x增加了环境变量导入、更细的日志控制等功能，但3.x是预发布版，商用或者生产环境我建议保守用2.24。下载zip后解压到比如D:\tools\nssm-2.24，把里面的nssm.exe拷到C:\Windows\System32也可以，但我不推荐直接扔系统目录，因为升级或卸载时不方便清理。更好的做法是放到一个固定目录，并把目录加到系统Path里，或直接在命令行里切换到该目录操作。

2.2 服务、进程、守护三个概念的辨析

在注册之前，最好把NSSM背后涉及的三个概念理清楚，很多配置选项看不懂就是这里糊涂。

• 服务（Service）：Windows服务由服务控制管理器（SCM）统一管理，可以设置为开机自启动、依赖关系、恢复选项。服务一般以SYSTEM或指定账户运行，不依赖用户登录会话。
• 进程（Process）：你写的exe、bat、Python脚本，本质上是一个被启动的进程。NSSM本质上是个“包装器”，它启动你的程序，然后持续监视。
• 守护（Daemon）：NSSM充当守护进程，当你的程序崩溃或被关闭时，它会根据配置尝试重新拉起。这有点像Docker的restart policy，或者Linux里的systemd service。

NSSM把这三者结合：它先把自己注册为Windows服务，服务启动后，NSSM进程再创建你的目标程序进程，并等待它。如果目标进程退出，NSSM根据退出状态码决定是否重启以及等待多久。理解了这一层，你就能明白为什么NSSM可以很方便地实现“开机自启动”了——其实不是NSSM自己开机运行，而是Windows的SCM在开机时自动启动“服务”，服务启动后NSSM再拉起子进程，子进程就是你的程序。

2.3 图形界面还是命令行？看场景选择

NSSM提供了两种交互方式：一是直接运行nssm install弹出图形窗口，适合临时配置，能直接看到所有选项；二是纯用命令行参数，像nssm install 服务名 "程序路径" 参数，适合脚本批量部署。我个人的经验是：首次配置用图形界面熟悉选项，后期写成批处理或自动化脚本时全部用命令行，这样所有配置都能版本化管理。

另外要注意，NSSM的所有配置最终都写在注册表：HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\服务名。也就是说，如果你愿意，也可以直接改注册表，但不建议，NSSM已经做了很好的封装，没必要去碰底层。

3. NSSM注册服务的完整实操过程

3.1 基础注册命令：图形界面方式

我们拿一个常见的场景举例：给一个Java Spring Boot的jar包注册服务，方便开机自启动。假设java.exe位于C:\Program Files\Java\jdk17\bin\java.exe，jar包位于D:\app\myapp.jar。

第一步，打开命令行（管理员权限），切换到NSSM所在目录，或者使用绝对路径：

code复制D:\tools\nssm-2.24\win64\nssm.exe install MyApp

命令执行后立刻弹出图形窗口。这里面最关键的就几个字段：

• Application path：程序完整路径。填C:\Program Files\Java\jdk17\bin\java.exe。注意，如果路径含空格，务必用引号，但窗口内直接填可执行文件路径，不需要引号，NSSM会自己处理。
• Startup directory：工作目录。这个必须填，比如填D:\app。不填的话可能出现找不到相对路径的配置文件问题。
• Arguments：程序参数。对于jar包，填：

  code复制-jar myapp.jar
  

  这里参数可以包含空格，会被原样传给java。

点“Install service”，弹出窗口提示安装成功。此时去服务管理器（Win+R输入services.msc）就能看到MyApp服务了。但它默认没有启动，你可以右键启动或者用命令：

code复制nssm start MyApp

3.2 用命令行参数实现无人值守注册

如果要在多台机器上批量部署，用图形界面效率太低。NSSM支持所有配置项作为命令行参数传入。刚才的例子用命令行执行：

code复制nssm install MyApp "C:\Program Files\Java\jdk17\bin\java.exe" -jar myapp.jar

但这样只是设置了最基础的启动命令，工作目录、日志、重启策略都还没设置，所以完整的自动化脚本还需要补上其他参数。比如：

code复制nssm set MyApp AppDirectory D:\app
nssm set MyApp AppParameters "-jar myapp.jar"
nssm set MyApp AppStdout D:\logs\myapp.out.log
nssm set MyApp AppStderr D:\logs\myapp.err.log
nssm set MyApp AppRestartDelay 5000
nssm set MyApp Start SERVICE_AUTO_START

这里解释一下参数的含义：

• AppDirectory：设置工作目录，作用等同于图形界面的Startup directory。
• AppParameters：程序启动参数，如果之前install时已经传了，再set会覆盖。
• AppStdout 和 AppStderr：将程序的标准输出和错误输出重定向到指定文件。
• AppRestartDelay：进程崩溃后重启前的等待毫秒数。
• Start SERVICE_AUTO_START：设置服务为“自动”启动类型，这就是开机自启动的关键。

以上是命令行最常用的一组。每一条nssm set都会修改注册表中的对应键值，不会立即重启服务。配置全设置完之后，用nssm start MyApp启动即可。

3.3 为什么工作目录和环境变量影响巨大

我在给别人排错时，遇到的第一大坑就是工作目录。如果你的程序读取的是相对路径的配置文件，比如application.properties或logs/目录，那么工作目录不对，程序直接闪退。NSSM默认的工作目录在哪里？如果你用图形界面install时没填Startup directory，它会保存为可执行文件所在的目录。但Java的jar、Python脚本这类情况，可执行文件是解释器（java.exe/python.exe），工作目录默认为解释器目录，这几乎必然出错。

所以建议每次注册都明确设置AppDirectory。另外还有一个环境变量问题：NSSM默认服务的环境变量和系统环境继承，但如果你的程序需要自定义的环境变量，可以在NSSM的“Environment”标签页添加，也可以用命令：

code复制nssm set MyApp AppEnvironmentExtra {"MY_VAR=value", "OTHER=123"}

这个语法比较隐蔽，第一次用容易写错。注意是用{}和逗号分隔，每个字符串内部不要有逗号。如果变量值含空格，要写在一对双引号内。

3.4 图形界面里那些容易被忽略的选项卡

很多教程只讲了“Install service”，但NSSM窗口里其实藏着大量实用配置。

• Shutdown选项卡：默认情况下，停止服务时，NSSM会让目标进程优雅退出，也就是发出Ctrl+C或关闭消息，而不是强杀。如果你的程序没有处理关闭信号，NSSM会等待一段时间，然后执行taskkill /T强制关闭。这里的超时时间Throttle可以调整。

• Exit actions选项卡：配置服务停止后是否重新启动进程。默认情况下，停止服务就会停止子进程。但有些需求是“服务停止时也要让子进程自动拉起”，那就要设置“Restart”作为退出动作之一。不常用，但遇到特殊场景时需要知道。

• I/O选项卡：日志文件的配置都在这里，可以设置输出重定向、滚动日志、旋转大小。生产环境强烈建议开启日志重定向，否则程序日志会丢失，排查问题没有依据。

• Process选项卡：可以设置进程优先级、CPU亲和性等，不过大部分程序用默认就好。

我对新手的建议是：第一次配置只用基础三件套（路径、目录、参数）加日志，注册成功后验证效果，再逐步去尝试这些高级选项。不要上来就全部勾上，改错了反而更难排查。

4. 开机自启动的设置原理与常见误区

4.1 如何确保服务真的“开机自启动”

NSSM注册的服务，默认启动类型是“自动”（SERVICE_AUTO_START），也就是说开机时SCM会自动启动它。但Windows里还有另一个概念叫“延迟自动启动（Automatic Delayed Start）”，NSSM图形界面中有“Startup type”下拉框，你选择“Automatic”即可。如果你希望开机后稍微延迟一点，避免和其他服务抢资源，可以选“Automatic (Delayed Start)”。命令行设置则是：

code复制nssm set MyApp Start SERVICE_AUTO_START

或者延迟：

code复制nssm set MyApp Start SERVICE_DELAYED_AUTO_START

这里有个易错点：注册服务之前，服务是不存在的，nssm install会默认设置为自动启动。但如果你不小心在图形界面把Startup type改成了Manual，那么服务不会开机自启，需要手动启动。所以修改完一定要检查一下服务的启动类型。

另外，Windows服务的启动和用户登录无关，即使没有用户登录，服务也会在系统启动阶段拉起。这是跟“启动文件夹”、“注册表Run键”最大的不同。如果你需要程序在用户登录后才运行（比如访问用户目录下的资源），那才应该考虑启动文件夹或计划任务，而不是用NSSM。

4.2 开机自启失败：账户权限和登录会话问题

很多朋友把服务设成自动后依然没跑起来，原因往往出在服务账户。默认情况下，NSSM安装的服务使用LocalSystem账户，这拥有极高权限，但缺点是它不访问网络共享的某些凭据、也不能访问加密的文件夹。

如果程序需要访问网络路径，比如读取\\192.168.1.10\share\config.ini，LocalSystem账户可能没有权限。解决办法是在服务属性里将“此账户”改为一个有权限的域账户或本地账户，同时勾选“允许服务与桌面交互”在某些老程序中有用，但新程序一般不需要。

还有一个非常隐蔽的问题：如果你在命令行以普通用户权限运行nssm install，服务注册可能失败或出现在当前用户会话下产生奇怪问题。因此，所有NSSM的install/set/start操作，都建议用管理员权限的cmd或PowerShell执行。右键“以管理员身份运行”是必须的。

4.3 服务启动失败时，系统返回的错误码含义

NSSM本身是服务，服务启动时如果报错，事件查看器里会记录错误码。常见的：

• 1053：服务没有及时响应启动请求。通常是目标程序启动慢，NSSM超时了。解决方法是在AppExit或服务超时相关设置里增加超时时间，或者换用延迟自启动。
• 1067：进程意外终止。看NSSM日志和事件日志，通常程序自身崩溃。
• 2：系统找不到指定的文件。这个大概率是Application path写错了，或路径里转义有问题。
• 5：拒绝访问。权限不足，服务账户没有访问程序目录或日志目录。

遇到这些错误，先看C:\Windows\System32\winevt\Logs\System.evtx里的System事件日志，里面会明确指出是哪个服务失败，错误码多少。然后把NSSM的日志重定向打开，再看程序输出的错误。

5. 日志配置、环境变量和进程守护的高级玩法

5.1 日志重定向的正确姿势

很多程序本身有日志功能，但如果你注册成服务后不把标准输出/错误输出重定向到文件，一旦程序崩溃，信息就石沉大海。NSSM的日志配置可以做到：把stdout写入一个文件，stderr写入另一个文件，并支持按大小或时间滚动。

图形界面在I/O选项卡，最常用的是这两个字段：

• Output (stdout)：输出日志路径
• Error (stderr)：错误日志路径

命令行对应：

code复制nssm set MyApp AppStdout D:\logs\myapp_stdout.log
nssm set MyApp AppStderr D:\logs\myapp_stderr.log

需要注意：如果程序本身有控制台输出+日志框架，那么stdout不一定包含太多信息。但如果你的程序是批处理或简单脚本，stdout基本就是全部运行记录了，这个配置就是救命稻草。

滚动日志的设置在命令行是：

code复制nssm set MyApp AppStdout D:\logs\myapp_stdout.log
nssm set MyApp AppStdoutTimestamp 1
nssm set MyApp AppRotateFiles 1
nssm set MyApp AppRotateOnline 1
nssm set MyApp AppRotateBytes 10485760

上面配置的含义：在stdout日志中加时间戳、开启文件轮转、在线轮转（即不停止服务也轮转）、轮转大小20MB（1010241024=10485760）。这个对长期运行的进程特别关键，否则一个日志文件可以膨胀到几十GB，把磁盘塞满。我见过真实事故：某服务日志写了3个月，单文件100多GB，最后磁盘爆掉，服务起不来。所以生产环境务必配置轮转。

5.2 崩溃自动重启的那些细节

NSSM最强的功能之一是当程序崩溃或退出时，自动重启。这在图形界面的“Exit actions”里可以设置，命令行常用参数：

code复制nssm set MyApp AppExit Default Restart
nssm set MyApp AppRestartDelay 5000

AppExit Default Restart表示对于所有默认退出码，服务都会去重启进程。AppRestartDelay是重启前等待的毫秒数，5000表示5秒后重启。这个延迟很重要，防止程序因为环境问题（比如依赖的数据库没就绪）陷入快速无限重启循环。

还有一个细节：如果程序是被某个错误码固定触发重启，你还可以针对特定退出码单独设置：

code复制nssm set MyApp AppExit 255 Restart
nssm set MyApp AppExit 1 Exit

这种配置极少用，但如果你知道程序会用特定退出码表示“参数错误，别再重启了”，就可以这样写。

需要注意的是，AppExit Default Restart会对所有退出码生效，包括程序正常退出。如果你的程序可能因为业务原因主动调用exit(0)，那么默认重启会导致它反复起来，从而带来副作用。这时你可以设置：

code复制nssm set MyApp AppExit 0 Exit

即退出码0时不重启，其他都重启。这个逻辑要想清楚，才能避免踩坑。

5.3 多实例注册和环境变量共享的技巧

有时候你需要运行同一个程序的多个实例，比如两个不同端口的Node服务，只需要注册两个不同的服务名，分别指定工作目录和参数即可。注意每个服务名必须唯一，比如MyApp_8080、MyApp_9090。

环境变量方面，NSSM除支持AppEnvironmentExtra外，还有AppEnvironment参数（覆盖全部环境变量）。如果程序依赖大量环境变量，我更推荐直接在系统环境变量里添加，或者写一个启动bat，在bat里先set好变量再启动程序，然后用NSSM把bat注册为服务。这样把环境变量逻辑放在脚本里，更容易排查。比如启动脚本：

code复制@echo off
set JAVA_HOME=C:\Program Files\Java\jdk17
set PATH=%JAVA_HOME%\bin;%PATH%
cd /d D:\app
java -jar myapp.jar

然后用nssm install BatApp，Application path填C:\Windows\System32\cmd.exe，Arguments填/c D:\app\start.bat。这个方法虽然多一层cmd，但胜在脚本可读性好，环境变量和工作目录都不需要在NSSM里配复杂参数。我自己的很多工具都用这种方式，维护起来非常方便。

提示：bat方式有一个坑——如果你直接在nssm的Application path里填D:\app\start.bat，NSSM不会直接执行bat（因为bat需要cmd解释器）。除非系统关联了.bat到cmd，但服务环境下不一定可靠，所以最稳妥是用cmd.exe /c启动。

5.4 如何验证服务是否真的在开机自启

配置完成后，最好做一次重启验证。但不用真的等开机，可以用命令查询服务当前配置：

code复制sc qc MyApp

输出结果里会有一行START_TYPE，如果是AUTO_START就是自动启动。再用nssm status MyApp查看运行状态。如果你想测试服务能正常启动，先停掉再启动：

code复制nssm stop MyApp
nssm start MyApp

另外，services.msc里查看“启动类型”列，如果是“自动”即可。如果重启后总是没起来，还需要检查“恢复”选项，Windows对服务有三次失败后的操作控制，默认是“不操作”，也可能导致服务在开机没能自动拉起时不会再次尝试。你可以在服务的“恢复”选项卡里设置“第一次失败：重新启动服务”，或者用NSSM内部的重启策略，两者不冲突。通常NSSM的AppExit Restart已经能覆盖程序退出场景，不需要额外设置SCM恢复，但如果NSSM进程本身被系统杀掉（极少见），SCM恢复才有意义。

6. 卸载服务、修改配置和常见问题速查

6.1 如何干净地卸载服务

卸载NSSM服务非常方便：

code复制nssm remove MyApp

它会弹窗确认，或者直接加confirm参数来自动确认：

code复制nssm remove MyApp confirm

执行后服务被删除，注册表里对应键也没了。注意：停止服务并删除后，NSSM创建的日志文件、程序文件都不会自动删除，需要手动清理。如果你要彻底卸载NSSM本身，把解压的文件夹删除即可，因为它没有安装程序，不写系统目录（除非你手动复制到System32）。

6.2 修改服务配置的两种方式

改配置有两种路径：一是重新打开图形界面，但图形界面安装时对应的是install，如果你想修改已有服务，可以用：

code复制nssm edit MyApp

这个命令弹出图形窗口，可以修改当前服务配置。二是继续用nssm set命令逐个改，改完直接生效，不必重启服务。有些配置需要重启服务才生效，比如AppDirectory、AppParameters，建议依次：

code复制nssm restart MyApp

6.3 常见问题排查实录

我在这里整理一份避坑速查表，覆盖日常使用的高频问题：

6.4 一个典型批处理模板

如果你需要快速部署一台机器，把下面的批处理保存为install-service.bat，以管理员身份运行即可。注意替换路径和服务名：

code复制@echo off
set NSSM=D:\tools\nssm-2.24\win64\nssm.exe
set SERVICE_NAME=MyApp
set APP_DIR=D:\app
set APP_CMD=C:\Program Files\Java\jdk17\bin\java.exe
set APP_PARAMS=-jar myapp.jar
set LOG_DIR=D:\logs

if not exist "%LOG_DIR%" mkdir "%LOG_DIR%"

"%NSSM%" install %SERVICE_NAME% "%APP_CMD%" %APP_PARAMS%
"%NSSM%" set %SERVICE_NAME% AppDirectory "%APP_DIR%"
"%NSSM%" set %SERVICE_NAME% AppStdout "%LOG_DIR%\stdout.log"
"%NSSM%" set %SERVICE_NAME% AppStderr "%LOG_DIR%\stderr.log"
"%NSSM%" set %SERVICE_NAME% AppRestartDelay 5000
"%NSSM%" set %SERVICE_NAME% Start SERVICE_AUTO_START
"%NSSM%" start %SERVICE_NAME%
echo 服务已安装并启动。

这里把NSSM路径单独定义变量，方便你换机器时只需改一处。注意不要把%APP_PARAMS%放到引号内，否则参数会被当成一个整体。如果参数里本身含空格，就需要像APP_PARAMS="-jar myapp.jar --server.port=8080"这样，在set时整体赋值，intall时传%APP_PARAMS%也是整体传，没有空格问题。

6.5 另一个常见场景：注册Python脚本

Python脚本也经常用NSSM守护。如果你直接注册python.exe script.py，NSSM会同时拉起python解释器和脚本文件，但脚本里的相对路径仍然依赖工作目录。最好的做法是写一个bat：

code复制@echo off
cd /d D:\scripts
python D:\scripts\daemon.py

然后把bat注册为服务。这样即使脚本内部用了相对路径（比如读取同目录配置），也没问题。如果脚本有依赖环境变量或需要激活虚拟环境，在bat里加：

code复制call venv\Scripts\activate.bat

再执行python脚本。注意，服务的启动目录虽然是AppDirectory，但bat执行了cd /d后工作目录变了，所以一切以bat内部为准。

7. 我的一些额外心得与实际经验分享

7.1 不要迷信“开机自启动”，先确认进程是否真的需要

有的人喜欢把每个常驻程序都注册成服务，但服务是有代价的：它跟随系统启动，占用内存，还可能与其他服务产生兼容性。如果你的程序只是偶尔用一下，或者必须依赖用户登录会话（比如GUI应用），那么更适合用启动文件夹或计划任务。NSSM的精髓是“常驻后台、崩溃自恢复、无人值守”，最适合的是API服务、数据库、消息队列、定时任务、爬虫等。

7.2 日志目录的权限陷阱

我踩过最深的坑之一，是给服务设置了日志路径，但忘记创建目录。NSSM启动时会尝试打开该文件，如果父目录不存在，会报“系统找不到指定的路径”，然后服务启动失败。还有一次是日志目录在D盘，但D盘是一个加密盘或BitLocker自动锁定的卷，服务在开机时无法访问，导致启动失败。解决办法：把日志路径放在非加密的系统盘，或者让服务依赖某个解锁脚本，但复杂了，建议直接放非加密盘。

7.3 如何在服务里调用带GUI的小程序

NSSM注册GUI程序（比如一个小窗口）也是可以的，但服务默认运行在Session 0，用户看不到窗口。如果你非要让窗口显示在桌面，需要勾选“允许服务与桌面交互”，且在服务属性中设置“本地系统账户”，这样有时能弹到会话0，但新版本Windows（Vista之后）里这种方式基本不可见，界面程序还是老老实实用计划任务或随用户启动。NSSM适合后台服务型程序，GUI程序别硬塞。

7.4 NSSM 2.24 vs 3.0的选型判断

虽然官网推荐新用户使用3.0版，但我在生产环境中始终用2.24。原因是3.x作为预发布版，某些API行为和2.x有差异，网上解决方案大多是2.x时代的。如果你只是自己机器上用，3.x也问题不大，体验上多了一些环境变量导入、重启延迟更精确的功能。但如果有几十台服务器的批量部署，稳定压倒一切，用2.24。

7.5 最后一个小技巧：把NSSM和程序打包进同一个目录

如果你负责的运维环境经常重装系统，可以做一个“绿色部署包”：一个文件夹包含NSSM的exe、你的应用、一个install.bat、一个uninstall.bat。部署时只需要复制文件夹，执行install.bat。这个做法可以让你在几秒内完成一个新环境的服务注册，而且所有配置集中在脚本里，团队协作时非常方便。下面是我常用的uninstall.bat：

code复制@echo off
set NSSM=D:\tools\nssm-2.24\win64\nssm.exe
set SERVICE_NAME=MyApp
"%NSSM%" stop %SERVICE_NAME%
"%NSSM%" remove %SERVICE_NAME% confirm
echo 服务已删除。

在考虑注册服务时，我的习惯是先手动用命令行跑一次程序，确保它本身可以正常启动，再注册到NSSM。这样一来，就算后面出了问题，也能排除程序自身因素。NSSM本身很可靠，但程序自身的问题谁也救不了。

总的来说，NSSM是我在Windows上做服务管理最顺手的工具，没有之一。它把Windows服务的注册和管理变得像Linux的supervisor一样顺手，尤其是开机自启动这一块，只要配置正确，基本可以实现一劳永逸。希望这篇分享能帮你少走一些弯路，顺利把自己的程序跑成“永久服务”。如果你还有其他NSSM相关的坑，欢迎到评论区留言，我看到会尽量回复。