企业官网建设流程全解析

做Java Web这行，Tomcat是你迟早要亲手部署一遍的东西。哪怕2024年容器化已经这么普遍，Spring Boot内嵌Tomcat，老项目独立Tomcat，这些场景凑到一起，你依然绕不开这几个问题：Tomcat从哪里下载才不会下到坑货，JDK版本和Tomcat版本怎么配对，server.xml里那些参数到底改什么，以及为什么启动没反应、访问全是404。网上讲Tomcat的文章不少，但太多还停留在Tomcat 8那套旧逻辑，放到2024年的环境里照着做反而容易翻车。这篇文章我按照自己实际部署和维护项目的经验，把Tomcat的下载、安装、配置从选型到排障完整过一遍，版本匹配、Windows和Linux两套安装方式、核心配置、JVM调优、安全加固这些都会聊到，争取给你一份能直接照抄的参考。

1. 版本选型：2024年别再下错Tomcat了

Tomcat的下载页面打开之后，第一眼就是一堆目录名，8.5.x、9.0.x、10.1.x、11.0.x摆在一起，很多新手直接懵掉。其实选版本的核心逻辑并不复杂，就看两件事：你的应用是老的javax命名空间还是新的jakarta命名空间，以及你的JDK版本是什么。

1.1 javax与jakarta：版本切换背后的最大坑

Tomcat从10.0版本开始，Servlet API的包名从javax.servlet整体迁移到了jakarta.servlet。这个变更不是简单的改个名，而是Java EE移交Eclipse基金会之后，Oracle不允许继续用javax商标，只能换成jakarta。对于开发者的直接后果就是：你在Tomcat 9能正常跑的war包，放到Tomcat 10里大概率报ClassNotFoundException: javax.servlet.Filter之类的错误，因为整个Servlet、JSP相关类路径全部变了。

所以选版本之前一定要确认自己项目的技术栈。如果你的项目还在用Spring Boot 2.x，老一套JSP + Servlet写业务，包名全是javax开头，那就老老实实上Tomcat 9.0.x，别赶时髦去下载10.x。反过来，如果你的项目是Spring Boot 3.x，或者新工程从一开始就用jakarta命名空间，直接选Tomcat 10.1.x。这一步选错了，后面所有配置都是白折腾。

1.2 生命周期、JDK要求与选择建议

Tomcat的官方版本配套表格写得很清楚，我这里结合实际使用情况给你一个简化版参考：

Tomcat 11.0.x在2024年已经进入稳定周期，但我不建议你在生产环境里抢鲜。原因很实在：Tomcat 11需要JDK 17打底，很多企业服务器上的JDK还停在8或者11，升级成本不是Tomcat单方面能决定的。而且生态里的不少第三方库、监控组件对Tomcat 11的适配还在磨合期，没必要用生产环境当小白鼠。Tomcat 10.1.x是当下最稳的长期版本，生命周期和社区活跃度都有保障，新项目闭眼选它基本没错。

另外提醒一句：官网给出的下载列表里有RC版、Alpha版这类预览版本，文件名里通常带-RC或者版本号后面有alpha字样。这些是给社区测试用的，生产环境装预览版等于给自己埋定时炸弹，看到这些字样的目录直接跳过。

1.3 不同环境的版本管理思路

开发、测试、生产三套环境的Tomcat版本，我的建议是保持完全一致，至少大版本必须一致。你开发机上用10.1.20，测试环境却是9.0.80，开发时页面一切正常，一上测试环境就报Servlet版本不兼容，这种问题排查起来极其痛苦。版本不一致导致的诡异问题，比端口冲突和内存不足更难定位，因为报错信息往往指向业务代码，但根因在容器版本差异上。

从项目实践角度，推荐的做法是把Tomcat版本和JDK版本一起锁进部署文档或者脚本里，比如固定为"Tomcat 10.1.26 + JDK 17"，每次环境搭建都按这个组合来。等哪天需要升级，先在一台测试机上做完整回归，再逐步推。

2. 下载：从官方渠道拿到靠谱安装包

很多人习惯在搜索引擎里搜"Tomcat下载"，点进去却是一堆捆绑了推广软件或者旧版本的第三方站点。Tomcat这种基础中间件，安装包被动手脚的后果可能是生产事故级别的，所以下载这步我建议只认官方。

2.1 官网入口与文件目录怎么看

Apache Tomcat的官网是tomcat.apache.org，页面上有Download区，会根据你的选择进入对应版本的下载子目录。以Tomcat 10.1.x为例，下载目录结构大致是这样的：/download-10.cgi是下载页导航，真正的安装包在/dist/tomcat/tomcat-10/v10.1.26/bin/这种路径下面。

下载目录里会有很多文件，每一行对应一个安装包，需要看清楚的字段包括：文件名、大小、Checksums校验文件、PGP签名文件。版本号目录里的文件新旧也会随着维护更新，比如10.1.24是旧版，10.1.26是当前修订版，建议下载最新修订版，安全修复通常只打到最新版本上。

国内直接访问Apache官网下载，速度有时候不太理想。这时候可以找高校或者云厂商提供的开源镜像站，搜"Tomcat镜像"就能找到一堆，从镜像站下载时注意选择和官网相同的版本目录，文件名不要拿错。镜像站一般每小时同步一次，如果官网刚发布新版本，镜像还没刷出来，等一两个小时再刷新就行。

2.2 安装包类型与场景选择

bin目录下常见的安装包文件类型有这么几类：

• apache-tomcat-10.1.26-windows-x64.zip：Windows解压版，解压即用，开发调试首选。
• apache-tomcat-10.1.26.tar.gz：Linux/macOS解压版，也是生产环境最常用的。
• apache-tomcat-10.1.26.exe：Windows服务安装版，以系统服务方式运行，集成到Windows服务管理器里。
• apache-tomcat-10.1.26-src.tar.gz：源码包，只有需要定制Tomcat时才会用到，绝大多数人不用下。
• 各种-deployer包：配合Maven等构建工具的部署器，一般也用不上。

我自己的使用习惯是：Windows开发调试用zip解压版，Linux生产用tar.gz，Windows服务器生产环境才考虑exe服务版。不推荐用exe服务版做开发，因为服务方式运行后，日志输出和文件权限都跟普通进程不太一样，排查问题反而多一层麻烦。

2.3 下载后校验哈希，避免坏包

安装包下载完第一时间校验哈希，这个习惯我会建议每个人都养成。下载目录里跟安装包同名但以.sha512结尾的文件，就是官方发布的SHA-512校验值，用本地计算出的值跟它对一下，能确认文件没有在传输过程中损坏或被篡改。

Windows上校验命令用自带的certutil：

certutil -hashfile apache-tomcat-10.1.26-windows-x64.zip SHA512

Linux上用sha512sum：

sha512sum apache-tomcat-10.1.26.tar.gz

把输出的一长串十六进制值和官方.sha512文件里的内容对比，一致就说明包没问题。这一步几十秒钟的事，能省掉后面"解压到一半报错""启动莫名其妙缺文件"这些恶心问题。

3. 安装与目录结构：Windows和Linux各来一遍

安装Tomcat本身不难，难的是装完之后能不能顺利跑起来，以及跑起来之后能不能按你的预期被管理。Windows和Linux两条路线，姿势不太一样。

3.1 Windows解压版安装与验证

Windows上最省事的流程：把apache-tomcat-10.1.26-windows-x64.zip解压到指定目录，比如D:\dev\apache-tomcat-10.1.26。这里有个小注意点：尽量不要把目录放进路径带空格的地方，比如C:\Program Files\Tomcat这种，虽然Tomcat官方支持带空格的路径，但后续一些脚本命令、IDE集成、批处理调试的时候，空格经常引发各种莫名问题，不如一开始就避开。

解压后要做两件事：确认JDK已安装，并配置好JAVA_HOME环境变量。然后双击bin\startup.bat，启动后浏览器访问http://localhost:8080/，能看到默认的猫首页就说明装好了。

不过双击启动有个麻烦：窗口突然闪一下就消失，你根本看不到报错信息。正确的验证姿势是在命令行窗口里手动执行：

cd D:\dev\apache-tomcat-10.1.26\bin catalina.bat run

这样Tomcat以前台方式启动，日志直接打在控制台里，启动报什么错一目了然。调试阶段用这个方式，确认没问题之后再用startup.bat后台启动。

3.2 Linux的规范安装：专用用户与systemd

Linux生产环境我推荐的规范流程是这样：把tar.gz包解压到/opt/tomcat，创建一个专用运行用户tomcat，把目录属主改给tomcat，然后用systemd托管进程。为什么要单独建用户跑Tomcat？安全是第一位的。Tomcat一旦被攻破，如果进程是root启动的，攻击者直接拿到整台机器的权限；用低权限专用用户运行，至少能把损失控制在一个范围内。

具体命令流程：

sudo useradd -r -s /bin/false tomcat sudo mkdir -p /opt/tomcat sudo tar -xzf apache-tomcat-10.1.26.tar.gz -C /opt/tomcat sudo ln -s /opt/tomcat/apache-tomcat-10.1.26 /opt/tomcat/current sudo chown -R tomcat:tomcat /opt/tomcat

然后写systemd服务文件/etc/systemd/system/tomcat.service：

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

写完之后systemctl daemon-reload，再systemctl enable --now tomcat。这套方案的好处是：开机自启、崩溃自动拉起、用systemctl status tomcat和journalctl -u tomcat查看状态和日志，运维体验比裸跑startup.sh强太多。

3.3 目录结构与环境变量解读

装完之后，Tomcat的根目录下有几个子目录，是排查问题时的主要战场：

• bin：启动关闭脚本。startup.sh、shutdown.sh、catalina.sh都在这里。
• conf：核心配置文件。server.xml、web.xml、context.xml、tomcat-users.xml都在这里。
• lib：Tomcat自身以及应用共享的jar包。数据库驱动这类公共依赖通常扔这里。
• logs：日志目录。catalina.out是主输出文件，localhost_access_log是访问日志。
• webapps：应用部署目录。war包扔到这里就能自动部署。
• work：JSP编译后的class缓存目录。页面改了不生效，有时删这个目录就能解决。
• temp：临时文件目录。

Tomcat脚本运行依赖两个环境变量：JAVA_HOME指定JDK安装位置，CATALINA_HOME指定Tomcat根目录。Linux上还可以用CATALINA_BASE来指定实例配置目录，实现一份二进制多实例运行，后面讲多实例部署时再展开。JAVA_HOME不配或者配错，最常见的报错就是脚本找不到java命令，或者在老版本上直接弹"Unable to find a Java SDK"之类的提示。

4. 核心配置文件server.xml详解

server.xml是Tomcat的主配置文件，里面是Server、Service、Connector、Engine、Host、Context这些嵌套元素。看不懂这个文件，等于只学会了启动Tomcat，还没学会怎么用它。

4.1 三层结构：Connector、Engine与Host

server.xml核心骨架默认长这样：

<Server port="8005" shutdown="SHUTDOWN"> <Service name="Catalina"> <Connector port="8080" protocol="HTTP/1.1" connectionTimeout="20000" redirectPort="8443" /> <Engine name="Catalina" defaultHost="localhost"> <Host name="localhost" appBase="webapps" unpackWARs="true" autoDeploy="true" /> </Engine> </Service> </Server>

我来拆一下这个结构：Server代表整个Tomcat实例，port="8005"是关闭端口，shutdown="SHUTDOWN"是关闭指令字符串；Service把连接器和引擎绑到一起；Connector就是用来接收外部请求的网络端口组件；Engine是Servlet处理引擎，往下管理虚拟主机Host；Host对应一个虚拟主机，appBase指定这个主机下应用默认放在哪个目录。

一次请求的路径大致是：浏览器请求到达Connector，Connector把请求交给内部的线程池处理，转到Engine，Engine根据请求的域名匹配Host，Host再根据URL路径匹配Context应用，最后路由到具体的Servlet。理清这条链路，很多配置问题就能自己推导出来了。

4.2 端口规划与AJP禁用

Tomcat默认监听三个端口：8080是HTTP访问端口，8005是关闭端口，8009是AJP端口。AJP是Apache前端与Tomcat通信的专用协议，在Tomcat 9之后默认配置里已经不再激活。如果你没有明确使用Apache对接AJP的需求，就让这个端口保持禁用状态，多暴露一个协议端口就多一个攻击面。

从安全角度再补一句：8005关闭端口在生产环境建议改掉默认值，比如改成port="-1"，让Tomcat完全禁用通过端口发送关闭指令的能力。关闭指令本身还需要匹配shutdown字符串，但如果Tomcat所在网络被访问到8005，攻击者尝试发送SHUTDOWN字符串依然有一定风险。要么用防火墙把8005挡在内网，要么直接关掉。

4.3 Host、Context与应用部署方式

Host元素里，appBase指定应用目录，默认是webapps。你把一个名为demo.war的包扔进webapps，Tomcat会自动创建一个名为demo的Context，访问路径就是http://localhost:8080/demo/。如果你希望应用直接通过根路径访问，也就是http://localhost:8080/，那就把war包改名为ROOT.war再扔进去，同时清理掉webapps下原来的ROOT目录。

unpackWARs和autoDeploy这两个属性值得理解：unpackWARs="true"表示把war包解压成目录再运行，false则直接从war包运行；autoDeploy="true"表示启动后持续扫描appBase，检测到新增或更新的war包就自动部署。生产环境如果希望完全手工控制部署时机，可以把autoDeploy改为false，需要发布时通过Manager页面或脚本手动reload。

还有一种常见需求：应用代码和Tomcat目录不想耦合在一起。比如应用放在/data/apps/demo，这时不用复制到webapps，直接改Host元素里加一个Context：

<Host name="localhost" appBase="webapps"> <Context path="" docBase="/data/apps/demo" reloadable="false" /> </Host>

path为空表示根路径，docBase指向外部目录。这种部署方式在发版系统里很常见，更新代码不用往Tomcat目录里复制文件，直接把新版本切到docBase路径就行。

5. JVM参数与连接器调优

Tomcat跑得动和跑得快，中间隔着一层JVM调优。很多性能问题不是应用代码慢，而是堆内存没给够、线程池参数不合理。

5.1 用setenv.sh统一管理JVM参数

Tomcat启动时会加载bin/catalina.sh，在这个脚本里可以找到JAVA_OPTS的引用位置。直接把JAVA_OPTS写进catalina.sh是最省事的做法，但不推荐：每次升级Tomcat覆盖整个bin目录时，你的自定义参数就丢了。更规范的做法是在CATALINA_BASE的bin目录下放一个setenv.sh，Tomcat启动时如果发现这个文件会自动加载它，既不影响主脚本，又方便版本管理。

Linux/Win下分别创建bin/setenv.sh或bin\setenv.bat，内容大致如下：

export JAVA_HOME=/usr/local/jdk-17 export CATALINA_OPTS="-Xms1024m -Xmx1024m -XX:MaxMetaspaceSize=256m -Dfile.encoding=UTF-8"

这里说明一下，CATALINA_OPTS只作用于Tomcat自身进程，而JAVA_OPTS除了Tomcat进程，还会被脚本里的其他工具继承。所以专门给Tomcat进程设参数，用CATALINA_OPTS更精准。

内存参数的选择逻辑：-Xms和-Xmx最好设置成相同值，避免启动后堆内存反复扩容收缩带来的性能抖动。设置多大要看你的应用负载，这不是拍脑袋定的，建议先压在测试环境跑一段时间压测，观察JVM曲线后确定。一般8G内存的服务器，给Tomcat分2G到4G堆比较常见，再高要考虑宿主机上是否还有别的服务。-XX:MaxMetaspaceSize给JSP和类加载预留空间，256m对绝大多数应用够了，类是特别多的可以提到512m。

5.2 线程池与连接数参数

Connector里的几个线程参数，是Tomcat扛并发的基础：

这几个参数之间是协同关系。拿一个配置示例来讲：

<Connector port="8080" protocol="HTTP/1.1" connectionTimeout="20000" maxThreads="300" minSpareThreads="20" acceptCount="100" maxConnections="8192" URIEncoding="UTF-8" enableLookups="false" />

我解释一下每个选择的含义。maxThreads从默认200提到300，是给高峰期请求处理留余量；minSpareThreads提到20，减少低峰期到高峰期的线程创建延迟；acceptCount保持100，因为队列太长，请求在队列里等到超时，体验反而更差；enableLookups="false"关闭DNS反向解析，每次解析一次主机名是很耗时的操作，没特殊需求必须关掉。

网上有些教程喜欢把maxThreads设置成1000甚至更大，我的看法是谨慎。线程不是越多越好，线程太多会带来上下文切换开销，反而拖垮吞吐。线程数的上限定多少，最好配合压测结果来，先跑一轮jmeter或者wrk，观察响应时间和CPU使用率之间的平衡点，再反推参数值。

5.3 数据源配置（JNDI）

应用里大量使用数据库连接池的，可以把数据源配置到Tomcat的context.xml或server.xml的Context元素里，应用通过JNDI名称获取连接。这样做的好处是连接池的创建和管理都交给容器，应用代码里不用硬编码数据库账号密码。

在应用目录下的META-INF/context.xml里配置：

<Context> <Resource name="jdbc/AppDB" auth="Container" type="javax.sql.DataSource" driverClassName="com.mysql.cj.jdbc.Driver" url="jdbc:mysql://localhost:3306/appdb?useUnicode=true&amp;characterEncoding=UTF-8" username="app_user" password="your_password" maxTotal="20" maxIdle="10" maxWaitMillis="10000"/> </Context>

注意几个细节：name是JNDI名称，应用里通过java:comp/env/jdbc/AppDB查找；type在Tomcat 10.1里要跟应用的命名空间匹配，新项目用javax.sql.DataSource还是jakarta开头取决于你的Tomcat版本和驱动版本；数据库驱动的jar包要放到lib目录下，Tomcat才能加载。配置完记得重启Tomcat，JNDI数据源的变更基本都需要重启才生效。

6. 安全加固：上线前需要做的几件事

Tomcat装完默认就能访问猫首页，但这只是开发模式。直接拿这套配置上生产，等于开着大门等攻击者进来。

6.1 清空默认应用与收紧管理后台

Tomcat解压后webapps目录下自带ROOT、docs、examples、manager、host-manager这些默认应用。其中docs是文档，examples是示例代码，这俩纯粹是给开发者看的，生产环境必须删掉；manager和host-manager是Web管理后台，攻击者可以利用管理台部署恶意war包，没有强需求的情况下也应该删掉。

如果团队确实需要Manager做远程部署，那至少要做两件事。第一，tomcat-users.xml里为管理账号设置强密码，只分配最小角色权限，比如只用manager-script做脚本部署，不要轻易给manager-gui的图形界面权限。第二，用Valve限制来源IP，在Manager应用的Context配置里加上：

<Context> <Valve className="org.apache.catalina.valves.RemoteAddrValve" allow="192.168.1.0/24|127.0.0.1" /> </Context>

这样只有白名单里的IP能访问管理接口，外网一律拒绝。

6.2 隐藏版本信息与访问控制

Tomcat默认在响应头里会带Server: Apache-Coyote/1.1一类的信息，报错页面也会显示具体版本号。攻击者知道你的版本，就能去查对应版本的已知漏洞。最简单的处理方式是在连接器层面加Server头隐藏：

<Connector port="8080" protocol="HTTP/1.1" server="Apache-Coyote/1.1" />

实际上Tomcat官方不建议把server头完全去掉，因为某些兼容性原因，但用防火墙把不必要的协议端口全部挡在外网，已经是基础操作。8080只对需要的IP段开放，8005这类管理端口一律内网访问，AJP端口保持禁用。安全这东西，做的就是减少暴露面。

6.3 日志滚动与监控基础配置

生产环境跑一阵子后，catalina.out会一路膨胀，几十个G的日志文件不是没见过。处理办法是在Linux上用logrotate定期轮转：

/opt/tomcat/current/logs/catalina.out { copytruncate daily rotate 15 compress missingok notifempty }

把这段配置放到/etc/logrotate.d/tomcat下就能生效。copytruncate是复制原文件然后清空，而不是把文件改名，这样Tomcat持续打开的句柄不会断。日志不轮转，磁盘写满，Tomcat会直接hang住，这种事故实际上手过的人都知道有多被动。

监控方面，最少要盯两个指标：JVM堆内存使用率和线程数。堆内存持续接近-Xmx且频繁Full GC，说明内存该调了或者有泄漏；线程数长期顶在maxThreads上限，说明要么流量超出设计，要么有慢请求占着线程不放。这些指标可以通过JMX暴露出去，接上现有的监控系统就能看。

7. 高频问题排查实录

这些年帮别人处理过不少Tomcat问题，踩来踩去发现高频率出事的就那么几类，我整理出来供你排查时对照。

7.1 端口被占用怎么办

启动时报Port 8080 required by Tomcat v10.1 Server at localhost is already in use之类的错，核心原因就是8080被别的进程占用了。排查命令：

Windows：

netstat -ano | findstr :8080

Linux：

ss -lntp | grep 8080 # 或者 lsof -i:8080

看到占用进程的PID后，确认不是系统关键进程或已部署的其他服务，再决定是杀掉还是给Tomcat换个端口。现实里经常遇到的情况是：上一次Tomcat没正常关闭，残留的Java进程还占着端口。对应的解决方式是先找到那个僵尸进程杀掉，然后重新启动。

7.2 启动闪退与日志定位

双击startup.bat窗口一闪而过，是Windows新手最常见的问题。一个原因是JDK环境变量没配好，脚本找不到java；另一个原因是启动过程中抛了异常，窗口被立即关闭。无论如何，不要在双击脚本上死磕，直接在命令行里执行catalina.bat run，所有报错都打在屏幕上。

Linux上启动失败，看日志的优先级顺序是这样的：

journalctl -u tomcat -n 50 tail -n 100 /opt/tomcat/current/logs/catalina.out ls /opt/tomcat/current/logs/

注意logs目录下除了catalina.out，还有按日期命名的catalina.2024-xx-xx.log，里面记录的异常栈往往比catalina.out更全。启动失败往往伴随两个典型坑：JAVA_HOME没指到有效JDK路径，或者内存参数-Xmx设置得超过服务器实际可用内存导致JVM直接退出。

7.3 404、403、乱码三大经典

404先分清是哪种：访问http://ip:8080出404，大概率是webapps里的ROOT应用被删了或者没部署任何应用；访问http://ip:8080/app出404，先检查war包名和大小写是否一致，Tomcat的上下文路径严格区分大小写；应用里访问子路径404，就要去查应用的Servlet映射了。

403最常见的是访问Manager或Host-manager管理后台时触发，报403 Access Denied。按6.1节说的，要么配置了RemoteAddrValve导致你的IP不在白名单，要么tomcat-users.xml里的账号缺少对应角色。还有一种是应用下某目录配置了WEB-INF权限限制，这个得看应用自己的配置。

乱码问题分几个层面：URL参数乱码，给Connector加URIEncoding="UTF-8"；页面输出乱码，检查JSP的pageEncoding和响应头里的charset；日志乱码，Windows环境下注意控制台默认GBK编码，JVM启动参数加-Dfile.encoding=UTF-8能缓解大部分问题。乱码的根因只有一个：两端的编码不一致，顺着数据流转的每个环节查编码，就能定位到具体哪里被转错了。

7.4 重部署与内存问题

开发环境改代码后经常懒得重启Tomcat，直接覆盖war包触发热部署。偶尔这么做没问题，但频繁热部署容易把老类的ClassLoader残留留在堆里，时间长了就出现PermGen space或Metaspace溢出。Tomcat 10.1里遇到Metaspace溢出，先检查是不是热部署太频繁，再检查-XX:MaxMetaspaceSize是否给得太小。

还遇到过一种典型情况：应用里用JDBC驱动，驱动类被Web应用的ClassLoader加载，但连接池的清理没有跟着卸载，结果每次重部署都会把数据库连接池整个泄漏掉。这种问题的标准解法是：把数据库驱动jar放到lib目录用共享ClassLoader加载，同时确认应用实现了ServletContextListener来正确关闭数据源。如果实在排查不出泄漏源，就定好流程：发布时完整重启Tomcat，别用热部署侥幸过关。

8. 我的个人实操心得

整套流程走下来，真正让我觉得省心的几个习惯，在这里一并分享。

第一，从第一天就用setenv.sh管理环境变量和JVM参数，不要等出了问题再回头补。我接过一个项目，Tomcat跑了两年，后来查JVM配置发现根本没生效，原因就是当时有人直接把参数写进了catalina.sh，后一次升级Tomcat目录整个被覆盖，参数全丢了，系统一直在默认堆内存下运行。用setenv.sh隔离配置，升级不丢配置，排障也只需要看这一个文件。

第二，版本升级之前，一定把conf目录整个备份一份。Tomcat升级时优先采用保留conf目录的升级方式，而不是解压新包后直接覆盖老目录。直接覆盖最大的风险是server.xml、context.xml等配置文件里的定制内容被新版本默认配置顶掉，应用看起来没变，但行为全变了。

第三，日志是一切排障的起点。遇到任何Tomcat问题，第一步不是瞎猜，而是把catalina.out、catalina日期日志、localhost访问日志挨个打开看。很多时候答案就在日志里，只是很多人习惯跳过日志先盲改配置，结果越改越乱。养成看一眼日志再动手的习惯，排查时间至少缩短一半。

第四，别追求参数的极端值。maxThreads不是越大越好，堆内存不是越多越好。先按经验和默认参数跑起来，再根据监控数据逐步调整，这才是工程化的做法。上来就堆一堆大参数的配置，看起来性能拉满，实际压测跑一轮可能直接拖垮整台机器。

Tomcat不是新东西了，但正因为老，它的稳定性和生态成熟度才更值得信赖。把下载、安装、配置这套基本功练扎实，后面无论是维护老项目还是上手新项目，你都会轻松很多。