把Java项目部署到Tomcat服务器，流程核心就三步：把项目打包成WAR包、把WAR包放进Tomcat的webapps目录、启动Tomcat让它自动解压运行。
无论你是刚学JavaWeb的学生，还是第一次负责上线功能的在职开发，整个部署过程都围绕这三个动作展开，下面我按实际操作的先后顺序,把每一步涉及的坑和细节都拆开讲清楚。
java项目部署tomcat服务器步骤详解
部署前的准备工作：确认JDK与Tomcat版本匹配
动手拷贝文件之前，先确认机器上的基础环境，Tomcat本身是一个Servlet容器，它跑在JDK之上，如果JDK没装好,后面所有操作都会报错。
- 检查JDK版本：在命令行输入
java -version，确认显示1.8或更高版本，Tomcat 9及以下版本对JDK8支持最好，Tomcat 10以上版本对最新JDK的兼容性更友好,但大部分老项目还在用JDK8。 - 确认JAVA_HOME环境变量：在Linux上执行
echo $JAVA_HOME，在Windows上执行echo %JAVA_HOME%，如果输出为空，需要先配置环境变量,否则Tomcat启动脚本会提示找不到Java路径。 - 下载Tomcat：官网下载核心发行版压缩包，Windows用户选.zip格式，Linux用户选.tar.gz格式，解压后目录结构要熟悉，重点记住三个目录：
bin存放启动关闭脚本，conf存放端口和用户配置，webapps就是部署项目的落脚点。
打包Java项目为WAR包
Tomcat直接运行的是打包后的Web应用结构，最常用的打包格式是WAR包，WAR包本质上是一个压缩文件，里面包含项目的class文件、JSP页面、依赖的jar包以及web.xml配置文件。
如果你用Maven管理项目，打包操作很简单,在项目根目录执行：
mvn clean package命令执行完毕后，在target目录下会生成.war文件，如果你用IDEA开发，右侧Maven工具面板里双击package也能达到同样效果。
打包过程中最常见的错误是测试用例失败导致打包中断，可以在打包命令后加-DskipTests跳过测试。
将WAR包放入Tomcat的webapps目录
这一步的操作逻辑很简单：把target目录下的.war文件复制到Tomcat的webapps目录下。
但有几个细节值得留意：
- 停止正在运行的Tomcat：覆盖部署时，如果Tomcat正在运行，最好先执行
shutdown.sh（Linux）或shutdown.bat（Windows）停掉服务，再替换文件,否则可能出现文件被占用或解压不完全的情况。 - WAR包命名决定访问路径：访问一个部署到Tomcat的应用，URL格式是
http://IP:端口/应用名/，应用名默认就是WAR包的文件名，比如你把包命名为blog.war，访问地址就是http://localhost:8080/blog/，想要通过根路径直接访问项目，可以把WAR包改名为ROOT.war。 - WAR包会自动解压：Tomcat启动后会自动解压WAR包，生成一个同名的文件夹，如果解压过程中报错，优先看
logs目录下的日志文件。
springboot项目部署tomcat详细教程：内嵌容器还是外置容器
近几年新项目普遍用SpringBoot开发，部署方式与传统SSH项目有所不同，SpringBoot默认内置了Tomcat，所以涉及一个选择问题,常见的部署方案有两种。
打成WAR包部署到外部Tomcat
这种方式的优点是便于用传统运维手段管理，适合公司内部有统一Tomcat集群环境的情况，操作步骤与上文基本一致,但需要额外修改三处代码：
- 启动类继承
SpringBootServletInitializer并重写configure方法 pom.xml中把spring-boot-starter-tomcat依赖的scope改为provided，避免和外部Tomcat冲突- 打包时使用
war包类型
命令仍然是mvn clean package，生成的WAR包丢进Tomcat的webapps目录即可。
直接用内置Tomcat运行
SpringBoot项目可以用mvn spring-boot:run直接启动，也可以打成JAR包后用java -jar app.jar运行，项目启动时会自动拉起内置的Tomcat服务,不需要单独安装任何容器。
这种方式在DevOps场景和微服务架构中使用更广泛，因为不需要额外维护一套Tomcat环境，部署成本更低，也更容易和Docker、Kubernetes配合使用。
两种部署方式的优劣势对比
| 对比维度 | 外部Tomcat部署 | 内置Tomcat运行 |
|---|---|---|
| 部署步骤 | 需要额外安装配置Tomcat | 直接运行JAR包，步骤简洁 |
| 传统项目兼容性 | 好 | 一般 |
| 运维管理 | 可复用已有Tomcat集群 | 需要重新梳理监控部署方式 |
| 上线速度 | 相对较慢 | 快 |
| 适用场景 | 老项目改造、统一容器管理 | 新项目、微服务架构 |
行业共识认为，如果是新启动的项目，优先考虑内置Tomcat的方式会省去很多运维工作量，也便于后续容器化改造,毕竟多一层Tomcat就多一个需要维护的点。
tomcat部署java项目常见问题排查
实际部署过程中，一次成功的情况其实并不多见，大多数情况是需要反复调试的，把高频问题汇总一下,遇到时按这个顺序排查。
页面报404错误
404是部署最常见的报错，先确认访问的路径是否正确，webapps目录下有没有对应的文件夹或WAR包，再看Tomcat启动日志里有没有报错信息，如果项目引用了额外的依赖jar包，确认它们是否都放在WEB-INF/lib目录下。
启动时报端口被占用
Tomcat默认端口是8080，如果机器上已有其他服务占用了这个端口，启动会直接失败，Linux下用netstat -tlnp | grep 8080查看占用情况，Windows下用netstat -ano | findstr 8080，不想冲突就改Tomcat的conf/server.xml端口配置，把<Connector port="8080"改成其他未被占用的端口。
内存溢出OutOfMemoryError
项目体量较大，或者并发量上来后，Tomcat默认的内存设置可能不够用，报错日志往往会看到java.lang.OutOfMemoryError，解决方法是在Tomcat的bin目录下新建setenv.sh（Linux）或setenv.bat（Windows），写入JVM参数配置,常见组合是：
-Xms512m -Xmx1024m -XX:MaxPermSize=256m调整后重启Tomcat即可生效。
linux服务器部署java项目tomcat的具体操作流程
大多数生产环境跑在Linux服务器上,在这上面部署比Windows多几个步骤需要注意。
先上传WAR包到服务器任意目录,然后执行以下操作：
- 解压或直接移动：执行
mv app.war /opt/tomcat/webapps/ - 给目录配置权限：Tomcat运行用户如果不是root，需要确认webapps目录有读写权限，执行
chown -R tomcat:tomcat /opt/tomcat/ - 启动Tomcat：切到
bin目录，执行./startup.sh - 查看启动日志：用
tail -f ../logs/catalina.out监控启动情况，看到Server startup in字样说明启动成功 - 确认防火墙放行端口：云服务器需要同时在安全组和本机防火墙放通8080或你自定义的端口
有几点容易踩坑，比如直接用root运行Tomcat虽然省事，但不太安全，被攻击后风险更高,建议用专用用户运行。
另一个常见问题是会话保持，如果部署了多个Tomcat节点做负载均衡，需要配置会话共享,否则用户登录状态会在节点间跳转时丢失。
部署方式怎么选：结合项目实际情况做决策
部署这个动作本身没有绝对的标准答案,关键看项目所处的场景。
如果是学习项目或内部演示系统，用WAR包部署到本地Tomcat即可，直观能看到效果,调试也方便。
如果是生产环境老项目，重点考虑平滑升级，每次发版前备份旧的WAR包,发布失败时可以快速回滚。
如果是微服务架构的新项目，跳过外部Tomcat部署,直接打JAR包配合容器平台发布。
不管选哪种方式，发布流程里都应该包含日志检查和回滚预案这两步，发布结束不代表事情做完了，观察几分钟日志和接口监控,确认系统状态正常才算真正完成。
java项目部署tomcat服务器有哪些坑
给新手几条具体的避坑建议：
- WAR包不要用中文命名，Tomcat对特殊字符和中文路径处理容易出问题
- 修改端口号时，确认server.xml中三处端口都改了，除了HTTP连接器端口，还有AJP端口和关闭端口，如果存在冲突，改一遍不如彻底改干净
- webapps下同名文件夹残留会导致新包不生效，覆盖部署时先删除旧解压目录再放新包
- 不要用杀毒软件扫描Tomcat目录，这会造成启动性能下降
部署Java项目到Tomcat之所以让很多人觉得繁琐，核心原因在于把不同环节的知识点混在一起了，把JDK环境、打包方式、目录结构、日志排查这几件事分开理解，整个流程自然脉络清晰，动手做一遍,比看十篇教程更靠谱。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/795174.html
