JavaWeb项目部署全攻略：从war包到jar包，避开所有坑-代码聚汇网

JavaWeb项目部署全攻略：从war包到jar包，避开所有坑

JavaWeb项目部署Tomcat

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

一开始做JavaWeb交付的时候，我以为项目部署就是把代码扔到服务器上，Tomcat一启动就完事。直到有一次在现场部署，从下午两点折腾到凌晨，最后发现是JDK版本不对，压根不是代码问题，那次之后我才意识到，部署这件事在整个JavaWeb开发链路里，分量一点不比写业务代码轻。尤其是你接触的项目越来越多，从单机部署到服务器集群，从传统war包到Spring Boot的jar包，每一层的选择都直接影响上线后的稳定性。

这篇内容我打算围绕JavaWeb项目部署的完整链路来聊，从环境准备、打包方式、Tomcat/Jar部署、Nginx反向代理，到常见问题的排查思路，全部基于我实际踩过的坑来写。适合刚接触JavaWeb、第一次准备把项目部署到服务器的同学，也适合带过一阵子项目但对部署细节还想再夯实一下的开发者。

1. 项目部署这件事，到底在部署什么

1.1 部署不是“把代码复制过去”，而是把整套运行环境还原出来

很多人第一次部署JavaWeb项目时，下意识会觉得：本地能跑，服务器肯定也能跑。这句话在90%的情况下是错的。因为本地能跑靠的是一整套已经装好的环境：你电脑上的JDK、你IDE里配置的Maven仓库、你本地MySQL里的数据、你调试时用的配置文件。换一台干干净净的服务器，这些一个都没有。

部署的本质，是把“你在本地构建出来的产物”和“它运行所需的全部外部条件”一起交付到目标机器上。后者听起来简单，实际包含的东西不少：

JDK版本：Java 8还是Java 11还是Java 17，直接影响项目能否启动。很多老项目用的是JDK 1.8，Spring Boot 3以上的版本又强制要求JDK 17，版本选错，启动必挂。
外部依赖：数据库、Redis、消息队列、文件存储，每一个中间件都要在服务器上单独部署，并且版本要和本地开发保持一致，否则就会出现“本地好好的，服务器上各种诡异报错”。
配置文件：本地的数据库地址是localhost，服务器的数据库地址是内网IP或者云数据库的公网地址，配置文件不改，服务能起来才怪。
静态资源：如果是前后端分离项目，前端打包后的dist目录也要一并部署，否则页面打不开或者样式丢失。

所以我建议你在动手之前，先把项目拆成三个清单：运行环境清单、中间件清单、配置文件变更清单。列清楚了再动手，部署的成功率会高一半以上。

1.2 两种主流形态：war包和jar包

JavaWeb项目部署方式从大的方向上看，就两种：

war包 + 外置Servlet容器（Tomcat等）：这是传统JavaWeb的标准玩法。项目打包成war文件，放到Tomcat的webapps目录下，启动Tomcat后自动解压部署。适用于Spring MVC、SSM、SSH等传统架构，以及一些必须沿用Servlet规范的旧项目。
jar包 + 内置容器：Spring Boot默认提供的打包方式。项目里内嵌了Tomcat（或者Jetty、Undertow），打包后就是一个可执行的jar，直接用java -jar启动。不需要单独装Tomcat，部署更轻量。

我自己做项目时，如果是新项目，一律推荐用jar包方式。理由很简单：减少一个外部依赖，环境问题就少一类。如果是维护老项目，那种依赖JSP、需要动态热部署的，老老实实打war包继续用Tomcat。

1.3 完整部署链路长什么样

一个典型的JavaWeb项目部署链路，从代码到用户可访问，通常包含这几个环节：

开发环境编写代码，提交到Git仓库。
在服务器（或者本地命令行）拉取代码，执行打包命令（Maven或Gradle）。
把打包产物（war/jar + 前端静态资源）上传到服务器。
服务器上准备运行环境：JDK、MySQL、Redis、Nginx等。
初始化数据库，导入表结构和基础数据。
修改配置文件，把数据库连接、Redis地址、日志路径等切换成生产环境的值。
启动服务（Tomcat、java -jar、systemd托管等）。
用Nginx做反向代理，把域名/端口转给Java服务。
验证：检查日志、访问接口、确认页面正常。

这几个环节任意一步出错，都可能导致部署失败。下面我按照这个链路，把每一步具体怎么操作、有哪些容易踩坑的地方，逐一展开讲。

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

2. 部署前必做的准备工作

2.1 环境清单：JDK版本、Tomcat、数据库

先列一个最小可用的环境清单，以最常见的服务器环境为例：

组件	版本建议	说明
JDK	1.8（老项目） / 17（Spring Boot 3）	先确认项目编译时用的哪个版本，再装对应JDK
Maven	3.6+	服务器上打包用，本地也可以只负责打包上传产物
Tomcat	9.0（war包项目）/ 不需要（jar包项目）	如果项目里用到了Servlet新特性，注意Tomcat 10包名变更
MySQL	5.7 / 8.0	与本地版本一致，避免SQL方言差异
Nginx	1.20+	反向代理和静态资源托管
Redis	5.0+	如果项目用了缓存或Session共享

这里我特别提醒一句：JDK版本是JavaWeb部署变数最大的一个点。有些服务器预装了OpenJDK 11，但项目基于JDK 8编译，运行时大概率报UnsupportedClassVersionError。这个错误信息很明确，但很多新手看到一长串堆栈就慌了，其实就版本不匹配这一件事。

2.2 数据库初始化：脚本比手动执行更可靠

数据库这块，我踩过最深的坑是：本地测试库和生产库的表结构不一致。明明本地跑得欢，一部署到生产环境就报Unknown column。所以现在我有两个习惯，强烈建议你也养成：

第一，数据库结构变更必须沉淀成SQL脚本，用Flyway或者Liquibase管理，或者至少把所有变更语句集中放在一个sql目录下，按版本编号保存。不要在本地开发时直接改表结构，然后指望靠记忆在服务器上重复一遍。

第二，首次部署时，用mysqldump从本地导出完整的数据结构和基础数据，然后到服务器上导入。这里有个小技巧：导出时加上--default-character-set=utf8mb4，避免中文数据乱码。

bash复制# 本地导出（仅结构+数据，不包含建库语句）
mysqldump -uroot -p --default-character-set=utf8mb4 --databases yourdb > yourdb.sql

# 服务器导入
mysql -uroot -p < yourdb.sql

导入完成后，立刻用一种方式验证：连接数据库，查看表数量，随便查几条关键业务表的数据，确认数据完整。

2.3 配置解耦：把环境相关的配置从代码里拆出去

这一点我觉得是JavaWeb项目部署中最值得投资的一步。如果你的项目把所有配置都写死在application.properties或者某个db.properties里，那每次部署都要改源码、重新打包，迟早会出问题。

正确做法是：使用Spring Boot的多环境配置，或者至少让配置文件支持外部化覆盖。

Spring Boot项目里，你可以这样组织配置：

properties复制# application.yml 主配置
spring:
  profiles:
    active: @profile.active@

然后在pom.xml里通过profile来区分环境：

xml复制<profiles>
    <profile>
        <id>prod</id>
        <properties>
            <profile.active>prod</profile.active>
        </properties>
    </profile>
    <profile>
        <id>dev</id>
        <properties>
            <profile.active>dev</profile.active>
        </properties>
    </profile>
</profiles>

打包时：

bash复制mvn clean package -Pprod

这样，application-prod.yml里放生产环境的数据库地址、Redis地址、日志路径，application-dev.yml里放本地开发配置。代码不需要改，配置统一由构建参数控制。

如果你用的是传统的war包项目，同样可以在Spring的xml配置里通过<context-param>加载不同环境的properties文件，原理一样。

提示：无论哪种方式，数据库密码和密钥都不要以明文写在代码仓库里。至少用环境变量或者服务器上的配置文件来管理敏感信息。这个习惯早点养成，后面对接支付、对接第三方平台时会省很多心。

3. Tomcat部署war包：传统JavaWeb的主流玩法

3.1 从构建到上传：war包的完整生命周期

war包的部署方式，本质上是“把Web应用打包成一个可移动的单元，交给Tomcat去托管”。整个流程说起来很直白：

先在本地或服务器上执行Maven打包：

bash复制mvn clean package -DskipTests

打包完成后，在项目的target目录下会生成一个.war文件，文件名通常是项目名.war。把文件上传到服务器的Tomcat安装目录下的webapps文件夹里，启动Tomcat：

bash复制cd /usr/local/tomcat/bin
./startup.sh

Tomcat启动后，会自动把war包解压成一个同名目录，然后加载里面的class文件和配置文件。这时候通过http://服务器IP:8080/项目名/就能访问到你的应用了。

如果不想通过IP加端口访问，而是想直接通过80端口访问，有两个常用办法：一是把war包改名为ROOT.war，这样访问根路径时直接命中你的应用；二是用Nginx做反向代理，把80端口转发到Tomcat的8080端口。Nginx的方案后面我详细讲。

3.2 Tomcat版本选型：Tomcat 9和Tomcat 10之间有个大坑

Tomcat版本这个坑，我见过很多组踩过，这里单独说一下。

Tomcat 10开始，Servlet API从javax.servlet迁移到了jakarta.servlet。如果你的项目是按照老规范编译的（依赖javax.servlet包），直接扔进Tomcat 10里运行，大概率连启动都过不了，报错信息通常是ClassNotFoundException: javax.servlet.Filter之类的。

所以简单的选型规则是：

项目用的Spring版本比较老（Spring 5以下）、Servlet规范是3.x/4.x → 用Tomcat 9，别用Tomcat 10及以上。
项目从零开始、基于Spring Boot 3或Jakarta EE规范 → 可以选Tomcat 10，但一般这时候更多人直接选jar包部署了。

你在服务器上查看Tomcat版本，可以执行：

bash复制/usr/local/tomcat/bin/version.sh

确认好版本再部署，省得反复折腾。

3.3 Tomcat部署war包的几个冷门但实用的细节

虚拟目录和上下文路径：默认情况下，war包解压出来的目录名就是上下文路径。如果你想让项目在根路径下访问，要么改名为ROOT.war，要么在conf/server.xml的<Host>里配置<Context path="/" docBase="你的项目名" />。第二种方式更灵活，但改错server.xml可能导致Tomcat无法启动，改之前先备份。
JSP预编译：如果你的项目依赖JSP，第一次访问会有一个编译的过程，速度会比较慢。能在打包阶段用JSPC插件预编译是最好的，否则就接受第一次请求慢一点的现实。
静态资源优化：war包里的static目录下存放静态资源（CSS、JS、图片），Tomcat处理这些资源的性能比不上Nginx。如果项目访问量大，建议把静态资源交给Nginx托管，Tomcat只处理动态请求。这个后面有专门一节。

4. Spring Boot jar包部署：更轻量的现代方案

4.1 打包和启动：从构建到运行只有三步

Spring Boot项目的jar包部署，我觉得是目前最省心的一条路。流程简洁，不依赖外置容器，部署的可控性也高。

打包：

bash复制mvn clean package -DskipTests

执行完成后，在target目录下生成一个xxx.jar文件。注意Spring Boot打包出来的jar和普通jar不太一样，它是“可执行jar”，里面包含了项目依赖的所有类库以及内嵌的Tomcat。你可以用java -jar直接跑：

bash复制java -jar project.jar

如果你在服务器上手动执行这个命令，会发现一旦关闭终端，程序就跟着停了。这是因为进程直接挂在当前shell下面。解决方式是用nohup：

bash复制nohup java -jar project.jar > app.log 2>&1 &

nohup的完整意义是“忽略挂断信号”，这样即使SSH断开，Java进程也不会被杀掉。输出日志重定向到app.log，后续排查问题全靠这个文件。

4.2 使用systemd管理Java服务：能让进程“死了自动拉起”

虽然nohup简单，但它有一个问题：服务一旦崩溃，不会自动重启。对于需要7x24小时运行的项目来说，这不太够。

Linux下的systemd是更主流的托管方案。新建一个service文件：

bash复制sudo vim /etc/systemd/system/myapp.service

内容如下：

ini复制[Unit]
Description=My JavaWeb Application
After=network.target mysql.service

[Service]
Type=simple
User=root
WorkingDirectory=/opt/myapp
ExecStart=/usr/local/jdk/bin/java -Xms512m -Xmx1024m -jar /opt/myapp/myapp.jar
Restart=on-failure
RestartSec=10
StandardOutput=journal
StandardError=journal

[Install]
WantedBy=multi-user.target

然后执行：

bash复制sudo systemctl daemon-reload
sudo systemctl enable myapp
sudo systemctl start myapp

从这以后，你可以用systemctl status myapp查看服务状态，journalctl -u myapp -f实时查看日志。程序奔溃时，systemd会在10秒后自动拉起，大大降低你深夜被叫起来的概率。我个人现在所有Java服务都是这么管的，没有例外。

4.3 内存参数和JVM调优：不要默认参数一路跑

很多人直接把jdk默认的JVM参数拿来跑生产环境，这通常会出问题。-Xms（初始堆内存）和-Xmx（最大堆内存）最好显式设置，而且给多大要根据服务器的物理内存来算。

一个简单的经验分配方法：

服务器内存8G，Java服务给4G堆，留2G给系统和其他中间件，2G作为缓冲。
服务器内存4G，Java服务给2G堆，别再多了，否则MySQL和Nginx可能因为内存不足直接挂掉。
如果项目里大量使用缓存、批量导出，可以适当调大-Xmx，同时保证-Xms和-Xmx相等，避免运行期动态扩容带来的性能抖动。

一个带基础参数的启动命令长这样：

bash复制java -Xms512m -Xmx1024m -XX:+UseG1GC -jar myapp.jar

G1垃圾回收器是JDK 8u40以上默认的GC，不用额外加也行；显式写出来的好处是让自己和队友清楚项目用了什么GC策略。

4.4 jar包上传和版本管理：你值得有一个发布目录

jar包的版本迭代很快，我不建议直接放在/root下，毕竟过两个月就乱成一锅粥。我习惯在服务器上建一个专门的发布目录，比如/opt/app，每个版本单独建立一个带时间戳的子目录：

bash复制mkdir -p /opt/app/myapp_20250115_2100
mv myapp.jar /opt/app/myapp_20250115_2100/

然后创建一个软链接指向当前运行版本：

bash复制ln -snf /opt/app/myapp_20250115_2100/myapp.jar /opt/app/myapp.jar

systemd的ExecStart里写的永远是/opt/app/myapp.jar这个软链接。发布新版本时，只需要把新jar放到新目录，重建软链接，然后systemctl restart myapp。万一新版本有问题，软链接切回旧版本，一条命令就能回滚。

5. Nginx反向代理和静态资源分离

5.1 为什么JavaWeb项目前面要加Nginx

除非你的项目只是内部系统，访问量很小，否则我建议你加一层Nginx。理由很实在：

端口收敛：Java服务默认跑在8080端口，用户访问时总要带个端口号，显得不够专业。Nginx监听80端口，把请求转发给Java服务，用户直接输入域名就能访问。
静态资源加速：CSS、JS、图片这些文件，让Tomcat或Spring Boot内置Tomcat处理，性能不在最优区间。Nginx处理静态文件非常擅长，而且可以配置缓存，页面加载速度会明显提升。
负载均衡：如果以后项目访问量上来了，部署了两台Java服务，Nginx可以按权重把请求分发到不同节点，这是横向扩展的第一步。
HTTPS终结：SSL证书的配置、HTTP到HTTPS的跳转、TLS握手，这些都给Nginx做，Java服务专注业务逻辑。

5.2 一个最小可用的Nginx配置

前后端分离的场景下，前端项目（Vue/React打包后的dist目录）和Java后端是分开部署的。一个最基础的Nginx配置如下：

nginx复制server {
    listen 80;
    server_name example.com;

    # 前端静态资源
    root /opt/frontend/dist;
    index index.html;

    # 解决Vue Router的history模式刷新404问题
    location / {
        try_files $uri $uri/ /index.html;
    }

    # 后端API反向代理
    location /api/ {
        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;

        # 如果接口上传文件，增大请求体体积限制，默认1m太小
        client_max_body_size 50m;
    }
}

这里有个重点：proxy_pass http://127.0.0.1:8080/;末尾的斜杠不能漏。带斜杠表示把/api/前缀去掉再转发，比如请求/api/user/list，转发给后端的实际路径是/user/list。如果你的后端接口本身定义了/api前缀，那就去掉末尾斜杠，写成proxy_pass http://127.0.0.1:8080;。

5.3 HTTPS证书和自动续期

现在部署新项目，我基本默认打开HTTPS。一方面是因为浏览器对HTTP的限制越来越多，另一方面是项目里如果涉及登录、支付这类敏感请求，明文传密码说不过去。

证书申请现在也很便捷。以较为常用的certbot为例，找一个域名，DNS解析到服务器IP，然后：

bash复制sudo apt install certbot python3-certbot-nginx
sudo certbot --nginx -d example.com

certbot会自动修改Nginx配置，配上SSL证书，而且自带自动续期机制。整个过程几分钟搞定，成本几乎为零。注意续期后可能需要reload下Nginx：

bash复制sudo systemctl reload nginx

5.4 关于宝塔面板这类可视化部署工具

说到部署，很多人会提到宝塔面板。我不否认宝塔面板大幅降低了部署门槛，尤其是对不熟悉Linux命令的人来说，图形界面点点鼠标就能把Nginx、MySQL、Java环境装好。如果你的项目是Spring Boot + Vue3这种组合，宝塔的确能帮你快速搞定基础环境。

但我给你的建议是：可以用宝塔装环境、看资源监控，但不要把整个部署流程完全依赖在面板上。原因很简单：面板本身也只是一个工具，一旦面板升级或出问题，你要能手里有命令行方案兜底。我见过不少人在服务器上装了宝塔后，连文件夹路径都找不到，问题排查起来非常被动。环境安装可以用面板，但部署流程、目录结构、启动脚本这些核心逻辑，自己心里要有数。

6. 部署后的验证检查与日志排查

6.1 服务起来了不算成功，要按业务链路验证

部署完成的标志不是进程还活着，而是业务链路真的通。

我自己的验证顺序是这样的：

检查进程状态：ps -ef | grep java或者systemctl status myapp，确认进程没有退出。
查看启动日志：确认没有报错，关键是看Started Application in x seconds或者Server startup in xxx ms这样的日志。
用curl测试接口：先测健康检查接口，再测一个需要查询数据库的业务接口。
在浏览器里点点点：登录、列表、详情、提交表单，把核心业务流程走一遍。
检查数据库数据：确认写入的数据正常、中文没有乱码。

如果你遇到热词里提到的“车辆轨迹计算某条路走了几个来回、覆盖了多少”这类业务，部署完成后还需要准备一份测试数据，实际验证计算逻辑。这类功能往往涉及空间计算，数据量大，部署后最容易出现的问题就是超时——本地数据量小体现不出来，一上生产数据量上来接口就挂了。所以部署完成后，我建议用生产级数据量跑一遍核心接口，提前发现性能瓶颈。

6.2 日志是排查问题的第一入口

Java服务的问题，九成都能从日志里找到线索。日志要留足，但也不要无脑全开。一个合理的实践是：

项目里用logback或者log4j2做日志配置。
日志按天滚动，保留30天。
应用日志和错误日志分文件。
关键业务（支付回调、定时任务）单独打一份业务日志。

如果你用systemd托管服务，日志默认输出到journal。可以这样看：

bash复制journalctl -u myapp -f
journalctl -u myapp --since "2025-01-15 10:00:00"

如果是nohup方式启动，日志在app.log里，用tail -f app.log查看实时输出。

6.3 部署后的基础监控：不用上复杂体系也能掌握服务状态

对中小项目来说，上完整的Prometheus + Grafana监控体系有点重。我建议从轻量方案开始：

用free -h和top定时看看内存和CPU。
用df -h检查磁盘空间，日志增长太快时尤其重要。
如果项目做对外服务，可以用一个简单的定时脚本检查接口存活，异常时触发告警。
条件允许的话，给项目加一个/actuator/health这类健康检查接口，配合Nginx就能自动剔除故障节点。

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

下面这个表格里的问题，都是我实际部署JavaWeb项目时遇到最多的情况，基本覆盖了热词里大家搜的那些问题。

现象	可能的原因	排查命令/手段	解决方案
启动报错`UnsupportedClassVersionError`	JDK版本和项目编译版本不匹配	`java -version`	安装项目要求的JDK版本，或重新用目标版本编译
端口被占用，Tomcat/Java启动失败	其他进程占用了8080端口	`netstat -tlnp \| grep 8080`	杀掉占用进程，或修改服务端口
页面中文乱码	数据库字符集、连接串、文件编码不一致	`show variables like 'character_set%';`	统一使用`utf8mb4`字符集，连接串加`characterEncoding=utf8`
数据库连接失败	IP、端口、账号、密码不对，或数据库没开放远程访问	`mysql -h 数据库IP -P 端口 -u 用户 -p`	逐一核对配置，确认数据库账号有授权且有远程访问权限
前端页面打开了，但接口请求失败	前端和后端没通过Nginx串起来，跨域或路径不对	浏览器F12查看Network请求	检查Nginx的`location`匹配规则和`proxy_pass`路径
502 Bad Gateway	Nginx连不上后端Java服务	`systemctl status myapp`，`curl 127.0.0.1:8080`	确认Java服务正常运行，检查Nginx配置里的代理地址
内存溢出后进程自动退出	`-Xmx`设置过大或代码有内存泄漏	`grep -i oom /var/log/messages`，查看GC日志	调整JVM堆内存，优化代码，配合systemd的`Restart=on-failure`
部署新版本后接口行为异常	缓存没有清理，旧进程没被杀干净	`ps -ef \| grep java`，`kill -9 进程号`	先杀进程再启动，必要时清空临时目录
支付回调不通	回调地址填的是localhost，或者没做内网穿透	检查第三方平台回调配置	回调地址必须填公网可访问的域名/HTTPS地址

这里面我再单独强调两个比较隐蔽的坑。

第一个：时区问题。 很多人的数据库连接串里没有serverTimezone参数，或者写的是UTC，导致时间比其他时间差8小时。建议连接串里显式写serverTimezone=Asia/Shanghai，前后端日期格式化统一用yyyy-MM-dd HH:mm:ss，避免时区差异带来的数据错乱。

第二个：关闭Debug日志。 有些项目开发时打开了debug级别的日志，部署到生产环境忘了关，结果日志文件疯狂膨胀，一晚上吃掉几个GB磁盘。部署后第一件事，检查日志级别，生产环境至少是info，一般建议warn起步。

8. 两个部署场景的补充说明

8.1 老项目迁移：本地项目第一次上服务器怎么搞

如果你是第一次把一个本地JavaWeb项目部署到自己的云服务器，我的建议是别一上来就追求高大上。先把链路跑通，再逐步完善。

推荐这样走：

服务器装好JDK和Tomcat（war包项目）或者JDK和数据库（jar包项目）。
数据库导入本地导出的SQL文件。
用Maven在本地打包，把war/jar上传到服务器。
启动服务，直接用IP加端口访问。
确认能访问了，再装Nginx，配置域名和反向代理。
熟悉了基础链路后，再回头看有没有必要上systemd、HTTPS、自动化部署这些进阶内容。

这个顺序的核心价值在于：每一步的失败原因可控制。一上来就同时引入域名、HTTPS、Nginx、自动化脚本，一旦出现问题，你根本不知道是哪个环节引起的。

8.2 项目涉及第三方对接时的部署要点

热词里有人提到“javaweb对接支付”和“高德关键字查询在HTML中的使用”，这类项目部署时有个共性特点：依赖外部的第三方服务，而且很多回调类接口要求公网可访问。

支付对接时，回调地址必须写一个公网可访问的地址，而且推荐直接用HTTPS域名。如果用HTTP，部分支付平台会有限制。部署完成后，需要在支付平台后台配置回调地址，并确保你的服务能正常接收回调请求。

高德地图这类前端服务，密钥要放在前端代码里吗？如果你用的是Web端JavaScript API，配置的key本身是绑定域名白名单的，所以不用担心泄露。但部署时要注意：配置的域名要和你实际部署的域名保持一致，否则地图服务会拒绝请求。这个细节我第一次部署时忽略了，结果本地可以，一上服务器地图白屏，排查了很久才找到原因。

9. 一些部署习惯和项目实例参考

9.1 发布检查清单：每次部署前过一遍

发布这种事，最怕的就是“临门一脚”出差错。我给自己整理了一个发布检查清单，每次上线前逐项过一遍：

[ ] 代码已经提交并推送到了Git仓库
[ ] 配置文件已切换为生产环境（数据库地址、Redis地址、日志路径）
[ ] 数据库脚本已经执行，且执行结果正确
[ ] 本地打包成功，产物（war/jar）存在
[ ] 旧版本进程已经停止
[ ] 新版本产物已上传到发布目录
[ ] 启动命令正确（JVM参数、环境变量）
[ ] 启动日志没有报错
[ ] 核心业务接口用curl验证通过
[ ] 前端资源已更新（如果是前后端分离项目）
[ ] Nginx配置已reload

这些检查项不需要写得多复杂，但能显著减少低级失误。

9.2 从《JavaWeb从入门到精通》这类书到真实项目的距离

很多人会照着书上的案例做项目，书里通常教你在IDE里点运行，然后用浏览器访问localhost:8080，这是学习阶段的合理路径。但真实项目部署和书上的最大区别在于：书上的环境是封闭的，你只有一台机器，而真实项目需要面向外部用户，要面对公网、域名、HTTPS、数据库远程访问、安全等方面。

我之前带过一个同学，照着书做了一个完整的学生管理系统，本地跑得很好。第一次部署到云服务器时，从装JDK到数据库导入，再到Nginx配置，花了整整一天。但那一次之后，他对JavaWeb的理解完全上了一个台阶——因为他终于知道了一个Web项目从“代码”变成“产品”要经过多少个环节。这个过程的收获，不亚于再写一个项目。

9.3 Docker部署值得了解，但别急着全面替代传统方式

热词里也出现了“docker部署springboot项目”，这项技术在团队协作和环境一致性方面确实好。容器化部署的优势我认同，比如同一个镜像在任何机器上都能跑，省去了环境差异带来的问题。

但我的建议是：如果你是新手，或者项目还处于起步阶段，先把传统部署方式跑熟，再接触Docker。原因不复杂：Docker提供的是“标准化环境”的能力，而使用Docker的前提是，你清楚你的应用需要什么样的环境、需要哪些端口、需要挂载哪些目录、日志怎么持久化。这些东西不通过在传统部署里踩几个坑，很难真正理解到位。直接上Docker，出了容器内的问题，你可能反而更抓手。先能跑通，再谈容器化，这个顺序对大多数人更合适。

10. 写在最后的建议

项目部署这件事，动手做一次比看十篇文章都管用，真要去部署时，把上面这些章节当作一份参考清单来用。我个人在实际操作中的体会是：部署最耗时的往往不是技术本身，而是“环境不一致”带来的各种隐藏问题。如果你能在部署前就做到配置解耦、数据库脚本化、环境清单明确，那么整个部署过程会从“碰运气”变成“走流程”，成功率几乎可以达到百分之百。

最后再分享一个小技巧：无论你用什么方式部署，Server上都留一个deploy.sh脚本，把启动、停止、查看日志、回滚这些常用操作封装成命令。这样即便过个半年再回去维护这个项目，你也不会因为忘了当初怎么部署而头疼。部署这件事，讲究的就是“可重复、可回滚、可追溯”，把这个原则记在心里，你的项目运维体验会好很多。