企业官网建设流程全解析

在Java Web领域干了这么多年，“Tomcat安装配置”这种活儿我闭着眼睛都能做完，但每次帮人排错时我都能发现，一个看似简单的安装配置，能踩的坑比想象中多得多。再过几天就是2026年了，我翻了翻目前网上的教程，要么还停留在Tomcat 7、JDK 1.8的老黄历，要么只说Windows不说Linux，要么启动报错就让你重装，完全没有排查思路。这篇教程我按2026年当前的主流版本环境来写，把整个流程从JDK选型、环境变量、目录结构、核心配置、应用部署到常见问题排查全部串起来，Windows和Linux两个场景都覆盖。适合刚接触Java后端的新手，也适合那些装了好几遍都没跑起来的老哥照着逐步排查。

很多朋友卡住不是因为操作复杂，而是被一个接一个的报错搞懵了。你问别人，别人甩给你一句“环境变量没配好吧”，你也不知道到底哪里有毛病。所以这篇我会把每一步背后的原理也讲清楚，比如为什么JAVA_HOME不能配错、为什么Tomcat 10的包名突然从javax变成jakarta、为什么改了端口还要改关闭端口。知其然也知其所以然，后面遇到问题你才能举一反三。

1. 动手之前：先搞清楚Tomcat在你的系统里扮演什么角色

1.1 Tomcat是什么，它到底替你干了哪些活

Tomcat全称Apache Tomcat，是Apache软件基金会旗下的开源项目，核心价值在于实现了Java Servlet规范和JavaServer Pages（JSP）规范。你的Java后端写出来的是Servlet类或者Spring MVC的Controller，编译之后是class文件，这些文件本身不能直接面对HTTP请求。谁去监听80/8080端口？谁把浏览器发来的HTTP请求解析成Java对象？谁把ServletResponse再写回给浏览器？这些脏活累活都是Tomcat在做。

我用一个开饭店的类比给你解释：你写的Java代码就是厨师，你的浏览器是顾客，Tomcat是饭店的房东兼大堂经理。顾客进来点菜（带着HTTP请求敲门），房东负责接单、安排座位（创建线程来处理这个请求）、把菜单递给后厨（转发给对应的Servlet）、再把做好的菜端上来（返回HTTP响应）。如果没有房东，厨师得自己跑到门口去拉客、迎宾、摆桌、洗碗，这些基础设施你全都要自己写，光一个Socket网络通信就能折腾你几个星期，更不用说Session管理、静态资源映射、并发线程池这些细节。Tomcat把这个底层框架帮你撑起来了，你只需要专注写“炒菜”的逻辑。

还有一层关系也得提前说明：Servlet规范演进了很多版本，Tomcat也跟着升级。默认的解压包自带了一个ROOT应用，里面是Tomcat的欢迎首页，你第一次访问8080端口看到的那个带猫头鹰标志的页面，就是本机的ROOT项目在响应你。这个页面本身就是Tomcat验证安装成功最直观的信号。

1.2 2026年Tomcat版本和JDK版本到底怎么选

打开Tomcat官网，你会发现一堆版本号在陈列架上摆着：11.0.x、10.1.x、9.0.x、8.5.x。每个大版本背后对应不同版本的Servlet规范，也对应不同的JDK最低要求。我整理了一张当前环境下常用的匹配表，你先对照着看：

这里有个大坑，我必须重点说：Tomcat从10.0版本开始，包名从javax.servlet整体迁移到了jakarta.servlet。也就是说，如果你的项目代码里写的是import javax.servlet.http.HttpServlet，这个war包部署到Tomcat 10上，启动时会直接报ClassNotFoundException，应用根本跑不起来。很多老程序员第一次升级到Tomcat 10都会懵，以为是Tomcat装坏了，其实不是，是Servlet API的命名空间搬家了。

所以版本选型的核心原则是：新项目用Tomcat 10.1 + JDK 17，这两个组合在2026年属于最省心的黄金搭档；如果你在维护老业务，老老实实装Tomcat 9.0 + JDK 1.8，不要为了追新把老项目强行迁到Tomcat 10，不然光改import就有得你哭的。JDK 21目前也是长期支持版本，理论上配Tomcat 10.1也没问题，实测稳定。

2. 环境准备：没有JDK，Tomcat就是一具空壳

2.1 安装JDK：Windows和Linux两种姿势

Tomcat本身是Java程序，它运行的前提是系统里有一个能用的JDK或者JRE。虽然Tomcat只需要JRE就能跑，但考虑到大多数人的机器上还要开发Java项目，我建议直接装JDK，一步到位。

Windows环境下，去Oracle官网或者Adoptium（Eclipse Temurin）下载JDK 17的安装包。Windows的安装版是exe，一路下一步就行。这里有一个很多人容易忽视的细节——安装路径。默认路径是C:\Program Files\Java\jdk-17，这个路径里有空格，虽然现在大多数软件能处理，但为了减少无谓的坑，我一般建议手动改到D:\Java\jdk-17这种无空格的纯净路径。

Linux环境下用解压版更干净，不依赖软件包管理器，卸载也简单，直接删目录：

sudo mkdir -p /usr/java sudo tar -zxvf jdk-17_linux-x64_bin.tar.gz -C /usr/java

解压完之后目录是/usr/java/jdk-17.0.x，建议做一个软链接，把版本号抹掉，方便以后升级：

sudo ln -s /usr/java/jdk-17.0.x /usr/java/jdk-17

为什么要这样搞？因为以后你换JDK小版本时，只需要把软链接重新指过去，所有依赖JAVA_HOME=/usr/java/jdk-17的配置都不用动。生产环境里这种小细节能减少很多操作失误。

2.2 JAVA_HOME与PATH环境变量配置：Tomcat启动的命门

装完JDK，接下来是决定成败的一步：环境变量。Tomcat启动脚本会优先读取JAVA_HOME环境变量来定位java命令，如果你只配了PATH没配JAVA_HOME，Tomcat会提示找不到JVM或者JRE环境。

Windows下操作路径：此电脑 → 属性 → 高级系统设置 → 环境变量。在“系统变量”区域点击“新建”，变量名填JAVA_HOME，变量值填JDK的根目录路径，比如D:\Java\jdk-17。注意，一定是根目录，不是bin目录。然后找到Path变量，点编辑，新增一行%JAVA_HOME%\bin。

这里有三个关键心得：

• 在Path里永远使用%JAVA_HOME%\bin这种引用方式，不要直接写死D:\Java\jdk-17\bin。这样你以后升级JDK，只改JAVA_HOME一个变量就够了。
• 改完环境变量后，已经打开的cmd窗口不会自动刷新，必须重开一个新的命令行窗口测试。
• 配置完成后验证：运行java -version，会看到类似“openjdk version 17.0.x”的输出。同时echo %JAVA_HOME%确认变量有值。

Linux下的配置方法略有不同，编辑/etc/profile或者用户级的~/.bashrc：

export JAVA_HOME=/usr/java/jdk-17 export PATH=$JAVA_HOME/bin:$PATH

保存后执行source /etc/profile让它生效。验证方式和Windows一致。

这里分享一个我自己踩过的经典坑：java -version在命令行里明明能执行，但启动Tomcat一直报“The JRE_HOME environment variable is not defined correctly”。为什么？因为当时我只把JDK的bin目录加到了PATH，没有设置JAVA_HOME。Tomcat的startup.bat脚本走的是另一套逻辑，它不看PATH里面的java，它只看JAVA_HOME这个变量。所以各位一定记住：JAVA_HOME必须单独设置，这跟PATH是两码事。

3. Tomcat本体安装与目录结构解读

3.1 下载与解压：注意别下错了安装包

Tomcat官网的下载页面有几个选项，新手容易手滑。核心下载区域有两类：

• Binary Distributions - Core：里面有zip（Windows）、tar.gz（Linux）、以及Windows Service Installer（exe安装版）。
• 如果你只是本地开发或者学习，选zip或者tar.gz就对了。exe那个是把Tomcat做成Windows服务的安装器，适合生产环境长期运行服务，但新手用它容易把路径搞得乱七八糟，而且卸载不干净。

我推荐下载“Core”分类下的zip包，解压即用，不写入注册表，关机重启也不会有残留进程，对学习和测试阶段来说最干净。

解压后第一件事，把整个目录挪到一个纯英文路径下。Windows下我一般放在D:\apache-tomcat-10.1.27，Linux下放在/opt/tomcat。千万不要把Tomcat放在带中文或者空格的目录里，比如“C:\Program Files\Apache Tomcat”这种，启动脚本在解析路径时碰到空格会出一堆莫名其妙的错误。我当时第一次安装就是图省事直接解压在桌面上的文件夹里，结果双击startup.bat直接闪退，换了好几个版本都一样，最后才发现是路径的锅。

3.2 目录结构：哪几个目录是你调试时要盯的

解压完你会看到一堆文件夹，很多新手对每个目录一脸懵，出了错也不知道去哪查。我给你梳理一下：

这里我特别想强调logs目录的价值。很多帖子只教你双击startup.bat，然后看窗口输出，但窗口一关信息就没了，而且出错信息可能被截断。真正专业的排查路径是打开logs/catalina.out和logs/localhost.日期.log，里面记录了完整堆栈。比如端口被占用，日志里会写“Port 8080 was already in use”；部署失败，日志里会写完整的ClassNotFound异常。不管你现在遇到什么报错，养成“先翻日志再百度”的习惯，能省至少一半的时间。

3.3 启动与访问验证：看到猫头鹰页面才算成功

Windows下进入bin目录，双击startup.bat，会弹出一个控制台窗口。如果配置无误，窗口里会出现类似“Server startup in [xxx] milliseconds”的提示。Linux下执行：

/opt/tomcat/bin/startup.sh

然后打开浏览器访问http://localhost:8080/。如果看到带有Apache Tomcat字样的默认欢迎页（新版本是一只橙色的小猫标志，旁边写着版本号），说明Tomcat已经成功跑起来了。

如果访问不到，先不要慌，按这个顺序排查：第一，Telnet或者curl一下8080端口，确定端口是不是真的在监听；第二，看一眼logs/catalina.out，看是不是端口被占；第三，确认服务器防火墙有没有放行8080。我遇到过太多次“Tomcat明明起来了但浏览器打不开”的情况，最后发现是云服务器的安全组策略没放行8080端口，跟Tomcat本身半毛钱关系都没有。

4. 核心配置精讲：让Tomcat按照你的节奏工作

4.1 server.xml三大核心端口：8080、8005与8009

conf/server.xml是整个Tomcat配置文件里最核心的一份，里面定义了连接器、主机、上下文的行为。新手至少要认识这三个端口：

• 8080：HTTP连接器端口，也就是浏览器访问Tomcat的入口。
• 8005：关闭Tomcat的专用端口。执行shutdown.sh时，脚本会向这个端口发送特定指令来优雅停机。
• 8009：AJP协议连接器端口，用于和Apache HTTP Server或Nginx配合时进行二进制协议通信。现在前后端分离架构已经普及，AJP用得越来越少，但端口还在。

对应到server.xml里，HTTP连接器的配置长这样：

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

为什么你必须了解这三个端口？因为当你在同一台机器上部署两个Tomcat实例时，比如测试环境和预发布环境共存，三个端口全都不能跟另一个实例重复，否则第二个Tomcat根本启动不起来。我给大家一套在生产环境验证过的端口规划方案：

改完端口之后重启Tomcat生效。这里要提醒的是：如果改了HTTP端口，记得把防火墙和云安全组也同步放行，不然后端服务之间互相调不通。我见过有人改了8080到18080，但Nginx代理还指着8080，线上接口挂了一整天才发现。

4.2 乱码问题：不是编码的锅，是控制台和URI的锅

Tomcat的乱码问题，可能是让中文开发者最头疼的一环。它其实分两种场景，很多人混为一谈：

场景一：启动日志中文乱码。Tomcat的日志输出默认使用UTF-8编码，而Windows中文系统的命令行窗口默认用的是GBK（代码页936），两边编码不一致，中文就打成了乱码。解决方案是修改conf/logging.properties：

java.util.logging.ConsoleHandler.encoding = GBK

改完重启Tomcat，控制台的中文日志就正常了。这个方案在中文Windows上实测有效。如果你用的是新版Windows Terminal或者IDEA自带的Terminal，默认已经是UTF-8，那就不用改，保持默认即可。

场景二：URL传递中文参数乱码。浏览器访问http://localhost:8080/myweb/search?keyword=中文，服务器端拿到的却是乱码，这属于URI编码问题。在Tomcat 7及更早的版本上需要手动在server.xml的Connector上加URIEncoding="UTF-8"；从Tomcat 8.0开始，Connector默认的URIEncoding就是UTF-8，所以这个问题在新版Tomcat上很少出现。如果你在维护老项目，记得检查这一项。

经验补充：部署在Linux服务器上的Tomcat，如果JSP页面是GBK编码而服务器系统是UTF-8，也会出现乱码。这种跟Tomcat本身没关系，是代码文件编码与页面声明编码不匹配导致的，排查时要先分清HTTP层编码还是文件层编码。

4.3 JVM内存参数调优：给Tomcat留足口粮

默认情况下，Tomcat启动时JVM使用的堆内存初始值和最大值都比较保守，一旦部署的应用稍大或者并发上来，很容易报java.lang.OutOfMemoryError: Java heap space。

调优的方式是修改JVM启动参数。Windows下编辑bin/catalina.bat，在文件开头加：

set "JAVA_OPTS=-Xms512m -Xmx1024m"

Linux下编辑bin/catalina.sh，同样在文件开头加：

JAVA_OPTS="-Xms512m -Xmx1024m"

参数含义解读：

• -Xms：堆内存初始值，应用启动时就分配这么多。
• -Xmx：堆内存最大值，应用最多能申请到这么多。
• 建议把-Xms和-Xmx设为相同值。因为如果初始值和最大值不同，JVM运行过程中需要不断调整堆的大小，触发full GC的频率会变高，对性能反而有影响。直接相同，内存一步到位。

关于设多大，我给的参考建议是：独立服务器物理内存4G，给Tomcat分2G堆；物理内存8G，给Tomcat分4G堆。不要超过物理内存的60%，因为操作系统、数据库、中间件都需要内存，全塞给JVM会让整机性能反而下降。我见过一个案例，运维把Xmx直接设成了8G，物理内存只有16G，系统swap开始疯狂写盘，最后应用比原来更卡。

5. Web项目部署全流程：从war包到IDE可视化部署

5.1 最简单的war包部署：扔进webapps就完事

本地开发完成后，把你的项目打成war包（IDEA里Build -> Build Artifacts -> Build，或者Maven执行package命令），得到一个类似myweb.war的文件。把这个文件复制到Tomcat的webapps目录下，重启Tomcat。

启动时Tomcat会自动解压war包，生成一个和war包同名的目录myweb/。浏览器访问：

http://localhost:8080/myweb/

就能看到你的应用首页。

注意几个细节：

• 访问路径和war包名严格一致。war包叫demo.war，访问就是/demo/；叫myweb.war，就是/myweb/。如果不想带路径，直接把war包改名为ROOT.war，替换掉webapps下的ROOT目录，访问http://localhost:8080/就能直达。
• war包文件名建议全小写。Linux系统下路径大小写敏感，MyWeb.war部署后的访问路径是/MyWeb/，突然某天你访问/myweb/就会404，这种问题排查起来特别隐蔽。
• webapps下已经存在同名目录时，重启Tomcat会覆盖还是合并？实际行为是：如果war包比同名目录新，Tomcat会重新解压覆盖。如果你改了代码重新打包，直接覆盖war包再重启就行，不用手动删目录。

5.2 外部目录部署：项目文件不放进webapps可以吗

很多正规的生产环境不会把项目文件真的扔进webapps里，因为webapps属于Tomcat安装目录，Tomcat一升级整个目录可能被替换。更规范的做法是让项目文件存放到独立的数据目录，通过配置指向它。

有两种做法：

做法一：修改server.xml，在 标签内加一个 ：

<Context path="/myweb" docBase="/data/webapp/myweb" reloadable="true" />

做法二（更推荐）：在conf/Catalina/localhost目录下新建一个XML文件，文件名就是你的访问路径前缀。比如创建conf/Catalina/localhost/myweb.xml，内容：

<Context docBase="/data/webapp/myweb" reloadable="true" />

浏览器访问http://localhost:8080/myweb/就能映射到/data/webapp/myweb这个外部目录。这种方式的好处是：不用重启Tomcat，放置XML文件后Tomcat会自动加载新应用；删除XML文件就能卸载应用，完全不用动war包。

这里有一个必须强调的点：docBase指向的目录，必须是包含WEB-INF的那个应用根目录。比如你的项目结构是/data/webapp/myweb/WEB-INF/classes，那么docBase就写/data/webapp/myweb，千万别写到/data/webapp/myweb/WEB-INF这一层。

5.3 IDEA中配置Tomcat：本地开发调试一步到位

很多新手虽然能用war包部署，但每次改点代码都要重新打包，效率极低。在IDEA里配置Tomcat可以把这个过程压缩到“改代码-刷新页面”两步。

IDEA配置Tomcat的完整步骤：

1. 打开IDEA，进入Run菜单 -> Edit Configurations。
2. 点击左上角“+”号，找到Tomcat Server -> Local。
3. 在Application Server一栏点击Configure，选择你的Tomcat安装目录。
4. 切到Deployment选项卡，点击“+”号，选择Artifact，选中你的Web项目（一般会有war和war exploded两种格式，选war exploded）。
5. 在下方的Application context设置访问路径，比如填/myweb。
6. 点击Apply，然后点击右上角的启动按钮。

配置好之后，IDEA会启动Tomcat并自动部署项目，浏览器会自动打开你的项目首页。war exploded模式表示IDEA展开部署，你修改了JSP页面后，通过Ctrl+F10或直接刷新页面就能看到效果，不用重启Tomcat。

这里有个高频报错：启动后访问页面，浏览器提示“源服务器未能找到目标资源的表示”。这是Tomcat返回的HTTP 404标准描述，别去翻Tomcat日志了，基本上就是Application context没配对。你把Deployment里的Application context改成和你的访问路径一致，比如都改成/myweb，问题立刻消失。还有一种情况是你部署名写的是/，却访问/myweb，照样404。

6. Linux环境部署与开机自启动

6.1 Linux部署的特殊坑：用root跑Tomcat是真勇

Linux服务器上部署Tomcat，和Windows最大区别在于权限管理和服务管理。很多新手图省事，直接用root账号下载、解压、启动Tomcat，这样不是不行，但非常不推荐。一旦Tomcat应用被入侵，攻击者拿到的是root权限，整台服务器就沦陷了。正确姿势是创建一个专用系统用户来运行Tomcat：

sudo useradd -r -s /bin/false tomcat sudo chown -R tomcat:tomcat /opt/tomcat sudo -u tomcat /opt/tomcat/bin/startup.sh

useradd的-r参数表示创建系统账号，-s /bin/false表示禁止这个用户登录交互式shell，只是给Tomcat进程一个运行身份。然后通过sudo -u tomcat指定以tomcat用户身份执行启动脚本。

在使用chown分配目录权限时，有一个权限最小化的技巧：Tomcat运行需要写权限的是logs、temp、work这3个目录，webapps如果需要热部署也必须有写权限。而conf目录建议只读，防止应用被攻击后篡改配置。

Linux下查看Tomcat是否启动成功，除了访问8080端口，更靠谱的方法是看进程和日志：

ps -ef | grep tomcat tail -f /opt/tomcat/logs/catalina.out

注意是catalina.out，不是catalina.sh。这个.out文件记录了Tomcat控制台的所有输出，出错排障全在它身上。

6.2 systemd管理Tomcat：开机自启动与异常自动拉起

服务器重启之后手动启动Tomcat，偶尔犯懒忘记，服务就瘫了。生产环境里，Tomcat开机自启动是基本要求。最推荐的方式是搭配systemd编写服务文件。

新建/etc/systemd/system/tomcat.service，内容如下：

[Unit] Description=Apache Tomcat Web Application Container After=network.target [Service] Type=forking User=tomcat Group=tomcat Environment="JAVA_HOME=/usr/java/jdk-17" Environment="CATALINA_HOME=/opt/tomcat" Environment="CATALINA_BASE=/opt/tomcat" ExecStart=/opt/tomcat/bin/startup.sh ExecStop=/opt/tomcat/bin/shutdown.sh Restart=on-failure [Install] WantedBy=multi-user.target

然后执行：

systemctl daemon-reload systemctl start tomcat systemctl enable tomcat systemctl status tomcat

之后Tomcat就会随系统开机自动启动，而且一旦进程异常退出，systemd会自动把它重新拉起来。

这里有一个非常容易踩的坑：Type=forking和Type=simple的选择。startup.sh脚本启动完Tomcat进程后会立即返回，真正的Tomcat进程是fork出来的后台进程。所以Type必须写成forking，告诉systemd“脚本执行完不算完，还有子进程在跑”。如果你写成simple，systemd会认为主进程就是startup.sh，一旦脚本结束了，systemd就把整个服务判定为退出了，Tomcat刚起来就被系统杀掉。

ExecStop用shutdown.sh而不是直接用systemctl stop，这个细节也很关键。shutdown.sh向8005端口发送关闭指令，走的是正常停机流程，会等待正在处理的请求完成并释放资源。强制stop相当于直接kill，可能造成正在处理中的数据丢失。

7. 常见问题排查实录：从端口占用到404再到乱码

7.1 端口占用：8080起不来的第一元凶

症状表现：启动Tomcat时，控制台或catalina.out报错“Port 8080 was already in use”或“Address already in use: JVM_Bind”。解决方法和后端同学撞端口对不上，有很大概率是本机之前启动的Tomcat没关干净，或者Nginx、Spring Boot等程序占用了8080。

排查步骤：

Windows系统：

netstat -ano | findstr :8080

拿到最后一列的PID后：

taskkill /PID 进程号 /F

Linux系统：

lsof -i:8080

拿到PID后：

kill -9 进程号

但这里我反而建议大家想一下：如果8080经常被占，与其每次都去杀进程，不如把Tomcat端口改到18080之类的非知名端口。一是避开系统中其他软件默认抢占8080的高频冲突，二是很多扫描工具和攻击脚本默认优先扫8080，换掉端口本身就多了一层安全防护。

7.2 404与“源服务器未能找到目标资源的表示”

这个报错是Tomcat 9之后对HTTP 404状态码的标准描述，本质上就是没有找到对应的资源。我把它高频出现的三个原因帮你拆掉：

• 路径没对上：最典型的是war包叫myweb.war，Tomcat解压出来的context path是/myweb，你却访问http://localhost:8080/，当然404。
• 应用没部署成功：登录Tomcat管理界面看到应用列表为空，或者logs/localhost.日期.log里面有一堆红色Error。这种情况先看错误堆栈，再决定是不是要清掉webapps下的同名目录重新解压。
• 编译产物缺失：IDEA部署war exploded时，有时候classes目录是空的，页面能启动但访问直接404。去target目录看一眼，class文件是否存在，不存在就重新Build Project。

入口文件被删了也会造成404，但这类问题更隐蔽，一般要结合日志来分析。

7.3 双击startup.bat一闪而过，根本看不到报错

Windows上双击启动脚本时窗口闪退，这是让无数新手劝退的经典场景。闪退的本质是脚本执行到一半出错了，但窗口直接被关闭，错误信息你看不到。

解决方案：打开cmd命令行窗口，先cd到Tomcat的bin目录，再手动执行startup.bat：

cd D:\apache-tomcat-10.1.27\bin startup.bat

这样错误信息就会留在cmd窗口里，不会一闪而过。常见的隐藏原因是系统找不到java命令，也就是JAVA_HOME没有配置好。此时窗口会提示“The JAVA_HOME environment variable is not defined correctly”，回到2.2重新检查环境变量即可。

如果改完环境变量还是闪退，检验一下你改环境变量后有没有重启cmd窗口。Windows的环境变量刷新机制是只对新开的进程生效，老窗口里还是旧值。很多新手的“配置了没用”其实就是因为这个。

7.4 内存溢出：OutOfMemoryError处理手册

日志里出现java.lang.OutOfMemoryError: Java heap space，说明堆内存不够，按4.3节的参数调整JAVA_OPTS即可。但有一个进阶问题：你改了catalina.sh里的JAVA_OPTS，重启后却没生效，为什么？

大概率是你改错了位置。catalina.sh文件里，前面的注释段落里也有一串类似JAVA_OPTS="$JAVA_OPTS -Xms..."的示例，但那是注释掉的。真正的生效位置在文件前部设置项，不要在注释区里加内容。Windows的catalina.bat同理。

如果日志里报的是java.lang.OutOfMemoryError: PermGen space，那是JDK 7及更早版本的元空间问题，需要加-XX:MaxPermSize=256m。JDK 8之后PermGen被Metaspace取代，不会再有这个报错。

如果报的是java.lang.OutOfMemoryError: Metaspace，说明元空间不够，加-XX:MaxMetaspaceSize=256m。

7.5 JSP编译失败与页面中文乱码

访问JSP页面时报“Unable to compile class for JSP”，大概率是JSP语法错误或者lib下的jar包冲突。这类问题本地开发时可能不报错，部署到Linux上才报，多数是本地和服务器JDK版本不一致导致的。排查时打开logs目录下的localhost日志，翻到最后会看到具体是哪一行JSP代码编译失败，直接定位。

JSP页面呈现乱码，先是看页面开头的charset声明：

<%@ page contentType="text/html;charset=UTF-8" language="java" %>

如果页面本身是UTF-8而声明是GBK，或者Tomcat请求参数编码不是UTF-8，都会出现乱码。还有一个容易被忽略的点：如果你在Linux上编辑JSP文件用的是echo命令或者vi默认配置，文件编码可能和声明的编码不一致，用file命令查文件编码，不一致就统一转成UTF-8。

7.6 Tomcat日志轮转：日志文件太大撑爆磁盘

这个坑可能只有跑过线上的人才会遇到。Tomcat的catalina.out默认不会自动切割，跑几个月下来能到几十个G，把磁盘撑爆，然后Tomcat假死。在生产环境里一定要配置日志切割。

Linux上用logrotate来做最简单。新建/etc/logrotate.d/tomcat：

/opt/tomcat/logs/catalina.out { daily rotate 30 compress missingok copytruncate }

daily表示每天切割，rotate 30表示保留30天，compress开启压缩，copytruncate是关键——它先复制文件再清空原文件，不影响Tomcat的日志句柄。如果没有copytruncate，logrotate会直接重命名文件，Tomcat还会往旧文件名里写，日志就丢了。

Windows环境下，一般配合计划任务定期清理或者用第三方工具切割，这里篇幅有限不展开。

写在最后的经验之谈

我这些年和Tomcat打交道下来，最深的一个体会是：Tomcat本身并不复杂，真正折磨人的是所有“你以为对了但其实没对”的细节。比如JAVA_HOME配到了bin目录、war包名和context path不一致、改了端口却忘了放行防火墙、Type写成simple导致systemd反复重启。这些问题单独看都很小，但串联起来就能耗掉人半天时间。

如果你要我把这篇教程浓缩成三句话，我会说：第一，先补环境再谈部署，JDK版本和Tomcat版本一定要匹配；第二，报错了先看logs目录下的catalina.out和localhost日志，别猜；第三，把常见坑背下来，路径不带空格、端口不冲突、文件编码统一，这三条能规避掉日常80%的幺蛾子。

最后再分享一个小技巧：部署完项目之后，先用curl而不是浏览器验证，这样能排除浏览器缓存干扰。比如curl http://localhost:8080/myweb/，返回HTTP状态码200，你的应用访问链路基本没问题；如果404，再回到第7节的排查流程。这个习惯我用到现在，不管是本地调试还是线上排查，都比打开浏览器再刷新快得多。