Windows服务器上Spring Boot JAR包部署与端口转发完整指南-代码聚汇网

Windows服务器上Spring Boot JAR包部署与端口转发完整指南

姬轩亦·2026-08-29·阅读 23 GEO检测（免费）

Java项目部署Windows服务器Spring Boot

|难度：普通|阅读约 40 分钟

1. 部署前的整体思路与链路设计

1.1 为什么我们平时总谈Linux，这次却要在Windows上部署

Java项目的部署教程，十篇里有九篇都是讲Linux服务器的操作，什么CentOS、Ubuntu、宝塔面板，命令一行一行的敲。但真到了实际业务场景里，Windows服务器比很多人想象中要常见得多。中小企业里大量服务器就是Windows Server，原因也很朴素：公司内部本来就有AD域控、文件共享、财务系统这些Windows生态的东西，运维人员习惯用远程桌面，客户那边也明确要求“装到我们自己的Windows机器上”。你总不能跟客户说“你换台Linux服务器吧”，不现实。

Windows上跑JAR包这件事，本身没有任何技术障碍。Java是跨平台的语言，JAR包在哪个操作系统上运行都一样，区别只在于环境怎么配、服务怎么拉起来、端口怎么放行。所以你要是把JDK装好、把端口弄通，Windows上的稳定性完全够用。我印象很深的一次，给一个做工业设备的客户部署MES系统，他们的服务器就是一台用了五六年的Windows Server 2016，机器性能不怎么样，但JAR包丢上去，照样跑得很稳。

1.2 完整部署链路：从开发机到外网访问

整个部署链路，我习惯把它拆成四段：环境准备、项目打包、服务运行、外网打通。每一段都有明确的任务边界，排查问题的时候也方便定位。

第一段是环境准备，也就是在Windows服务器上装JDK并配好JAVA_HOME、PATH这些环境变量。这一步没做好，后面JAR包永远起不来，第一个报错就是“不是内部或外部命令”。
第二段是项目打包，在本地开发机上用Maven把Spring Boot项目打成可执行JAR包。这里有个关键点，很多人喜欢直接在服务器上放源码再打包，我不太建议，至少在Windows上没必要。本地把包打好，一个JAR文件传上去，干净利落。
第三段是服务运行，把JAR包在服务器上拉起来，先确保本机访问没问题，再做后台运行和开机自启。这里要处理的事情比较多，端口号、内存参数、日志输出，每一项都值得说几句。
第四段是外网打通，要分两种情况：服务器在公网云上，只需要在云控制台的安全组放行端口；服务器在公司内网，则需要Windows防火墙放行、路由器做端口转发，可能还需要DDNS解决动态IP的问题。

这四段是一环扣一环的，前面任何一环出问题，后面都走不通。这也是为什么我不建议直接按照网上的碎片教程跳着做——你只配了防火墙端口，却不知道端口转发没做，外网照样访问不了，排查起来就会特别被动。

1.3 为什么选JAR包这种部署方式

部署Java项目，方式其实不止一种。传统的有打WAR包丢进Tomcat，新一点的有JAR包直接跑，再往上还有Docker容器化。在Windows服务器这个场景下，JAR包几乎是性价比最高的选择。

WAR包需要额外装Tomcat容器，Tomcat版本跟JDK版本还有兼容性问题，维护成本高。Docker虽然方便，但Windows服务器上开Docker Desktop或者Docker服务，对机器配置有要求，很多旧服务器根本跑不动，而且有些企业网络环境对容器技术有限制。JAR包部署的好处就非常明显：一个可执行文件，依赖的Tomcat已经内嵌在Spring Boot的JAR里了，机器上只要有一个能用的JDK就能跑，不管是换机器、备份、还是迁移，拷一个文件就搞定。

所以这篇文章的默认前提就是：你有一个Spring Boot项目，通过Maven能打成可执行JAR包，现在要部署到一台Windows服务器上并对外开放访问。

需要模型API调用？免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。

2. 环境准备：JDK安装与配置

2.1 JDK选型：8还是17，这个决定不能拍脑袋

JDK版本的选择，我建议先看项目在哪个版本上编译的，生产环境就跟它保持一致。目前市面上Spring Boot项目用得最多的还是JDK 8，很多老项目甚至是从JDK 1.8一路跑过来的，虽然年纪大了，但胜在稳定，各种中间件兼容性最好。如果你是新项目，用Spring Boot 3.x，那底子上就要求JDK 17起步，这没有商量余地。

需要注意的是，服务器上的JDK版本和本地开发版本不一致的问题很常见。本地用17开发，生产机器装的是8，JAR包打出来用的是高版本类文件格式，低版本JVM根本认不了，启动直接报UnsupportedClassVersionError。我见过太多人在这个问题上卡住，排查半天，最后看版本才发现自己装错了JDK。所以装之前，先确认清楚项目用的Java版本，比如可以在pom.xml里看maven.compiler.release或者properties里配的java.version。

JDK版本	配套Spring Boot版本	适用场景	建议
JDK 8	Spring Boot 2.x	存量老项目、依赖较多Legacy环境	只要能跑，就别轻易升
JDK 11	Spring Boot 2.x	部分用上模块化新特性的项目	兼容性略尴尬，用得不多
JDK 17	Spring Boot 3.x	新项目、技术栈较新、追求长期支持	新项目首选，支持周期长

另外强烈建议用官方JDK发行版。网上很多第三方编译的JDK也能用，但服务器环境要的是省心，官方版本有完整的补丁更新和兼容性保证，别在这种关键环节省事。

2.2 JDK安装与环境变量配置步骤

JDK安装本身没什么技术含量，一直点下一步就行，但有几个细节值得注意。

第一，安装路径不要带空格和中文。有些版本JDK默认装在Program Files目录下，路径里有空格，虽然现代Java工具链大部分能处理，但有些老脚本、老配置就敏感。另外中文路径在Windows上容易出现编码问题，启动时报错也会很诡异。我自己习惯统一装到D:\Java\jdk-17这种纯英文路径下，省心。

第二，装完之后，系统环境变量需要配两个关键项：

txt复制JAVA_HOME = D:\Java\jdk-17
Path      = %JAVA_HOME%\bin

具体操作是右键“此电脑”->“属性”->“高级系统设置”->“环境变量”。在系统变量里新建JAVA_HOME，值填JDK的实际安装路径。然后找到Path变量，点编辑，新建一行，输入%JAVA_HOME%\bin，确定保存。

配环境变量的目的是什么，简单解释一下：JDK安装包在装完后其实不会自动把java命令加进全局PATH里，而我们在命令行下敲java、javac，Windows是去PATH变量里记录的目录逐个找的。如果不配置，你打开cmd敲java就说找不到命令，但你跑到JDK安装目录下的bin里再敲，又是好的。这就是原因。

2.3 验证JDK是否就绪

配完环境变量，不要急着部署，先开一个新的cmd窗口验证。为什么要新开？因为环境变量的修改只会对之后启动的进程生效，你如果用的还是之前已经开着的窗口，拿到的还是旧PATH，会怀疑自己配错了。验证命令：

bash复制java -version
javac -version
echo %JAVA_HOME%

三条命令都能正常输出，且版本号是预期值，JDK这块就算过关了。java -version能输出版本，javac -version也能输出版本，说明JRE和编译器都可用；echo %JAVA_HOME%打印的路径和自己配置的路径一致，说明环境变量读取正常。

我每次部署时习惯把这三条命令的输出截图留档，一方面是为了确认，另一方面万一后面出问题，回头翻一下能确认JDK不是什么变量。这个习惯虽然小，排查问题的时候却挺管用。

3. Maven构建打包：把项目变成可部署的JAR包

3.1 为什么本地先打JAR包而不是服务器上编译

有些同学习惯把整个项目源码打包传到服务器上，再在服务器装Maven、拉依赖、编译打包。对于Windows服务器场景，我是明确不建议这么做的。原因有三个。

第一，服务器环境越干净越好。服务器上只装必要的组件，JDK那是有用的，但Maven这种构建工具放在开发机上才是正路。多装一个工具，就多一个版本升级、配置错误、环境变量冲突的隐患。

第二，拉取Maven依赖很耗时。一个中型Spring Boot项目，首次打包要下载上百兆的依赖，在开发机上可能还好，放到服务器上要是网络不好，打包二十分钟都是常事。

第三，本地打好的JAR包经过验证，是一个确定可执行、可回滚的产物。服务器上编译还需要装一堆构建依赖，容易引入不确定性。

所以标准流程是：开发机上编译打包，产出一个JAR包，传到服务器上，一个文件解决问题。

3.2 Maven安装配置与环境准备

如果你本地还没装Maven，需要先装一下。Maven是Java写的工具，所以前提是你本地有JDK。Maven安装包去Apache官网下载二进制zip包，解压到纯英文目录，然后配置环境变量。

txt复制MAVEN_HOME = D:\apache-maven-3.9.6
Path       = %MAVEN_HOME%\bin

配好后，在本地开个新cmd窗口，输入mvn -v，能输出版本信息就说明Maven装好了。

Maven还有一个绕不开的配置是settings.xml，主要改两个地方：本地仓库路径和镜像源。

xml复制<settings>
  <localRepository>D:/maven-repo</localRepository>
  <mirrors>
    <mirror>
      <id>aliyun</id>
      <url>https://maven.aliyun.com/repository/public</url>
      <mirrorOf>central</mirrorOf>
    </mirror>
  </mirrors>
</settings>

本地仓库路径默认在用户目录的.m2/repository下，如果你C盘空间紧张，建议改到其他盘。镜像源这个事，国内开发环境基本都会配阿里云的Maven镜像，否则从中央仓库拉依赖那个速度，真的能让人等到怀疑人生。

3.3 打包前必须检查的项目配置

在敲打包命令之前，有几个配置一定要检查一遍，这些都是在实际部署中踩过坑总结出来的。

端口号：Spring Boot默认端口是8080，生产环境基本要换掉。在application.yml或application.properties里确认server.port设成了什么，后面所有放行端口、访问地址都跟这个数字有关。
数据库连接：如果你的项目用了MySQL、Redis这些外部中间件，确认地址写的是服务器能访问到的IP和端口。很多项目本地跑得好好的，传到服务器上起不来了，结果发现数据库连的还是localhost，而数据库本身没在服务器上。
配置文件区分：如果你的项目分了application-dev.yml、application-prod.yml这种多环境配置，打包前要确认激活了哪个环境。Spring Boot默认读application.yml，但dev和prod配置不一样，部署的时候千万不要让默认配置生效。

其中有个细节要特别提醒一下：如果你的配置文件里写死了数据库密码、密钥这些敏感信息，打出来的JAR包是包含这些内容的。如果你要把JAR包交付给第三方或者上传到公开渠道，记得用Jasypt或者环境变量占位符处理一下敏感信息。

3.4 执行打包命令与产物自检

项目配置检查完，就可以执行打包了。在项目根目录下打开命令行，执行：

bash复制mvn clean package -Dmaven.test.skip=true

参数说明几个关键点：

clean：先清掉上次构建的target目录，避免旧的class文件残留导致打包结果不干净。
package：执行打包流程，编译、测试、打包都在这个生命周期里。
-Dmaven.test.skip=true：跳过单元测试。本地开发时建议正常跑测试，但部署打包时跳过，防止因为测试环境网络不通或者测试用例数据异常导致打包失败卡住。

打包完成后，JAR包在项目的target目录下，一般是两种名字：如果你的pom.xml里finalName有配置，就用配置的名字；否则就是artifactId-version.jar。Spring Boot项目打出来的包，如果pom里引了spring-boot-maven-plugin，生成的JAR是可执行的；如果你不小心只用了默认的打包插件，那打出来的JAR只是一个普通jar，运行会报“没有主清单属性”。怎么区分？直接看target目录下有没有两个jar，一个是.jar一个是.jar.original，有的话说明Spring Boot插件生效，用不带.original的那个。

拿到JAR包后，在本地可以先跑一把做自检：

bash复制java -jar your-project.jar

看到Spring Boot的启动日志，并且最后出现类似Tomcat started on port(s): 8080的字样，说明这个包没问题，可以往服务器上搬了。

4. 上传JAR包并运行

4.1 把JAR包传到Windows服务器上

上传方式看服务器跟你本机的网络情况，常用的有三种。

一是远程桌面复制粘贴。Windows服务器最常用的远程登录方式，本地RDP连上服务器后，直接把JAR包从本地磁盘拖到服务器桌面或者某个目录下，操作最简单。不过，大文件传起来偶尔会中断，而且RDP剪贴板传输大文件速度很慢。

二是外网传输，如果服务器可以访问外网，直接把JAR包传到自己的对象存储、网盘、或者用python3 -m http.server起个临时下载服务，在服务器上用浏览器下载。这个方法适合大文件快速上传，但要注意临时服务用完就关。

三是用FTP/SFTP工具，比如FileZilla、WinSCP。如果服务器开了FTP服务，用这个方式传文件最稳定，支持断点续传，还能看到传输进度。

不管用什么方式，建议把JAR包放到一个专门的项目目录，比如D:\app\，不要放在桌面或者下载目录。桌面的文件容易在清理时被误删，下载目录又经常和其他文件混在一起，找起来费劲。

4.2 前台启动与功能自测

JAR包放到服务器上之后，记住一个原则：先以前台方式跑起来，确认没问题，再考虑后台运行。

为什么？因为前台启动时日志直接打印在屏幕上，启动到底卡在哪一步、报了什么错，一眼就能看到。我第一次部署的时候图省事直接搞了后台启动，结果8080端口起不来，日志又没定向到文件，排查起来完全是瞎猜。

在服务器上开一个cmd窗口，切到D:\app目录：

bash复制cd D:\app
java -jar your-project.jar

看到启动日志里出现Started YourApplication in X.XX seconds，说明服务启动成功。这时候先在服务器本机上验证一下接口能否访问。如果你项目里有health检查接口，打开浏览器访问http://localhost:8080/health，能看到正常的响应。如果没有专门的健康检查接口，访问一下登录页面或者已知的API路径也行。

本机验证通过了，下一步在局域网内用另一台电脑测试，访问http://服务器IP:8080/。能通，说明服务本身在局域网内没问题。到这里，就可以开始处理后台运行和开机自启的事了。

4.3 后台运行：不关窗口服务不能停

直接java -jar启动，最大的问题就是窗口一关，服务就没了。部署到服务器上的服务是要长期跑的，总不能远程桌面一直留着那个窗口。所以必须做后台运行。

Windows下做后台运行的方案主要有三种，我分别说一下，按我的推荐程度排个序。

使用WinSW（Windows Service Wrapper）：把JAR包包装成Windows服务，注册后可以设置开机自启、异常自动重启，还能像管理其他Windows服务一样用服务管理器控制。这是我认为最规范的方案。
使用NSSM（Non-Sucking Service Manager）：同样是注册成服务，配置简单，很老牌，稳定性也不错。和WinSW二选一即可。
使用批处理脚本配合任务计划程序：写一个start.bat，用start命令启动，再用任务计划把启动时机设在开机时。这个方法最轻量，不需要额外下载工具，但服务异常崩溃后不会自动拉起，不适合正式环境。

这里重点讲一下WinSW的用法，因为实际项目里用这个最省心。去GitHub下载WinSW-x64.exe，和jar包放在同一个目录下，把exe重命名成你的服务名，例如MyAppService.exe。然后创建一个同名xml配置文件MyAppService.xml：

xml复制<service>
  <id>MyAppService</id>
  <name>MyAppService</name>
  <description>Spring Boot Application Service</description>
  <executable>java</executable>
  <arguments>-Xms256m -Xmx512m -jar D:\app\your-project.jar</arguments>
  <logmode>roll</logmode>
  <onfailure action="restart" delay="10 sec"/>
</service>

然后以管理员身份打开cmd，执行注册服务的命令：

bash复制MyAppService.exe install

安装成功后，在Windows服务管理器里找到MyAppService，启动它。到这一步，服务就变成了由Windows系统托管，即使你注销了远程桌面也不会停掉，服务器重启后服务会自动跟着启动。

4.4 内存参数与日志管理

JVM参数这一块，很多人直接忽略，java -jar一把梭，但其实值得花几秒钟配置。Spring Boot应用默认堆内存是物理内存的四分之一，对于一台8G内存的服务器，JVM会觉得4G都是它的，而你的应用可能只需要512M，剩下的不用就浪费了，还容易引发内存换页。更麻烦的是多个Java应用同时跑时，内存分配不均，一个吃满了，另一个直接起不来。

所以建议根据服务器实际内存和业务规模设置堆大小。一般小中型应用，初始堆和最大堆都设成一样，避免运行过程中动态扩缩容带来的性能抖动。比如：

bash复制java -Xms512m -Xmx512m -jar your-project.jar

如果服务器内存充足，业务又比较吃内存，可以考虑1024m甚至更大。但记住，机器物理内存要留一部分给操作系统，不要全部塞给JVM。

日志管理也要提一下。Spring Boot默认把日志打印到控制台，服务化之后，如果不重定向，窗口关了日志就没了，出了问题什么也查不到。用WinSW时我上面配置了logmode=roll，它会自动把stdout和stderr记录到日志文件，按日期滚动。如果是手写批处理，可以这样重定向：

bash复制java -jar your-project.jar >> D:\app\logs\app.log 2>&1

强烈建议在服务器上把日志留到固定目录，并且定期清理。跑了半年的老项目，日志文件好几个G是很常见的事，别把C盘空间吃没了才想起来看。

5. 外网访问配置：从内网到公网

5.1 先确认内网访问正常再谈外网

外网访问配置的前提，一定是内网访问已经通了。什么意思？就是服务在本机访问正常，在局域网内用另一台电脑也访问正常。如果这两步没做到，就不要往后看，先把前面的问题解决掉。

内网访问正常之后，外网打通的路径就很明确了：要让互联网上的用户能访问到你这台服务器上的8080端口，需要穿过两道“墙”：第一道是Windows自带的防火墙，第二道是网络出口的路由器或云平台的安全组。两道墙都得放行，任何一个地方拦住了，外网都访问不了。

5.2 Windows防火墙放行端口

Windows服务器的防火墙默认是开启的，它会对进来的流量做过滤。你从外网访问服务器的8080端口，防火墙默认是不放行的，所以必须在防火墙里加一条入站规则。

操作路径：控制面板->Windows Defender防火墙->高级设置->入站规则->新建规则。

创建规则的时候选“端口”，协议选TCP，端口填你项目的实际端口，比如8080。动作选“允许连接”，配置文件三个选项都勾上就行。规则创建好之后，给它起个明确的名字，比如Allow SpringBoot 8080，方便以后管理。

这里有一个很常见的坑：防火墙规则“允许连接”有时候需要同时勾选“公用”和“域”配置文件才生效。很多服务器同时加入了域环境，防火墙按配置文件类型区分规则，你只勾了域，但网络被识别成公用，规则就不生效。

校验规则是否生效，可以在另一台电脑上用telnet或者PowerShell命令测试：

powershell复制Test-NetConnection 服务器IP -Port 8080

返回TcpTestSucceeded: True，说明端口已通；False，说明还没放行，继续排查。

5.3 路由器端口转发与云安全组

接下来这步取决于服务器部署在哪里。

如果服务器是云服务器，比如阿里云、腾讯云、AWS，除了操作系统里的防火墙，云平台还有一个“安全组”的概念。安全组相当于云环境里的一道独立防火墙，优先级还挺高，即使你Windows防火墙放行了，安全组没放行端口，照样进不来。到云控制台找到这台ECS实例，在安全组规则里添加入方向规则，放行TCP 8080端口，来源IP按需填0.0.0.0/0代表所有人都可以访问，出于安全考虑可以填固定IP，如果只是自己用，没必要对全网开放。

如果服务器跑在公司内网或者家庭宽带，那就是要做路由器端口转发。登录路由器管理页面（一般是192.168.1.1或192.168.0.1），找到“端口映射”或“虚拟服务器”功能，添加一条规则：外部端口8080映射到服务器的内网IP的8080端口。这样外网访问路由器公网IP:8080时，数据包才会被转发到指定的内网服务器上。

路由器端口转发配置好之后，你可以在外网环境（比如用手机流量，不要连着同一个Wi-Fi）访问http://公网IP:8080/验证。如果通了，说明端口转发成功。

5.4 DDNS解决动态IP的问题

做端口转发的时候你会发现一个问题：路由器WAN口的IP是动态的，可能每过几天就变了。你昨天记住的公网IP，今天访问就404了。解决方式就是DDNS。

现在主流路由器都内置DDNS功能，支持花生壳、公云、或者路由器厂商自家的域名服务。在路由器的DDNS设置里注册一个域名，路由器会自动把域名解析到当前的公网IP上，IP变了它也会自动更新。这样你外网访问时直接用域名，比如myserver.xicp.net:8080，不用关心IP变成什么。

用DDNS之前我提醒一句：如果你的宽带是运营商分配的内网IP（大内网环境），端口转发就失效了，因为路由器本身没有公网IP，数据进不来。这种情况下，要么联系运营商申请公网IP，要么用内网穿透工具，比如frp、花生壳内网版，不过那是另一个话题了，这里不展开。

5.5 多个服务如何分配外部端口

实际项目中，一台Windows服务器上可能不止跑一个JAR包服务。比如一个后端接口服务占8080，一个管理后台占8081，一个定时任务占8082。这种情况下，路由器端口转发就得多配几条规则。需要注意，外部端口和内部端口可以不一样，比如外部用8000映射到内网8080，好处是你可以在外网用不同的端口区分服务，在服务器内部保持自己的端口规划不变。

另一个建议是外部端口尽量选1024以上的高位端口，因为80、443这些端口往往被宽带运营商封掉了，用不了。如果确实需要让人用域名直接访问（不带端口号），那就得走反向代理，在Windows上装Nginx或Caddy，把80端口转发到后端JAR包的端口上，这个属于进阶玩法，等基础部署跑通后再考虑。

6. 常见问题与排查技巧实录

6.1 端口被占用：明明改了端口还是起不来

Spring Boot启动失败，报Port 8080 was already in use，这个报错几乎每个部署的人都会遇到。排查方法很直接，在服务器上执行：

bash复制netstat -ano | findstr 8080

看输出最后一列是PID，去任务管理器里找到这个PID对应的进程，看看是什么程序占用了端口。一般要么是之前启动的服务没停干净，要么是其他应用（比如Tomcat、IIS）在用。处理方式：如果是自己之前的服务，就结束进程，然后重新启动；如果是别的应用占用，更推荐改自己项目的端口，避免冲突。

这里有个容易犯的错：改了application.yml里的端口，但启动日志还是显示8080。注意看项目是不是用了自定义启动参数，比如启动脚本里java -jar xxx.jar --server.port=9090，这种命令行参数优先级高于配置文件，改配置文件是无效的。我遇到过好几次，同事把application.yml改了，但bat脚本里硬编码了--server.port=8080，死活改不过来。

6.2 防火墙规则建了，外网还是不通

防火墙配置这件事，看起来很简单，但坑很多。常见的几种情况：

入站规则建错了方向。很多人跑到出站规则里建了一条，那当然没用，因为是外部流量进来被拦住了，要看入站。
规则建了但没启用。新建规则后要确认状态是“已启用”，有些时候界面操作没点到位。
规则匹配的端口不对。你建规则时填的是8080，但服务实际跑的是9090，两边对不上。
多个配置文件类型的问题。前面说过，服务器网络如果被识别成公用网络，但你规则只勾了域，等于没放行。

排查思路就一条：先在本机访问，通了；再到局域网另一台机器访问，通了；然后在路由器或云安全组两侧排查，哪一步不通就定位在哪一段。不要从最外圈一个个试，那样效率太低。

6.3 内网访问正常，外网就是访问不了

内网通、外网不通，这个问题基本锁定在出口设备上，也就是路由器端口转发或者云安全组这一层。逐项排查：

确认服务器公网IP到底是哪个。去路由器WAN口状态看IP，然后用浏览器访问这个IP试试。光猫拨号的话，还要看光猫是不是路由模式，如果是，光猫也得做端口映射或者桥接，很多人在这一步卡死。
确认端口转发规则的目标IP写对了。服务器是DHCP动态获取IP的，今天这个IP，明天可能就变了，端口转发规则还指向老的IP，当然不通。给服务器配置静态IP（固定内网IP）是个好习惯，不然重启后规则可能全部失效。
用手机流量测试外网访问，不要连同一个Wi-Fi。很多人说“外网不通”，实际上他测试时手机连的还是公司Wi-Fi，走的还是内网，当然验证不出真实情况。

6.4 JAR包本身启动失败：从日志一秒定位

如果JAR包启动失败，第一步永远是看控制台日志，或者日志文件。常见的启动失败原因我遇到过的：

端口被占，前面说过了。
数据库连接失败：启动过程中Spring Boot会尝试初始化数据源，如果数据库连不上，启动直接中止。看日志里有没有Connection refused或者Access denied。
配置文件读取不到：可能application.yml不在JAR包里，或者外部配置文件路径写错了。Spring Boot允许JAR包同目录下放application.yml覆盖内置配置，这个机制很实用，但路径找错就白搭。
内存不足：启动时报OutOfMemoryError: Java heap space，说明-Xmx设置得太小，或者机器物理内存真的不够了。
依赖缺失：报ClassNotFoundException或者NoClassDefFoundError，大概率是打包时依赖没打进去，检查pom里spring-boot-maven-plugin有没有正确配置。

看一眼日志，基本能锁个七八成。所以一定要养成一个习惯：部署时永远先把启动日志保住，别等出问题了才后悔当时没开日志。

6.5 服务器重启后服务没起来

这个问题在WinSW和NSSM方案里不太容易出现，但用批处理方案的人很常见。原因基本有两种。

一种是任务计划程序没有正确配置“不管用户是否登录都要运行”。默认的任务计划是仅在用户登录时运行，你远程桌面没开，任务就不会触发。选这个选项并设置成“使用最高权限运行”，就可以在无人登录时启动了。

另一种是任务计划虽然配置了开机触发，但JAR包启动依赖了某些服务（比如数据库）还没有就绪，启动直接失败。处理方式是在批处理里加延迟：

bat复制@echo off
timeout /t 30 /nobreak
java -jar D:\app\your-project.jar >> D:\app\logs\app.log 2>&1

先等30秒再启动，数据库那边基本就绪了，问题迎刃而解。

7. 一点实践心得

这套流程从头到尾捋下来，每一步都不复杂，但串起来之后，细节决定成败。我个人印象最深的一次，是在客户现场折腾了整整一个下午，原因是路由器端口映射把内网IP写错了一位。工具再熟练，也怕这种低级错误。所以我后来养成一个习惯：每做完一个环节，就在纸上或者Excel里记一笔，IP是什么、端口映射到哪、防火墙规则叫什么名字，所有信息一目了然。服务器上的东西，配置完一时半会儿根本用不上第二次，全靠记录。

另外，建议大家在正式上线前，把JAR包在服务器上完整跑一遍流程，从上传、启动、注册服务到防火墙、端口转发，全流程走通一次。因为很多问题都是在第一次部署时暴露的，提前走一遍，比上线当天手忙脚乱要从容得多。这套流程熟练之后，从拿到JAR包到外网能访问，半小时内搞定没有任何问题。