简介：NSSM 2.24 官方压缩包，面向需要将 Spring Boot 应用部署为 Windows 后台服务的开发者，集简捷配置、自动重启、日志管理于一体，可免去手工注册服务与守护进程的繁琐环节。包体紧凑，共 35 个文件、约 344KB，包含 2 个适用于 win32 与 win64 的 nssm.exe 主程序、13 个头文件与 12 个源码文件（覆盖服务管理、注册表、进程控制等模块），另有工程构建文件与说明文档，既可直接运行，也可按需查阅源码。已有 268 人学习下载，适合中小型项目与运维人员快速落地。解压后可获得独立可执行程序及完整开发工程，便于透明掌握服务注册、参数配置和日志输出逻辑；自带的自动恢复机制能有效保障应用持续在线，降低异常中断带来的运维成本，是打包 Spring Boot 服务化部署时的高效选择。
1. 提到 Windows 服务化，绕不开 nssm-2.24.zip 这个压缩包
提到 Windows 服务化，绝大多数运维的下载目录里都躺着一个 nssm-2.24.zip。它体积不大，却解决了 Windows 上一个老大难问题：普通 exe 不能直接注册成系统服务。凌晨三点业务脚本崩了，没有守护进程，早上一看数据缺失，只能手动拉起——这种事情碰上几次就会明白，程序能开机自启只是入门，崩溃后能自动恢复才是核心。NSSM（Non-Sucking Service Manager）把任意可执行程序包装成标准 Windows 服务，2.24 是社区里流传最广、踩坑沉淀最充分的版本。这篇文章不讲源码，只讲怎么把 nssm-2.24.zip 用明白：下载、注册、配置、排坑、验收。
2. 从 nssm-2.24.zip 到系统服务：安装与基础注册
2.1 解压与路径规划：先想清楚 nssm.exe 放在哪
拿到 nssm-2.24.zip，第一件事不是双击解压包里的 exe，而是先规划好它的落盘位置。nssm 是免安装软件，解压就能用，但 nssm.exe 的位置直接影响后续所有命令的可维护性。我建议固定放在 C:\Tools\nssm-2.24 这类路径下，原因有两个：一是路径里没有空格和中文，批处理脚本里拼接命令时少一层引号转义；二是团队里多台服务器部署时，统一路径能保证脚本行为一致。
解压后一般会看到多个子目录，包含 32 位和 64 位两个版本，按服务器系统位数选用。怎么确认系统位数？cmd 里输入 set PROCESSOR_ARCHITECTURE，返回 AMD64 就用 64 位版本。老系统上要注意位数匹配，不过 nssm 2.24 对老系统的兼容性本身就不错，这也是很多人留着这个压缩包不用新版的原因之一。
我习惯在部署脚本开头用变量统一引用路径：
:: 统一路径变量，后续命令都引用它，方便批量部署时改动 set NSSM_HOME=C:\Tools\nssm-2.24\win64 set NSSM=%NSSM_HOME%\nssm.exe这样后面所有 nssm 命令都写 %NSSM% 而不是完整路径。几十台机器部署时，只需要把脚本里这一行路径改掉，其他命令不用动。如果你只在一台机器上手动操作，双击 nssm.exe 打开 GUI 也完全可以，但 GUI 方式不适合批量复制配置，也不适合做变更审计，所以我后面所有步骤都采用命令行。
还有一个值得养成的习惯：把解压包里的 nssm.exe 版本记录下来。右键 exe 属性里的版本号，或者直接用 nssm 的相关命令查看运行信息，写到部署文档里。服务器上装了什么版本、什么时候更新过，比出问题时翻下载记录靠谱得多。
2.2 第一次注册服务：install 最小命令跑通流程
nssm install 支持两种模式：不带任何参数运行会弹出图形配置界面，适合临时验证；带服务名和程序路径运行，直接静默完成注册，适合脚本化部署。我强烈建议所有正式环境都走命令行注册，因为图形界面点出来的配置无法被版本管理，出了问题也没办法快速对比历史。
最小可用的注册命令是：
:: 注册服务：服务名 + 程序路径 + 传给程序的参数 %NSSM% install MyService "D:\app\server.exe" --port 8080 --config prod.ini :: 设置工作目录为程序安装目录 %NSSM% set MyService AppDirectory D:\app :: 启动服务 %NSSM% start MyService :: 确认服务已经进入运行状态 sc query MyService逻辑说明：install 的第一个参数是服务名，服务名是后续所有操作的唯一标识，一旦确定不要轻易修改。第二个参数是目标程序的绝对路径，无论路径里有没有空格，都建议加引号。从第三个参数开始，全部作为启动参数原样传递给目标程序，nssm 不解析、不修改。
参数说明：--port 和 --config 只是示例，实际传什么取决于你的程序支持哪些参数。注意这里的工作目录并不是通过参数配置的，而是通过下一节的 AppDirectory 单独设置。很多程序用相对路径读取配置文件，如果只注册不设工作目录，进程起来了但业务根本跑不起来的现象非常常见。
跑完这四条命令后，在 services.msc 里能看到 MyService 出现在服务列表。状态是"正在运行"还不能说明程序就绪，我后面会讲怎么验收。先记住一点：服务状态由 nssm 上报给服务控制管理器，nssm 把子进程拉起来就会上报运行中，子进程内部的初始化失败不会反映在服务状态里。这也是新手最容易误判的地方，部署完看到服务是 running 就走了，过一会儿回来发现进程已经退出。
2.3 基础参数三件套：工作目录、显示名与启动顺序
注册完服务后，有几个参数我建议立刻配上，否则后续容易出问题。它们分别是 AppDirectory（工作目录）、DisplayName（显示名）、Start（启动类型）、DependOnService（服务依赖）。命令行写法如下：
:: 设置服务工作目录为程序运行目录 %NSSM% set MyService AppDirectory D:\app :: 设置服务在控制面板中显示的中文名称 %NSSM% set MyService DisplayName "业务数据采集服务" :: 设置开机自动启动 %NSSM% set MyService Start SERVICE_AUTO_START :: 设置服务依赖 TCP/IP 服务先启动 %NSSM% set MyService DependOnService Tcpip逻辑说明：AppDirectory 是进程启动时的当前目录，程序里用相对路径读写文件时，实际基准就是它。比如程序要读 D:\app\config\app.ini，AppDirectory 应设成 D:\app，而不是 D:\app\config。DisplayName 只是显示别名，真正的服务名还是 MyService，注册表里对应关系的键还是服务名。
参数说明：Start 的常用取值有两个，SERVICE_AUTO_START 表示开机自启，SERVICE_DEMAND_START 表示手动启动。调试阶段用 DEMAND_START，业务验证通过后再改成 AUTO_START，可以避免程序有问题时开机就影响系统。DependOnService 可接一个或多个服务名，nssm 会把依赖关系写进服务注册表，服务管理器启动时先启动依赖项，再启动本服务，适合数据库、消息队列等前置组件场景。
还有一个参数在这个阶段就有必要提一下：AppEnvironmentExtra。它用于给服务进程追加额外的环境变量。部分程序通过环境变量传递配置，比如 DEPLOY_ENV=prod，在命令行里用 set 设置只能作用于当前 cmd 窗口，服务由服务管理器启动，读不到那些变量。用 AppEnvironmentExtra 就能做到：
:: 给服务进程注入自定义环境变量 %NSSM% set MyService AppEnvironmentExtra DEPLOY_ENV=prod :: 同时设置多个变量用分隔符隔开 %NSSM% set MyService AppEnvironmentExtra DEPLOY_ENV=prod LOG_LEVEL=info这个参数非常实用，特别是同一台机器上跑多个同名程序不同环境时，靠它区分环境能省很多事。
3. 服务化配置场景模板：脚本、Java、Python 怎么写才不翻车
3.1 Python 脚本服务化：pythonw.exe 与相对路径的坑
把 Python 脚本注册成 Windows 服务，是这些年 Windows 运维里最常见的需求之一。定时采集、文件夹监听、消息队列消费，本质上都是长期运行的 Python 进程。注册时的第一个决定是使用哪个解释器：python.exe 会在每次服务启动时弹出一个黑色控制台窗口，挂在桌面上非常显眼，也不专业。正确选择是 pythonw.exe，它是 Python 自带的"无控制台窗口"版本，适合后台进程。
:: 注册 Python 服务，解释器用 pythonw.exe，脚本路径写绝对路径 %NSSM% install PyWorker "C:\Python39\pythonw.exe" "D:\worker\main.py" :: 工作目录指向脚本所在目录 %NSSM% set PyWorker AppDirectory D:\worker :: 标准输出和错误分别记录到独立日志 %NSSM% set PyWorker AppStdout D:\worker\logs\worker.out.log %NSSM% set PyWorker AppStderr D:\worker\logs\worker.err.log :: 启动服务 %NSSM% start PyWorker逻辑说明：install 的第一个路径是 pythonw.exe 的完整路径，第二个路径是脚本路径。pythonw.exe 的路径可以用 where python 确认实际位置，不要想当然。main.py 的路径建议写绝对路径，因为即使设置了 AppDirectory，脚本内部如果通过 sys.path[0] 或者 os.getcwd() 找文件，取到的基准是 AppDirectory，而不是 main.py 所在的目录。
参数说明：AppStdout 和 AppStderr 是 nssm 里最常用的两个日志参数，作用是把进程的标准输出和标准错误重定向到文件。print() 的输出、traceback 堆栈都会落到对应的文件里。2.24 版本对这两个参数的支持很稳定，排查问题时日志是唯一可靠的信息源。日志文件所在目录需要提前手工创建，nssm 不会自动建目录，如果目录不存在，日志会静默丢弃。
这里还有一个 Python 特有的坑：标准输出默认有缓冲。在 python.exe 下，print 输出会先到缓冲区，缓冲区满或进程退出时才写入文件。而 pythonw.exe 的行为也不完全一样，部分情况下 stdout 被重定向到文件时，解释器的缓冲策略会掩盖实时日志。如果日志文件迟迟没有新内容，排错时先用 -u 方式运行脚本，强制不缓冲，日志就能实时落了。注册命令里可以把解释器参数补上：
:: 用 -u 参数禁用 Python 输出缓冲，日志实时写入 %NSSM% install PyWorker "C:\Python39\pythonw.exe" "-u" "D:\worker\main.py"3.2 Java 服务化：javaw.exe、JVM 参数与长启动时间
Java 服务注册成 Windows 服务的场景同样高频，特别是 Spring Boot 的 jar 包和 Netty 服务。Java 程序在 Windows 下有两个启动器：java.exe 会带有控制台窗口，javaw.exe 则没有。和 Python 同理，注册服务时用 javaw.exe。JVM 的参数和程序参数要通过 nssm 的机制逐段传递，处理起来比 Python 稍复杂。
先看一个 Spring Boot 的完整注册例子：
:: 注册 Java 服务，主程序用 javaw.exe，jar 包路径写绝对路径 %NSSM% install JavaApp "C:\Program Files\Java\jdk-17\bin\javaw.exe" "-jar" "D:\javaapp\app.jar" :: 工作目录设为 jar 包目录 %NSSM% set JavaApp AppDirectory D:\javaapp :: 追加 Spring 的 profile 与端口参数 %NSSM% set JavaApp AppParameters "--spring.profiles.active=prod --server.port=8081" :: OOM 等异常退出时自动重启 %NSSM% set JavaApp AppExit Restart :: 启动服务 %NSSM% start JavaApp逻辑说明：install 命令行里，javaw.exe 之后的所有参数会按顺序拼接成完整启动命令。比如上面这条实际执行等价于 javaw.exe -jar D:\javaapp\app.jar。Spring Boot 的额外参数如 --spring.profiles.active 写在 AppParameters 里，nssm 会把 AppParameters 的内容追加到程序路径之后。
参数说明：AppParameters 是 nssm 专门用来维护"程序参数"的属性。如果启动参数里包含空格或引号，注意外层引号的处理。JVM 参数比如 -Xmx512m 同样可以放在 AppParameters 里，但更常见的做法是把它写进 jar 包旁边的启动配置，或者通过环境变量 JAVA_TOOL_OPTIONS 传递，让 nssm 的配置保持简洁。
Java 服务的启动超时问题是重灾区。默认情况下服务控制管理器等服务启动完成的时间上限是 30 秒左右，很多 Spring Boot 应用在冷启动时需要加载 Bean、初始化数据库连接池、预热缓存，很容易超过上限。超过后服务管理器会杀掉进程并记录 1053 错误。这类问题的处理思路在第 4 章展开，这里先记住一个判断标准：如果事件日志里出现 1053，同时 Java 进程在任务管理器里短暂出现过，基本就是启动超时而不是注册问题。
3.3 批处理与通用程序：cmd /c 包装避开可执行文件限制
有些部署场景没有长期运行的进程，只有一段批处理脚本，希望它能开机自启并且崩了能自动拉起。批处理文件不是可执行文件，服务注册时直接指向 .bat 或 .cmd 文件会报错，需要先经过 cmd.exe 包装一层。注册模板如下：
:: 通过 cmd /c 调用批处理脚本 %NSSM% install BatchJob "%SystemRoot%\System32\cmd.exe" "/c" "D:\scripts\cleanup.bat" :: 工作目录指向脚本所在目录 %NSSM% set BatchJob AppDirectory D:\scripts :: 脚本退出码归零，等待 10 秒后重启 %NSSM% set BatchJob AppExit Restart %NSSM% set BatchJob AppRestartDelay 10000逻辑说明：cmd /c 的意义是启动一个 cmd 实例并执行指定命令，执行结束后 cmd 退出。nssm 看到的"进程"其实就是这个 cmd.exe，脚本的逻辑都在 cmd 内部完成。脚本里如果有相对路径，AppDirectory 配置到脚本目录即可。AppExit Restart 在这里要特别注意：批处理一次执行完会正常退出，如果配置了任何退出码都重启，批处理跑完反而会重复触发，形成重启风暴。所以设置前想清楚：你守护的是批处理执行过程本身，还是守护批处理背后的某个常驻进程。
参数说明：AppRestartDelay 单位是毫秒，设成 10000 表示退出后等待 10 秒再拉起。批处理服务我一般建议至少给一个延时，留出文件句柄和网络连接释放时间，避免脚本刚退出又启动时写入冲突。如果脚本本身执行频率高且耗时不长，不建议加自动重启，改为在脚本自身做循环或依赖任务计划程序更合理。
3.4 同一个程序多实例注册：套用模板前先改的两个参数
一台机器上同程序多实例跑，在很多项目里不可避免。比如采集程序要分别连测试库和生产库，或者按不同区域拆多个采集节点。nssm 允许同一可执行文件注册多个服务，每个服务独立配置进程参数和工作目录。只要程序支持参数区分实例，就能用一套模板复制多个服务。
:: 注册两个实例，服务名不同，参数不同 %NSSM% install Collector-Dev "D:\collector\collector.exe" --env dev %NSSM% set Collector-Dev AppDirectory D:\collector\dev %NSSM% install Collector-Prod "D:\collector\collector.exe" --env prod %NSSM% set Collector-Prod AppDirectory D:\collector\prod逻辑说明：多实例配置时最容易出问题的是日志路径和临时文件目录。若两个实例的工作目录指向同一路径，且程序按固定文件名写日志，两个进程会同时写同一个文件，内容互相交错。所以每个实例的工作目录、AppStdout、AppStderr 路径都必须独立，最好按实例名建子目录。
参数说明：进程名相同导致 tasklist 里看不出区别，排查时需要用其他方式查看进程命令行来区分实例。服务名和 DisplayName 也要区分，否则服务管理器列表里一堆同名服务根本分不清谁是谁。
提示：多实例场景下，配置模板复用时一定先改 AppDirectory、日志路径这两个参数，再启动服务。
4. 服务自启动与异常退出：nssm 的守护机制怎么调才不崩
4.1 退出代码与重启策略：AppExit 与 AppRestartDelay 组合
注册服务只是第一步，真正体现 nssm 价值的是它对进程退出行为的接管能力。nssm 把"进程退出后服务做什么"交给 AppExit 参数控制。2.24 版本支持的动作主要有 Restart（重新拉起）、Reset（重置状态计数）、Exit（正常退出服务）、Ignore（忽略退出、服务保持运行）。默认情况下，进程退出会被视为服务停止，不会自动拉起。
:: 针对所有退出码重启服务 %NSSM% set MyService AppExit Restart :: 仅针对指定的退出码重启（如 Java 的 1、2、3） %NSSM% set MyService AppExit Restart 1,2,3 :: 失败退出后等待 5 秒再重新拉起 %NSSM% set MyService AppRestartDelay 5000逻辑说明：第一行写法适用于脚本类程序，只要进程退出就自动拉起，实现最简单的守护效果。第二行写法更精密，只对特定的退出码做处理，适合程序自身对退出码有明确约定的场景。如果程序退出码不固定、也分不清哪些代表错误，建议统一用 Restart，但要在业务侧做好幂等，防止重复执行造成重复处理。
参数说明：AppRestartDelay 默认值很短，进程退出后立刻拉起，源端口可能因为 TIME_WAIT 状态暂时不可用，新进程绑定端口失败就会再次退出，陷入重启循环。调整到 3000 到 10000 毫秒通常能缓解。这个参数的实际意义是给系统时间完成进程清理、句柄释放、端口回收，不要保持默认值或设为 0。
重启策略也不是越激进越好。程序因为配置错误启动即退出时，自动重启只会让错误日志刷得飞快，排查时反而看不清原始原因。我的习惯是：首次部署先把 AppExit 关掉，手工启动、观察稳定运行，确认没问题后再打开自动重启。如果上了自动重启后出现快速循环，先看 AppStderr 里的报错，而不是调大延时。
有一个概念值得区分：nssm 管理的"服务"与"子进程"。nssm 本身是一个独立进程，它作为服务宿主注册到服务管理器；目标程序是 nssm 的子进程。服务停止时，nssm 会按配置的停止方式先通知子进程退出，子进程退干净后 nssm 才完成自己的退出。这就是为什么有时 nssm stop 会卡住：子进程不响应停止信号，nssm 在等待超时。
4.2 启动与停止超时：1053 错误与 AppStopMethodSkip 调整
1053 是 Windows 服务排错时的常见错误码，含义是服务没有在服务管理器允许的时间内完成启动或状态上报。nssm 拉起子进程后会立即向服务管理器报告服务已启动，所以 nssm 本身很少触发 1053，多数 1053 其实来自子进程起点后长时间不对外提供服务，服务管理器因此中断服务。不过，nssm 在个别情况下（子进程创建失败、系统负载异常等）也会自身启动超时。排查时先分清楚是 nssm 超时还是子进程初始化慢。
系统层面对启动超时的限制可以通过注册表调整：
:: 查询当前系统服务超时时间 reg query HKLM\SYSTEM\CurrentControlSet\Control /v ServicesPipeTimeout :: 将超时时间覆盖为 120 秒 reg add HKLM\SYSTEM\CurrentControlSet\Control /v ServicesPipeTimeout /t REG_DWORD /d 120000 /f逻辑说明：ServicesPipeTimeout 是服务控制管理器等待服务启动的最长时间，单位是毫秒。不同系统默认值有差异，很多是 60000。改成 120000 后，启动较慢的服务也能获得充足时间。注意这是全局注册表项，影响本机所有服务，改动后需要重启系统才生效，生产环境修改前要评估对既有服务的影响。
注意：ServicesPipeTimeout 是全局参数，不要为了单个服务随意调大，优先在程序层缩短启动耗时。
停止超时是另一个高频问题。nssm 停止服务时有一整套关闭流程：依次尝试向子进程发送关闭信号、关闭主窗口、结束进程树、最后强制结束。每个环节都有等待时间，加起来可能十几秒。如果服务的停止操作总是转圈很久，可以用 AppStopMethodSkip 简化关闭流程：
:: 跳过部分停止方式，加速服务停止 %NSSM% set MyService AppStopMethodSkip 6这个值 6 表示组合跳过某种关闭方式，具体含义是跳过向子进程发送关闭事件和关闭窗口两个步骤，直接推进后续流程。它对无界面、无需优雅退出的后台程序很有效，但需要程序自身能在强制结束后恢复一致状态。如果程序有数据库事务或本地队列要处理，不建议跳过太多步骤，一旦数据写到一半被强杀，恢复起来更麻烦。
启动超时和停止超时是同一个硬币的两面：配置 AppStopMethodSkip 前先看程序的优雅退出实现，程序自己实现了 shutdown hook，就不要跳过前两步；程序只是简单的脚本，跳过完全没关系。
4.3 运行账户与权限：LocalSystem 与自定义账户的取舍
nssm 支持指定服务运行账户。默认情况下注册的服务以 LocalSystem 账户运行，这对多数本地读写场景已经够用，但在访问网络共享、需要跨机器认证的场景中，LocalSystem 可能触发权限不足。此时需要一个专门的账户来运行服务，nssm 通过 ObjectName 参数设置：
:: 设置服务使用专用账户运行，参数格式为 域名\用户名 密码 %NSSM% set MyService ObjectName "DOMAIN\svc_collector" "your-password-here" :: 账户信息存到服务配置后，立即启动服务 %NSSM% start MyService逻辑说明：ObjectName 的两个参数分别是账户名和密码。nssm 会把凭据写入服务配置，启动时由服务管理器用该账户创建进程。使用域账户时，账户名建议用 域名\用户名 格式。本地账户直接用 .\用户名 或机器名\用户名。密码如果包含特殊字符要留意引号转义。
参数说明：密码在命令行里明文出现，命令历史会留记录。生产环境建议先在 GUI 里完成一次配置，密码保存在注册表服务项里，命令行只用于后续修改和查看。密码轮换后需要重新执行一次 ObjectName 设置，否则服务可能报 1069（无法登录）错误。
账户权限误区我见过不少：觉得 LocalSystem 权限大就万事大吉，但恰恰是权限大，访问网络共享时它默认使用机器账户的凭据，而共享目录往往没有给机器账户授权。换成域账户运行后指向共享目录的路径就能正常工作。反过来，过度追求"最小权限"的团队把服务账户权限删得太狠，服务启动时报拒绝访问错误。我的建议是：先用 LocalSystem 验证业务功能，确有必要再换专用账户，换完账户后的第一件事是重启服务并查看业务日志，确认运行身份变更后没有带来新的权限缺口。
5. 常见问题排查：服务起不来、启动后立即退出、日志没有输出
5.1 服务启动失败：事件查看器报 1053 或 7000
现象：nssm start MyService 执行后，服务状态卡在"正在启动"，随后回到"已停止"，事件查看器里对应的错误码是 1053 或 7000。
原因：1053 表示服务响应超时。可能是子进程启动阶段有网络请求或资源初始化，总耗时超过系统规定的服务超时阈值；也可能是子进程崩溃但 nssm 没有正确感知。7000 是另一类错误，通常与服务依赖缺失、服务镜像路径错误或登录账户密码失效有关，nssm 注册的服务碰到 7000，先检查账户相关配置。
解决：按顺序排查。先确认服务启动类型是否正常，用 nssm get MyService Start 查看；再确认账户配置是否正确，直接在 services.msc 的属性里重新输入一次账户密码；最后才考虑系统超时问题，用上一章的 reg add 命令调大 ServicesPipeTimeout 并重启系统。如果事件查看器里 1053 和程序相关错误同时出现，优先解决程序自身的启动错误，否则调大超时只是掩耳盗铃。
5.2 服务状态正常但进程退出：RUNNING 的假象
现象：sc query MyService 显示 RUNNING，服务图标也是绿色，但任务管理器里找不到目标进程，业务数据也不再更新。
原因：nssm 上报 RUNNING 的时刻是子进程被成功创建并保持运行的瞬间。如果子进程启动后因配置错误、依赖缺失或端口冲突立刻退出，nssm 在没有配置 AppExit 策略的情况下不会自动拉起，服务状态短暂停留在 RUNNING，过一会儿服务管理器的轮询发现进程不存在，才转为已停止。
解决：不要只信服务状态，要学会看进程列表。注册服务时配置 AppExit Restart 是最直接的兜底，至少能让失败的进程被拉起而不是无声消失。定位根因时，先在命令行手工以相同账户运行一次程序，看控制台输出的报错；再看 AppStderr 指向的错误日志，里面有异常堆栈。日志里常见的根因包括：工作目录设置错误导致相对路径文件找不到、端口被占用、数据库连接串错误或凭证过期。
5.3 日志文件不产生内容：目录、缓冲与重定向层级
现象：程序有输出，AppStdout 和 AppStderr 也都配置了，但日志文件不存在或内容为零，业务日志也没有新写入。
原因：nssm 不会自动创建日志父目录。如果目录不存在，nssm 对日志文件的写操作会静默失败。另一个原因是程序自己重定向了 stdout，比如 Python 的 logging 模块配置了 FileHandler，程序自身的日志已经写到别处，nssm 的日志文件自然为空。可以用文件开关顺序来判断。
解决：先手工创建日志目录，把 AppStdout 和 AppStderr 指向明确的绝对路径，重启服务后确认文件生成。如果还是没有内容，用进程管理器查看目标进程是否真的启动，以及它的父进程是 nssm 还是其他工具。遇到 Python 这类解释器式程序，先确认解释器参数里是否传递了 -u 或是否设置了 PYTHONUNBUFFERED=1，因为缓冲会导致日志延迟写入，误以为没有输出。
5.4 日志文件无限增长：轮转参数与磁盘占满
现象：服务运行几个月后，AppStdout 指向的日志文件体积达到几个 GB，磁盘空间被逐渐耗尽，服务开始因为写日志失败而报错。
原因：nssm 的日志重定向默认不切割文件，程序输出多少就写多少。如果程序本身没有日志切割机制，长时间运行后单文件必然膨胀。这个问题在采集类、心跳类服务上尤其明显，这类程序有大量周期性输出。
解决：nssm 2.24 提供了日志轮转参数。用 AppRotateFiles 开启按大小轮转，再配 AppRotateBytes 控制阈值：
:: 开启日志轮转，超过 16MB 自动切换新文件 %NSSM% set MyService AppRotateFiles 1 %NSSM% set MyService AppRotateBytes 16777216 :: 重启服务让轮转配置生效 %NSSM% restart MyService参数说明：AppRotateBytes 单位是字节，16777216 即 16MB。轮转产生的历史文件会按时间戳或序号保留在相同目录，避免单文件无限增长。如果程序自身已经实现了按天切割的日志逻辑，就不需要再开 nssm 的轮转，两个切割机制叠加可能产生双份文件，反而增加排查成本。
5.5 卸载后残留服务与注册表键：remove 的完整清理
现象：执行 nssm remove MyService 提示成功，但服务列表里找不到该服务时用 sc query MyService 还能看到记录，重新安装时又报服务重名。
原因：nssm remove 默认会删除服务注册表项，但服务进程句柄被占用、服务处于停止中状态时，删除操作可能没有完全生效。另外，如果曾经手动 sc create 过同名服务，后续被 nssm 接管，注册表里可能残留互相矛盾的键。
解决：先确认残留服务状态，用 sc query MyService 查看；再执行 sc delete MyService 清理注册表项；如果返回"服务已标记为删除"但仍在列表，重启系统后再删除一次。删除前必须确认该服务没有承载任何在线业务。清理干净后重新 nssm install 即可。如果团队部署脚本化，建议在脚本开头做幂等处理：查询服务是否存在，存在则先 stop 再 remove，最后才是 install。
6. 用 nssm edit 快速变更参数与手工验收的检查清单
服务上线后，日常维护不是靠重装完成的。nssm edit MyService 可以打开图形界面直接修改所有参数，包括程序路径、工作目录、日志位置、退出策略和账户信息。它是我在生产环境改参数时的首选，因为界面把所有配置项都摊开在眼前，改错的风险比一条条命令行 set 低很多。命令行做批量修改则适合脚本化场景。
:: 打开图形编辑界面查看或修改服务配置 %NSSM% edit MyService :: 查看指定参数的当前值 %NSSM% get MyService AppDirectory %NSSM% get MyService AppExit :: 重启服务让配置生效 %NSSM% restart MyService配置变更后要对服务做一次完整验收，而不是只看服务的运行状态。我自己的验收流程分三步。第一步验证重启能力：执行 nssm restart MyService，确认停止过程不卡顿、启动过程不报 1053，服务状态在 30 秒内恢复 RUNNING。第二步验证守护能力：用 taskkill /f /pid 杀掉目标进程，观察 nssm 按 AppExit 策略将其拉起的全过程。如果目标进程没有按预期恢复，回查 AppExit 配置是否生效。第三步验证日志链路：修改一次业务数据或触发一次日志输出，确认 stdout、stderr 都落到了预期文件，并且文件不是零字节。
实际维护中还常见一个需求：服务跑了很久，某个参数记不清当时怎么配的。此时用 nssm get 依次导出各关键参数，和部署脚本对比，能快速定位漂移。多台服务器批量更新服务参数时，我一般先在一台上用 nssm edit 验证新参数，再把等价命令写入脚本，按批次滚动执行，而不是一次性推完。服务停止时间窗口要避开业务高峰，特别是采集和消息类服务。
最后聊一下版本。nssm 2.24 是我在项目里用的主要版本，它久经考验，社区案例多，遇到问题能搜到大量讨论。升级新构建前，先在测试服务器上重点验证停止流程和日志轮转行为是否一致。几年前我曾经在一台旧机器上换过更新构建，替换后服务的停止时间明显拉长，回退到 nssm-2.24.zip 里的版本立刻恢复正常。从此养成习惯：任何 nssm 相关变更，都先在测试机跑一遍完整的重启、杀进程、日志轮转流程，确认通过后再上生产。这样即使在多台机器上滚动部署，也不会因为工具自身行为差异翻车。
把 nssm 2.24 这套用法吃透，Windows 服务化这件事基本不会有太大的坑。希望这篇实战笔记能帮到你，祝一次性部署成功。
本文还有配套的精品资源，点击获取
