企业官网建设流程全解析

1. 环境准备：先把服务器这台“毛坯房”收拾干净

接到“在Windows服务器上部署JavaWeb项目”这个需求，很多人的第一反应是直接下载JDK、装Tomcat、扔个war包上去，结果跑到一半被各种报错卡住。我在真实生产环境里反复踩过几轮之后，最大的感触是：部署JavaWeb项目的成败，往往在动手装第一个软件之前就已经决定了。

为什么这么说？因为Windows服务器和咱们自己电脑上跑IDEA完全是两码事。服务器的系统版本、内存大小、端口占用情况、自带的杀毒软件、远程桌面连接方式，这些外部因素每一样都能让你的Tomcat起不来、数据库连不上、图片传不上去。所以在写任何部署步骤之前，先搞清楚“这台服务器到底是什么环境”，比急着装环境更重要。

1.1 为什么要选Windows服务器跑JavaWeb

先聊个很多人纠结的问题：网上铺天盖地的教程都是Linux服务器部署，什么CentOS、Ubuntu，为什么还要有人在Windows服务器上部署JavaWeb？

真实原因是这样——相当多的中小型公司、传统企业、高校实验室，服务器系统就是Windows Server。有的是因为历史原因，公司的自研系统和财务软件只支持Windows；有的是因为运维团队本身对Windows更熟悉，不想额外养一个Linux运维；还有的就是买了云服务器Windows镜像，图个桌面操作直观方便，想改文件、看日志、装个Navicat全都靠鼠标点一点就能完成。

Windows Server部署JavaWeb并不是“错误方案”，而是“特定场景下的适用方案”。只要不是要求极致并发、超大流量、复杂容器编排的项目，Windows Server 2012/2016/2019跑Tomcat+Nginx完全够用。我们需要做的，是在这个平台上把每一步配置做稳、做规范，避免因为平台差异留下隐患。

1.2 服务器基本信息摸底清单

拿到一台Windows服务器之后，不要急着装东西，先做一轮信息确认。我习惯用五到十分钟把下面这些信息记下来：

• 系统版本：Win+R打开winver看版本号。Windows Server 2012 R2、2016、2019、2022，不同版本对软件的支持策略不同，比如JDK 8在2012上没问题，但JDK 17在某些老版本Windows上可能就力不从心。
• 内存和CPU：右键“此电脑”查看。Java项目启动前你需要知道你的堆内存要配多大，Tomcat默认的JVM参数是-Xms512m -Xmx1024m（我一般用jinfo -flags PID看或者直接在catalina.bat里改），如果服务器总共就2G内存，那你的项目部署完可能就只能给Tomcat分512M，数据库还得再占一块。
• 磁盘空间：确认C盘剩余空间，避免日志把磁盘塞满。
• 端口占用情况：JavaWeb项目必备三个端口——Tomcat默认8080（可以改）、MySQL默认3306、远程桌面3389。如果8080被别的程序占了，Tomcat启动会一直报Address already in use: JVM_Bind，这点最容易让人抓狂。查端口命令：netstat -ano | findstr "8080"，查到PID之后再去任务管理器里处理。
• 杀毒软件：Windows Defender在Server系统上默认开启，有时候会把Tomcat的临时文件、jar文件给拦截掉，尤其是刚解压的文件。我遇到过几次项目部署上去，一启动Tomcat就报严重错误，最后发现是Defender把commons-io-2.x.jar给隔离了，可气的是它连通知都不弹。所以装完环境后建议把Tomcat目录和项目目录加入Defender排除项。

这些信息先确认完，心里有底了，再开始装环境就顺畅得多。

1.3 版本选型是部署的第一道门槛

版本选型是我每次部署前花时间最多的事情。很多新人随便下载一个最新版JDK就去装，结果项目用的是SSH框架基于JDK 8写的，用JDK 17一编译，依赖注入直接出错，最后花两天时间排查发现是版本不兼容，白白浪费时间。

我个人用的稳定组合是：JDK 8 + Apache Tomcat 8.5或9.0 + MySQL 5.7（或8.0）+ Maven 3.6.3。这几个版本在Windows Server上经过无数生产项目验证，兼容性最好，网上遇到问题能搜到的解决方案也最多。如果你的项目是Spring Boot 3.x，那必须要JDK 17起步，对应的Tomcat内嵌版本也会更高，这时候选Tomcat 9/10做外置部署也没问题。

提示：版本选型不是“越新越好”，而是“项目用什么，服务器就配什么”。最好先在本地确认项目要求的Java版本、Servlet版本、数据库驱动版本，然后把这些版本号写进部署文档。

2. 核心软件安装：JDK、MySQL、Tomcat逐一搞定

环境摸底做完了，版本定好了，接下来就是动手安装。这一章我按“先装JDK，再装MySQL，最后装Tomcat”的顺序来写，因为Tomcat需要依赖JDK，MySQL虽然不是必须依赖Java，但先装MySQL方便你后面建库导数据，这样项目一上来就能跑通。

2.1 JDK安装和环境变量配置

JDK安装本身没什么难度，双击安装包一路Next就行，但有几个细节要注意：

• 安装路径不要带空格和中文。虽然JDK对带空格路径的兼容性比以前好了很多，但我依然推荐装在C:\Java\jdk1.8.0_202这种纯英文无空格路径下，省得后面写脚本、配环境变量时出各种诡异问题。
• 记得配置JAVA_HOME和PATH。装完后打开“高级系统设置 → 环境变量”，新建系统变量JAVA_HOME，值填JDK安装路径，比如C:\Java\jdk1.8.0_202。然后在Path变量里新增两项：%JAVA_HOME%\bin和%JAVA_HOME%\jre\bin。配置完之后，打开新的命令行窗口，输入java -version验证，能正常输出版本号就是成功。

关于JAVA_HOME的配置，有几点经验：

环境变量配置完成后必须新开命令行窗口才生效，老窗口不会重新加载环境变量。我见过至少三次，同事配置好了JAVA_HOME，但在已开着的CMD窗口里敲java -version，提示“不是内部或外部命令”，以为配错了，其实只要关掉CMD重新开就行。另外，如果服务器装了多个Java版本，注意Path变量里%JAVA_HOME%\bin要排在Oracle目录之前，否则系统可能先找到别的Java路径。

验证JDK之后，建议顺手验证一个容易被忽略的项——javac -version。有的环境只装了JRE，没有JDK的编译器，后续在服务器上用Maven打包时就会直接报javac: command not found。

2.2 MySQL安装和初始化设置

MySQL是JavaWeb项目的重头戏，也是Windows部署中坑最多的地方。官方MSI安装包适合桌面操作，你也可以下载ZIP包手动解压安装，但核心配置逻辑是一样的。

首先说字符集问题，这是血泪教训。中文乱码绝对排得上JavaWeb部署问题前三名。为了避免乱码，MySQL安装完成后要确认my.ini配置里的字符集设置，关键在[mysqld]段下配置：

[mysqld] character-set-server=utf8mb4 collation-server=utf8mb4_general_ci skip-character-set-client-handshake

utf8mb4比utf8强的地方在于，它能存四字节的Emoji表情和生僻字，现在的业务数据里出现各种奇怪符号太常见了，直接上utf8mb4最稳妥。客户端连接时skip-character-set-client-handshake让服务器忽略客户端的字符集声明，统一使用服务器的utf8mb4设置，一劳永逸地避免乱码。

然后是身份认证插件的问题。装MySQL 8.0的话，默认的认证插件是caching_sha2_password，但老项目用的JDBC驱动版本可能只认mysql_native_password，会导致连接数据库时直接报Public Key Retrieval is not allowed或Unable to load authentication plugin。解决思路有两个：

• 升级JDBC驱动为mysql-connector-java 8.0.x以上。
• 在MySQL里把用户认证插件改回mysql_native_password：

ALTER USER 'root'@'%' IDENTIFIED WITH mysql_native_password BY '你的密码'; FLUSH PRIVILEGES;

这两条命令在MySQL 8.0.34之后的版本里可能提示密码复杂度问题，密码要包含大小写字母、数字和特殊字符才能通过策略检查，如果不想搞那么复杂就先执行SET GLOBAL validate_password.policy = LOW;再改。

Windows上MySQL安装完默认root用户只能从localhost连接。如果Java后端部署在同一台服务器上，那用jdbc:mysql://localhost:3306/数据库名连接就行，不需要额外开远程访问。但如果你用本地Navicat连服务器数据库，就必须创建远程访问用户：

CREATE USER 'root'@'%' IDENTIFIED BY '密码'; GRANT ALL PRIVILEGES ON *.* TO 'root'@'%'; FLUSH PRIVILEGES;

同时还要到“Windows防火墙 → 高级设置 → 入站规则”里放行3306端口，否则Navicat会一直转圈最后报Can't connect to MySQL server (10060)。云服务器的话，还要到控制台的安全组里加一条放行3306的规则，两个地方都通了才能连上。

MySQL服务建议设置为自动启动，在services.msc里找到MySQL服务，右键设置启动类型为“自动”，并把登录身份改成本地系统账户，避免开机后手动启动数据库。

2.3 Tomcat安装和基本配置

Tomcat安装比MySQL省心一些，解压即用，但有几个配置点要注意。

解压之后，先把Tomcat的端口号确认一遍。打开conf/server.xml，核心配置段长这样：

<Connector port="8080" protocol="HTTP/1.1" connectionTimeout="20000" redirectPort="8443" />

如果服务器的8080端口已经被占用，把port改成8081或者你公司规定的其他端口。但改完之后，后面访问地址也要跟着变，远程桌面和防火墙放行时也要用新端口。

Tomcat使用前一定要先看看内存配置是否够用。在bin目录下找到catalina.bat（Windows专用），在文件开头加一段JVM参数：

set JAVA_OPTS=-Xms512m -Xmx1024m -XX:MetaspaceSize=128m -XX:MaxMetaspaceSize=256m -Dfile.encoding=UTF-8

参数含义： -Xms：JVM启动时初始堆内存 -Xmx：JVM最大堆内存 MetaspaceSize：元空间初始大小，JDK 8之后没有PermGen了，用本地内存作为元空间 file.encoding：强制Java文件读写编码为UTF-8，避免中文乱码

内存大小怎么定？一般建议-Xmx不超过服务器物理内存的1/4到1/2。比如服务器16G内存，给Tomcat分4G就够了；2G内存的小机器，分512M到1G比较稳妥，否则内存直接爆掉，Windows会持续疯狂换页，服务器卡到鼠标都动不了。

安装完之后，打开浏览器输入http://localhost:8080，看到Tomcat小猫页面就说明Tomcat本体没有问题。在小猫页面之前，如果出现404或者页面打不开，八成是端口问题、JDK环境变量问题或防火墙拦截，按顺序排查就好。

3. 项目打包上传：从IDEA到服务器的标准流程

环境装好了，接下来就是把咱们本地的JavaWeb项目从开发环境搬到服务器上。这一步涉及两个核心问题：怎么打包？怎么传？

3.1 Maven配置和项目打包

如果你用的是Maven工程，执行clean package -DskipTests打包之前，建议先看一眼Maven的settings.xml，确认两件事：

• 本地仓库路径：默认在C:\Users\用户名\.m2\repository，如果你服务器上的构建用户不是Administrator，那打包时下载的依赖会绕一大圈跑到另一个用户目录。
• 镜像源配置：国内网络直接访问Maven中央仓库有时候很慢，建议在settings.xml里配阿里云镜像：

<mirror> <id>aliyunmaven</id> <mirrorOf>central</mirrorOf> <name>阿里云公共仓库</name> <url>https://maven.aliyun.com/repository/public</url> </mirror>

配置完镜像后，再执行mvn clean package -DskipTests，最终在target目录下会生成你的项目名.war（如果打的war包）或者直接是Spring Boot的可执行jar。

这里要说一下war包和jar包的区别：传统JavaWeb项目（JSP+Servlet+Spring MVC）打出war包之后要扔到Tomcat的webapps目录下，由Tomcat容器去加载；Spring Boot项目默认打成可执行jar，里面内嵌了Tomcat，你只需要java -jar 项目名.jar就能直接跑。两种方式在Windows服务器上都能用，但部署逻辑完全不同。

• 如果你是Spring Boot的jar包，那Tomcat外置不装也行，直接java -jar运行。
• 如果你是传统war包，那必须要有外置Tomcat，并且把war包放到webapps目录下。

我的建议是：哪种方式取决于你的项目技术栈，不要为了简化部署把war改jar或者反过来，除非你很确定项目里没有依赖Servlet容器提供的类。

3.2 文件上传的几种方案对比

打好的war包或jar包怎么传到服务器？Windows环境和Linux不一样，Linux下大家习惯用scp或rsync，Windows下更常见的方式有：

• 远程桌面复制粘贴：直接通过远程桌面连接，在本地复制war包，到服务器桌面上粘贴，最直观，适合小文件（几十MB以内）。注意远程桌面传输大文件时容易中断，几百MB的大包不建议这么传。
• WinSCP或Xftp：SFTP协议传输，速度稳定、支持断点续传，强烈推荐。从公司网络传到云服务器，一般10MB/s到50MB/s，一个100MB的war包两分钟之内搞定。
• 宝塔面板/第三方工具：如果你服务器装了宝塔面板，直接网页上传到指定目录就行，对新手最友好，但要注意宝塔本身也会引入一些安全风险，生产环境按需选择。

从生产角度来说，我推荐WinSCP。它在Windows上非常成熟，传输日志支持可追踪，如果传了一半断了可以续传，不会因为网络抖动让你重来一份上百MB的包。

3.3 war包/Jar包部署到Tomcat或直接运行

war包部署的标准路径：把你的项目.war复制到Tomcat的webapps目录，然后启动Tomcat（双击bin/startup.bat或运行catalina run），Tomcat会自动解压war包，生成一个同名目录作为项目的上下文根路径。

访问地址就是：http://服务器IP:8080/你的项目名/。

如果你希望项目通过根路径http://服务器IP:8080/直接访问，不想带项目名，有两个办法：

• 把war包改名为ROOT.war，替换掉Tomcat webapps下自带的ROOT目录。
• 在Tomcat的conf/server.xml的<Host>节点中加入上下文配置：

<Context path="" docBase="你的项目名" reloadable="true" />

第一种方法比较简单粗暴，适合只有一个项目的场景；第二个方法灵活一点，适合同端口部署多个项目的情况。但注意，改server.xml是有讲究的，配置写错了Tomcat可能启动不起来，改之前先备份文件。

jar包的方式更省事，不依赖外置Tomcat。直接把jar包放到服务器任意某目录（比如D:\apps\），然后用命令行运行：

java -jar 你的项目.jar --server.port=8080

--server.port可以覆盖application.yml里的端口配置，适合在不改代码的情况下临时换端口。

但直接java -jar在命令行窗口里运行有一个非常致命的坑：窗口一关，进程就没了。生产环境不会让你天天开着远程桌面挂着CMD跑程序，所以后面专门讲一下用NSSM把jar包注册成Windows服务的方法。

4. 数据库导入与项目配置修改

项目文件到服务器了，数据库还没弄好，照样跑不起来。这一阶段干两件事：把本地数据库的结构和数据搬到服务器，改项目配置文件里的连接信息。

4.1 数据库导出和导入实操

先说导出。在本地Navicat里右键数据库 → “转储SQL文件” → “结构和数据”，生成的.sql文件就是你要的东西。如果你喜欢更原生一点的命令行方式，也可以用mysqldump：

mysqldump -uroot -p --default-character-set=utf8mb4 数据库名 > 备份文件.sql

注意一定要在导出时指定--default-character-set=utf8mb4，否则导出的SQL文件里中文注释和表结构可能乱码，导回来之后整个数据库一头雾水。

导出的SQL文件传到服务器上之后，在服务器的MySQL里执行导入。命令行方式：

mysql -uroot -p --default-character-set=utf8mb4 目标数据库名 < 备份文件.sql

也可以用Navicat连接到服务器MySQL，然后直接右键“运行SQL文件”。相关经验是，导入之前先建好同名的空数据库，否则导入时如果SQL文件里有USE语句还好，没有的话数据会全部灌进当前默认数据库，到时候表关系全乱。

导入完成后，执行一条查询验证一下：

SHOW TABLES; SELECT COUNT(*) FROM 你最主要的那张业务表;

确认表和数据都在，说明数据库迁移到位。

4.2 修改项目的数据库连接配置

这一步最容易被忽略。本地连的数据库密码是123456，服务器上的密码是Xx@2024#，项目里配置如果还是旧的，那部署上去启动的时候必然报Access denied for user 'root'@'localhost'。

传统JavaWeb项目的数据库连接配置一般在WEB-INF/classes/jdbc.properties或者applicationContext.xml里，Spring Boot项目则在application.yml或application.properties里。需要修改的核心项：

jdbc.driver=com.mysql.cj.jdbc.Driver jdbc.url=jdbc:mysql://localhost:3306/你的数据库名?useUnicode=true&characterEncoding=utf8mb4&useSSL=false&serverTimezone=Asia/Shanghai jdbc.username=root jdbc.password=服务器上MySQL的实际密码

URL后面那串参数看着繁琐，每个都有用：

• useUnicode=true&characterEncoding=utf8mb4：保证写入数据库中文不乱码。
• useSSL=false：本地连接MySQL 5.7以上版本时，不关SSL经常会出一堆警告，在公网传输时密码可能被明文拦截的风险更大，直接用false更省心。
• serverTimezone=Asia/Shanghai：MySQL驱动8.x版本对时区要求很严格，不设置时区会直接报The server time zone value 'EDT' is unrecognized，指定东八区就可以了。

如果你的项目用了连接池（Druid、C3P0、HikariCP），配置字段名会略有不同，但核心的url、username、password三个参数是必须对的。改完配置之后，重新打包项目，把新的war包/jar包再传到服务器覆盖旧的。

4.3 配置文件修改后的重打包注意

有一点我每次都会在部署文档里标红：修改配置文件之后，一定要重新打包，然后重启Tomcat（或jar进程），不要只覆盖一个配置文件到Tomcat的classes目录就完事。为什么？因为war包在Tomcat里是被解压后的，你确实可以只替换解压目录里的class或properties文件，Tomcat的reloadable机制也支持热加载，但这种方式容易造成“你改的是解压后的目录，下次Tomcat重新解压war包，你的修改全没了”的尴尬局面。

所以标准流程是：本地改配置 → Maven重新打包 → 先停掉服务器上的Tomcat → 删掉webapps下面旧的war包和解压目录 → 上传新的war包 → 再启动Tomcat。这套顺序能保证你线上跑的代码和配置，和你期望的一模一样。

5. 启动、自启动与防火墙：让项目“开机就有”

很多人的部署走到“项目能访问了”就结束了，但真正的生产部署还差最后三公里：项目开机自启、端口防火墙、日志检查。

5.1 用NSSM把jar包注册成Windows服务

前面提到，java -jar方式启动的项目，关掉CMD窗口进程就没了。解决办法是用NSSM（Non-Sucking Service Manager，一个把任意程序包装成Windows服务的工具）把项目注册成系统服务，这样Windows开机后服务会自动启动，进程崩溃后还能自动拉起，相当好用。

NSSM的用法非常简单：

nssm install 你的服务名

执行后会弹出图形界面，在“Application”标签页里设置：

• Path：Java的完整路径，比如C:\Java\jdk1.8.0_202\bin\java.exe
• Startup directory：jar包所在目录
• Arguments：-Xms512m -Xmx1024m -jar 你的项目.jar

设置完之后点“Install service”，然后在Windows服务管理器里就能看到名为“你的服务名”的服务了，右键启动即可。以后开机它自己会跑，崩溃了也会自动拉起来，非常省心。

如果遇到注册成功但服务启动失败的情况，去NSSM配置界面看“Log on”标签页的服务账户设置。我见过某台服务器把服务账户设成一个没有权限的域用户，导致java进程无法访问jar包目录，改成Local System account后就正常了。

5.2 传统war包的Tomcat开机自启设置

用Tomcat跑war包的，不用额外注册服务，Tomcat本身自带Windows服务支持。在Tomcat的bin目录下执行：

service install Tomcat9

这个命令会把Tomcat注册成名为“Tomcat9”的Windows服务。之后在services.msc里把启动类型设为“自动”，Tomcat就会开机自启。如果哪天你不想用服务模式了，用service remove Tomcat9就能卸载。

值得注意的操作细节是，Tomcat安装成服务后，修改catalina.bat里的JAVA_OPTS未必会生效，因为服务模式读取的是注册表里的配置。想改服务模式下的JVM参数，要运行bin/tomcat9w.exe（图形配置工具），在“Java”标签页里设置Initial memory pool和Maximum memory pool，或者点击Java Options手动追加-Dfile.encoding=UTF-8。

5.3 防火墙端口放行和安全组配置

Tomcat项目和jar包项目能端口访问，除了程序本身要监听，还得让外部流量能到达这个端口。这一步有两个地方要配置：

Windows防火墙放行：

1. 打开“控制面板 → Windows Defender防火墙 → 高级设置”。
2. 点击“入站规则” → “新建规则”。
3. 选择“端口” → 填写你的Tomcat端口（如8080）或MySQL端口（3306）。
4. 选择“允许连接” → 选择全部配置文件（域、专用、公用都勾上）。
5. 给规则起个名字，完成。

云服务器安全组放行：

如果你用的是阿里云、腾讯云、华为云等云服务器，光配Windows防火墙还不够，云控制台里的“安全组”也要放行对应端口。在安全组规则里添加入方向规则，端口范围填8080/8080，授权对象填0.0.0.0/0（表示所有IP都能访问，如果只想让公司IP访问，就填你公司的公网IP）。

提示：安全组和防火墙的差别在于，安全组是云平台层面的网络隔离，防火墙是服务器系统层面的访问控制。两层都放行，外部才能真正访问到你的服务。如果网页打不开，排查顺序就是：先看云安全组，再看Windows防火墙，再看Tomcat/Java进程是否在监听，最后看项目日志。

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

部署过程中碰到的问题，十个里有八个都是重复的。这里我把这些年在Windows服务器上部署JavaWeb项目遇到最多的典型问题整理成速查表，顺便分享一些排查经验。

6.1 Tomcat闪退的深入排查

Tomcat闪退应该是最常见的启动问题了。双击startup.bat后只会看到一个黑框一闪而过，什么信息都没留下。这种情况的排查思路我总结成一套操作：

不要用startup.bat，直接用命令行跑到前台模式：

catalina run

或者直接双击bin/catalina.bat在控制台里运行，Tomcat会把启动过程中的所有日志打到这个命令行窗口上，错误信息就一目了然了。闪退最常见的原因是JAVA_HOME没配置对，命令行会直接提示找不到JAVA_HOME或者找不到bin/java.exe。

还有一种情况是Tomcat日志目录没有写权限，导致启动过程中日志写不进去，静默失败。检查logs目录是否有写入权限，必要时右键属性把everyone账户的完全控制权限加上。

6.2 杀毒软件和防火墙的“隐形拦截”

Windows Server自带的Defender虽然在绝大多数情况下不会影响正常运行，但对于Tomcat这种要执行很多jar包、写临时文件的程序来说，偶尔会被误判。我遇到的典型现场是：项目部署完，启动Tomcat，日志里一堆ClassNotFoundException或Unable to load class，但本地跑得好好的。

排查方法是打开Defender的“保护历史记录”，查看有没有文件被隔离。如果有，把整个部署目录（比如D:\tomcat和D:\apps）加进“排除项”，然后重启Tomcat。当然，如果你的公司对Windows Defender有统一管控策略（比如有McAfee、360企业版等），那还要到对应的杀毒控制台把项目目录排除掉。

6.3 数据库相关问题的定位次序

数据库连接失败在部署问题里出现频率极高。遇到类似的报错，先不要急着改代码，按下面顺序排查：

1. 确认MySQL服务在运行：services.msc里查MySQL服务状态。
2. 确认账号能登录：命令行执行mysql -uroot -p你的密码，能进命令行说明账号密码正确。
3. 确认JDBC驱动版本和URL写法：MySQL 8.0用com.mysql.cj.jdbc.Driver，老项目里常写com.mysql.jdbc.Driver，驱动6.x之前的写法，8.x之后会直接报ClassNotFoundException。
4. 确认网络可达：如果Java项目不在本机，测试telnet 服务器IP 3306，能通说明网络没问题。

这套流程走下来，80%的数据库连接问题都能解决。

6.4 Nginx反向代理的选配经验

如果你需要直接用域名访问而不带端口，或者想用80端口把请求转发到8080，那可以在Windows上装一个Nginx做反向代理。Windows版Nginx同样从官网下载解压即用，配置方法简单来说：在conf/nginx.conf里设置upstream后端Tomcat地址，并监听80端口：

server { listen 80; server_name 你的域名或IP; location / { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } }

这样外部访问http://IP/就直接被转发到Tomcat的8080端口。Nginx在Windows下也能注册成服务，但Nginx在Windows上的性能比Linux略低，这个方案适合中小流量项目，高并发场景建议还是上Linux系统。

7. 部署完成后必做的三件事

项目能访问、能登录、能操作，部署就算成功了吗？我的答案是：到这一步只是“上线”，还不算“交付”。真正负责任的部署，还差三个收尾动作。

第一件事，写一份部署记录文档。记录内容至少包括：服务器IP、系统版本、JDK版本及路径、MySQL版本及账号、Tomcat路径及端口、项目的部署路径（war解压目录或jar包绝对位置）、服务的启动方式（NSSM服务名或Tomcat服务名）、数据库备份文件位置，以及本次部署修改过的所有配置项。写文档不费多少时间，但下次项目升级或者故障排查时，那份文档能帮你省下以天计的时间。

第二件事，设置日志清理策略。Java项目跑时间长了，Tomcat的logs目录和项目自己的日志文件会变得非常庞大。我见过一台云服务器40G硬盘，被Tomcat的catalina.out积累到占满，最后整个服务器连远程桌面都登不进去的情况。Windows下可以用任务计划程序定期删除超过N天的日志文件，项目里能配置日志滚动的话一定要打开。

第三件事，确认数据库备份和项目备份机制。手动备份依赖人的自觉性，人总会忘，所以更推荐在Windows任务计划程序里配置定时任务，每天凌晨执行一次mysqldump，把备份文件保留最近7天或30天。平时项目文件也要定期拷贝到本地或者其他存储，避免服务器磁盘损坏导致整个项目全丢。

做完了这三件事，一个“能跑、好维护、可恢复”的Windows服务器JavaWeb部署才算真正交付。

我个人在实际部署中最大的体会是：Windows部署JavaWeb项目，难的不是某个技术点本身，而是“细节之间的连带关系”。环境变量配错了，Tomcat启动不了；Tomcat启动不了，war包解压不了；war包解压不了，项目自然访问不了；最后排查来排查去，根源可能就是JDK安装时路径多了一个空格。所以平时部署时养成写部署记录、按标准流程操作的习惯，比临时抱佛脚去查报错高效得多。最后再分享一个小技巧：部署的时候一定不要用Administrator账户直接跑生产服务，哪怕公司管理没那么规范，至少也要建一个独立的服务账户，权限只给到部署目录和项目目录，这样真出了安全问题，影响面会小很多。