简介apache-tomcat-8.5.43.zip是面向Java Web开发者的Tomcat 8.5.43稳定版安装包适合需要快速部署Servlet/JSP应用、又不愿经历繁琐下载配置流程的初学者与运维人员。压缩包共634个文件以235个html页面、99个class、74个java源码、58个jsp及31个jar为主涵盖启动配置脚本、默认Web应用与示例文档整体仅11.07MB轻量易获取。包内startup.bat、shutdown.bat、catalina.bat等脚本齐全目录遵循Tomcat标准布局下载解压即可运行。已有137人浏览学习这份开箱即用的安装包能显著降低环境搭建门槛适合本地调试、课程实验或小型项目部署。1. 为什么偏偏是Tomcat 8.5.43这个版本卡在稳定与兼容的临界点某同学把 apache-tomcat-8.5.43.zip 解压完双击 startup.bat窗口一闪就没有了。他不信邪又点了一次还是闪退。这不是他手生而是很多“分享安装包”的文章只给下载地址不给使用边界。Tomcat 8.5.43 是 8.5.x 系列里一个值得记住的版本它保留了 Java 8 兼容性支持 Servlet 3.1也补上了 8.0 时代的不少坑又没有 9.x 换包名、改配置的折腾。如果你手里还有老项目或者你只是想在笔记本电脑上起一个干净的 Web 容器这个 zip 包比任何绿色版都靠谱。接下去我会按校验、安装、部署、调优、排错的顺序把这份 apache-tomcat-8.5.43.zip 变成你随开随用的开发环境。不用背文档照着手抄就行踩过的坑我会直接标出来。2. 把8.5.43装成可用环境下载校验、JAVA_HOME与三个必改文件2.1 获取安装包的正确姿势与zip包校验“分享安装包”这件事最容易翻车的不是压缩包本身而是传输过程中的损坏。apache-tomcat-8.5.43.zip 解压后就是一套完整的目录树bin 下有启动脚本conf 下有 server.xml、web.xml 这些核心配置lib 存放运行库webapps 是你放应用的地方logs 和 work 在启动后由 Tomcat 自己写入。它不需要写注册表也不创建 Windows 服务删掉目录就等于卸载所以很适合把它当作“开发便携机”。但正因为这样一旦 zip 少几个字节表面上也能解压启动时却会报各种奇怪的类找不到。我一般拿到 zip 的第一件事是算哈希。官方归档页面会把对应的 SHA512 校验值一起挂出来本地算完和它对得上再解压。Linux、macOS 和 Windows 的 Git Bash 都可以用 sha512sum# 先进入 zip 所在目录文件名替换成你实际下载到的文件 sha512sum apache-tomcat-8.5.43.zip如果只有 Windows 原生命令行用 CertUtilcertutil -hashfile apache-tomcat-8.5.43.zip SHA512逻辑说明这两条命令的输出都是 64 位十六进制字符串。你要和官方 .SHA512 文件里的值逐字符比较不要只比较前 12 位。文件如果被浏览器自动重命名成apache-tomcat-8.5.43(1).zip命令里的文件名也要跟着改否则立刻 No such file。校验通过后再解压。解压时记住一个原则目标路径必须用纯英文不要带空格。虽然 Tomcat 对带空格的路径多数时候能跑但后面配 JAVA_HOME、配 IDE、跑脚本会引入一层没必要的转义问题。我一般会解压到D:\work\apache-tomcat-8.5.43或/opt/tomcat8。2.2 环境变量与JAVA_HOME装Tomcat前先给自己上一课Tomcat 8.5.43 启动时需要找一个可用的 JVM。它不看你当前 PATH 里有没有 java而是直接找 JAVA_HOME 变量找不到就报Neither the JAVA_HOME nor the JRE_HOME environment variable is defined然后退出。这就是双击 startup.bat 窗口一闪而过的最大原因。很多“安装包分享”帖子把这个前提漏掉了新手第一次安装就卡在这里。Windows 下设置 JAVA_HOME 的常见做法是用 setx 写环境变量setx JAVA_HOME C:\Program Files\Java\jdk1.8.0_202 setx CATALINA_HOME D:\work\apache-tomcat-8.5.43逻辑说明setx 是持久化设置但它不会作用于当前已经打开的 cmd 窗口。你执行完 setx 后必须新开一个终端再测试。CATALINA_HOME 不是启动必需项但设了之后脚本可以更稳定地定位资源尤其在多个 Tomcat 版本切换时很有用。JDK 路径要和你本机实际安装目录一致如果装的是C:\Java\jdk8就把上面的jdk1.8.0_202换成jdk8。8.5.43 最低要求 Java 7推荐 Java 8你装 Java 17 也能启动但老项目里的某些库可能因为模块化限制报错所以开发这类环境我建议固定一个 Java 8 的 JDK。Linux 下环境变量要写进启动文件只 export 只能管当前会话export JAVA_HOME/usr/lib/jvm/java-8-openjdk-amd64 export CATALINA_HOME/opt/tomcat8 export PATH$JAVA_HOME/bin:$PATH改完source ~/.bashrc再验证。验证时两件事一起做echo $JAVA_HOME和java -version一个都不能少。JAVA_HOME 指向了 JRE 而不是 JDK 也可以Tomcat 启动用 JRE 足够但如果你之后要跑 JSP 编译其实还是需要 JDK 的 tools.jar所以直接指向 JDK 最省心。2.3 解压后立即要改的三个配置文件确认完环境变量先别急着双击 startup.bat。我一般会先把 conf 里三个文件改成自己习惯的样子免得项目跑起来之后每次改动都要记住“我动过哪里”。第一个是 server.xml 里的 HTTP Connector。默认端口 8080 在开发机上太容易被别的服务占掉而且很多人并不清楚 URIEncoding 的作用。8.5.x 默认字符集已经是 UTF-8但在有些跨团队共享项目里显式写出来能让别人少一点疑惑Connector port8080 protocolHTTP/1.1 connectionTimeout20000 redirectPort8443 URIEncodingUTF-8 /这里 port 是浏览器访问用的端口可以改成 8081、9090但后续访问地址要跟着变。redirectPort 是 https 重定向端口默认 8443不用动。connectionTimeout 表示建立连接后等待读取请求的超时毫秒数20 秒对本地开发足够了。第二个是 tomcat-users.xml。Tomcat 自带 manager 管理应用但默认没有任何用户直接访问 /manager/html 会得到 403。我习惯在第一次启动前就加一个只用于本机的账号role rolenamemanager-gui/ role rolenamemanager-script/ user usernamedevadmin password仅限本机使用的长密码 rolesmanager-gui,manager-script/manager-gui 负责图形页面上传manager-script 负责命令行部署。只配其中一种另一种接口就会报 403。这段 XML 要放在根节点tomcat-users内部注意 password 属性不要使用、这类需要转义的字符否则整个文件解析失败Tomcat 直接启动不了。第三个是 logging.properties。默认的控制台和文件日志都是 INFO开发时够用但跑久了 files 目录会很大。我会把控制台保持 INFO把核心组件的文件日志降到 WARNINGjava.util.logging.ConsoleHandler.level INFO org.apache.catalina.core.ContainerBase.[Catalina].[localhost].level WARNING这样启动信息不会太少又不会让日志一天涨几百兆。改完这三个文件后用脚本启动cd $CATALINA_HOME/bin ./startup.shWindows 下是startup.bat。如果又闪退不要继续双击改用catalina.bat run让错误留在窗口里。看到Server startup in [xxx] milliseconds字样就说明启动完成浏览器访问http://localhost:8080/会看到一个默认首页。3. 部署第一个Web应用war包、manager主页与IDE联动3.1 war包部署与访问路径的关系Tomcat 的 webapps 目录是一个自动部署目录。你把 war 包复制进去它会在几秒内解压出同名目录然后对外提供服务。# 把应用 war 包复制到 webappsdemo.war 只是示例 cp demo.war $CATALINA_HOME/webapps/demo.war复制后Tomcat 后台线程扫描到这个新 war解压出webapps/demo/访问地址是http://localhost:8080/demo/末尾的斜杠最好保留否则 Tomcat 第一次会发 302 重定向到/demo/有些客户端会丢掉 context path。如果你把 war 改名为ROOT.war再放进去它会部署在根路径访问http://localhost:8080/就是你的应用。逻辑说明这里没有任何“安装成功”的提示。要确认部署是否完成看logs/catalina.日期.log里的Deploying web application archive和Completed deployment两条记录。如果 404先检查解压目录是否存在再看 war 内部WEB-INF/web.xml里的映射。一个常见错误是以为 war 的文件名是访问路径的一部分访问/demo.war当然是 404war 是打包格式不是对外资源名。更新同一应用时不要直接把新 war 覆盖到已存在的解压目录上。Tomcat 检测到同名 war 变化后会尝试重新解压但如果解压过程中发生异常旧目录可能被保留导致你看到的是旧版本却以为部署成功。我一般先删旧解压目录再复制新 war更规范的是用 manager 的 redeploy 接口。生产环境通常会关掉 autoDeploy但开发时让它开着很省事。Tomcat 8.5.43 对 war 包还有一层热部署逻辑war 文件时间戳比解压目录新后台扫描时就会重新解压。开发时往 webapps 丢 war 包很方便但它和 IDE 的静态资源目录联动并不好因为 IDE 改的源码需要先打成 war才会被 Tomcat 感知。这也是很多人觉得“Tomcat 不自动更新”的真正原因你改的是源码目录不是 webapps 下的解压目录。3.2 让manager页面能用tomcat-users.xml的常见配法manager 这个应用是 Tomcat 自带的运维入口。默认情况下它只允许本机回环地址访问还要有对应的角色。所以你会遇到两个 403一个来自 IP 限制一个来自角色不足。开发环境默认本机访问问题基本都出在角色配置上。在 tomcat-users.xml 里加上角色和用户是最常见做法role rolenamemanager-gui/ role rolenamemanager-script/ user usernamedevadmin password本地专用密码 rolesmanager-gui,manager-script/manager-gui 对应/manager/html图形管理页面可以看应用列表、上传 war、启停应用。manager-script 对应/manager/text文本接口适合脚本调用。如果你用 curl 调 text 接口但用户只有 manager-guiTomcat 会返回 403反过来也一样。把它们都加上省得换接口时再改一遍。配好角色后还要确认 manager 应用自己的 IP 过滤。Tomcat 默认配置里conf/Catalina/localhost/manager.xml的 allow 是本机回环地址也就是只放行本机。如果你处在开发环境这个默认很合适如果要远程访问需要改 allow 列表但要明白这等于把管理端口暴露出去风险很大我从来不建议在共享网络上开 manager 远程访问。启动 Tomcat 后访问http://localhost:8080/manager/html输入用户名密码进入。如果遇到 404先检查 manager 应用是否被部署webapps 下没有 manager 目录8.5.43 的完整安装包默认包含 manager 和 host-manager如果你拿到的是精简包会没有。此时从完整包里复制 manager 目录过来也能用但要保证 Tomcat 的 lib 里相关 jar 齐全。3.3 和IDE联动远程部署与调试的秘密开发到一定阶段手动复制 war 就太累了。把 8.5.43 配置到某个 IDE 里核心动作不是 IDE 的图形界面而是让 IDE 用正确的 CATALINA_HOME 和 JAVA_HOME 启动 Tomcat。IDE 本质上会调用bin/catalina.sh或bin/catalina.bat所以之前设置的环境变量必须对。如果 IDE 里指定了一个与命令行不同的 JDK启动时可能出现UnsupportedClassVersionError那是 class 编译版本和 JDK 不匹配不是 Tomcat 的问题。不想依赖 IDE 时manager-script 接口可以直接做远程部署。我喜欢用 curl# path 是要部署的上下文路径updatetrue 表示覆盖已存在的应用 curl -u devadmin:密码 http://localhost:8080/manager/text/deploy?path/demoupdatetrue --upload-file demo.war看到OK - Deployed application at context path /demo说明部署成功。如果返回FAIL - Application already exists确认 URL 参数里有updatetrue。这里 path 必须以/开头upload-file 把 war 文件作为原始 POST 体传给 Tomcat。curl 的 -u 会把用户名密码以 Base64 放在请求头里没有加密所以只适合本机或内网开发环境。还有一个经常被提到的远程调试配置。在 setenv.sh 里加export JPDA_ADDRESS127.0.0.1:8000 export JPDA_TRANSPORTdt_socket然后用$CATALINA_HOME/bin/catalina.sh jpda startTomcat 会监听 8000 端口等待调试器连接。JPDA_ADDRESS 写成127.0.0.1:8000比只写 8000 更安全避免调试端口暴露在外部网卡。启动后你在 IDE 里用 Remote Attach 连上去断点就能命中了。要注意 jpda 启动方式是让 Tomcat 在远程调试模式下运行生产环境不要开。4. 给这台8.5.43上强度JVM参数、线程池与连接器调优4.1 catalina.sh里的JVM参数怎么填才不玄学Tomcat 启动脚本里有两个变量容易混淆JAVA_OPTS 和 CATALINA_OPTS。JAVA_OPTS 会传给所有 Java 进程包括 shutdown 命令CATALINA_OPTS 只传给主启动进程。内存参数、GC 参数、headless 设置都放在 CATALINA_OPTS避免 stop 命令也被塞入一堆奇怪参数。官方推荐的扩展点是 bin 下的 setenv.sh / setenv.bat。Tomcat 启动时会自动读取不用改动 catalina.sh 本身。这样升级 Tomcat 版本时这些个性化参数能保留。#!/bin/bash # 放在 $CATALINA_HOME/bin/setenv.sh并赋予执行权限 CATALINA_OPTS-Xms512m -Xmx1024m -XX:MaxMetaspaceSize256m -XX:UseG1GC -Djava.awt.headlesstrue export CATALINA_OPTS逻辑说明-Xms512m -Xmx1024m把堆初始和最大设为不同值。通常建议把两者设成一致防止运行中扩容导致 Full GC但在开发机上我反而允许扩容因为多数时间用不满。-XX:MaxMetaspaceSize256m限制元空间避免动态生成类过多时悄悄涨内存。-XX:UseG1GC选择 G1 垃圾回收器注意要 JDK 8u202 以上的版本才稳定更老的 JDK 8 建议保留默认 ParallelGC。-Djava.awt.headlesstrue对没有显示器的 Linux 服务器很有用防止服务端代码用到 AWT 时因为找不到显示设备而抛异常。设置完后验证最靠谱不要看心理安慰。启动 Tomcat 后执行jps -l | grep Bootstrap jcmd pid VM.flags | grep -E MaxHeapSize|MaxMetaspaceSize|UseG1GC如果输出里的 MaxHeapSize 不是 10737418241G说明 setenv.sh 没被加载。常见原因有三种文件名拼错文件没有执行权限没有重启 Tomcat。另外在 Windows 下对应的是setenv.bat语法要用 set 而不是 exportset CATALINA_OPTS-Xms512m -Xmx1024m不要在这里加引号Windows 批处理会把引号整个当成参数值。4.2 connector线程池与maxThreads的边界Connector 是 Tomcat 面对请求的入口。8.5.43 默认线程池由 Tomcat 自管理但要在高流量场景上强度最好显式定义一个 Executor。server.xml 里可以加Executor nametomcatThreadPool namePrefixcatalina-exec- maxThreads200 minSpareThreads25 maxIdleTime60000/然后让 Connector 引用它Connector executortomcatThreadPool port8080 protocolHTTP/1.1 acceptCount100 maxConnections8192 connectionTimeout20000/maxThreads 是同时处理请求的最大线程数minSpareThreads 是保持空闲的最小线程数acceptCount 是线程池满时放入操作系统 accept 队列的长度maxConnections 是包含等待中的 TCP 连接总数。这几个参数经常被误解成同一个东西。如果你把 maxThreads 设成 5000线程池会频繁创建线程线程上下文切换反而拖垮 CPU。经验值是先按 CPU 核数乘以 50 到 100 起步再压测调。开发机 4 核 8 线程设 200 已经比较保守。Connector 的 executor 属性值和 Executor 的 name 必须完全一致否则启动报错。如果你还希望给 AJP 连接器也做同样处理需要在对应 Connector 上加同样的 executor 属性。调整后重启 Tomcat在压测时用jstack pid | grep catalina-exec-看线程名的重复次数能大致判断线程池是否打满。4.3 设置server.xml里的compression和keepAliveTomcat 可以自己输出 gzip 压缩响应对文本类接口提升明显。在 Connector 上加compressionon compressionMinSize2048 compressibleMimeTypetext/html,text/xml,text/css,text/javascript,application/json,application/javascriptcompression 有三个值off、on、force。on 表示超过最小阈值且类型匹配时才压缩force 表示无论响应大小都压开发环境不建议用也可能导致某些下载内容损坏。compressionMinSize 默认 2048太小响应不值得压缩太大浪费带宽。compressibleMimeType 用逗号分隔注意 text/javascript 和 application/javascript 都写上老浏览器解析不一致。这里有一个很容易犯的“双层压缩”问题。如果你的 Tomcat 前面还有一层 Nginx 反代并且 Nginx 已经开了 gzipTomcat 端就应该把 compression 设为 off否则响应被压缩两次浪费 CPU前端响应头里还会出现两个 Content-Encoding 的歧义。判断方法用 curl -H Accept-Encoding: gzip -I 看响应头。如果已经有一层代理直接把 Tomcat 压缩关掉。keepAlive 参数也不要忽略keepAliveTimeout20000 maxKeepAliveRequests150keepAliveTimeout 是连接空闲多久后关闭maxKeepAliveRequests 是同一个连接最多处理多少个请求后主动关闭。这样避免空闲连接占满线程池也避免某些旧客户端长时间占用连接。高并发场景这两个值要根据压测结果调整如果代理和 Tomcat 之间长连接很多keepAliveTimeout 可以调短到 10 秒减轻 Tomcat 压力。修改后必须重启 TomcatConnector 在启动时已经绑定端口reload 应用上下文不会重新加载这些属性。5. 8.5.43使用避坑从启动闪退到Session丢失的排查清单5.1 启动闪退先看日志再怀疑人生现象双击 startup.bat窗口一闪就没了或者在 Linux 下执行 startup.sh终端连一句报错都没有Tomcat 也没起来。原因最大概率是 JAVA_HOME 没有设置或指向错误的环境变量其次是 conf/server.xml 被改出了 XML 语法错误Tomcat 解析失败直接退出再就是端口被占但因为启动脚本被 windows 批处理包装过错误来不及显示。解决不要反复双击改用前台模式启动。Windows 下catalina.bat runLinux 下$CATALINA_HOME/bin/catalina.sh run前台模式下 Java 进程的 stderr 直接输出到终端错误信息会停在窗口里。如果看到 “Neither the JAVA_HOME nor the JRE_HOME environment variable is defined”检查环境变量。如果看到 “Address already in use”去看端口。如果只是 “Invalid initial heap size”说明 setenv 里的 -Xms 大于 -Xmx把两个值改正确。大多数闪退都能在这里找到答案而不是去猜。5.2 8080被占用先分清是Tomcat自己还是别的进程现象启动日志报Port 8080 required by Tomcat 8.5.43 connector is already in use但浏览器访问 localhost:8080 却能看到一个东西不是你的应用。原因端口已经被另一个进程占用。那个进程可能是一个残留在后台的老 Tomcat也可能是某个 IDE 启动过内嵌服务器还可能是完全无关的程序。盲目的做法是杀掉一切占用进程有可能误杀重要服务。解决先找到 PIDWindows 下执行netstat -ano | findstr :8080 tasklist /FI PID eq PIDLinux 下执行ss -lntp | grep 8080 lsof -i:8080确认 PID 对应的进程名后再决定处理。如果确定是残留 Tomcat可以 taskkill 或 kill如果是别的服务就改 Tomcat 端口。改端口有一个容易漏的地方Tomcat 监听的不只 HTTP 8080还有 AJP 8009 和 Server shutdown 8005。如果你要复制一份跑第二个实例三处端口都必须改Server port8006 shutdownSHUTDOWN ... Connector port8081 protocolHTTP/1.1 ... / ... Connector port8010 protocolAJP/1.3 ... /只改 HTTP 端口第二个实例启动时还有两个端口会和第一个实例冲突。这也是多实例部署最常见的问题。5.3 部署后404/403理解context path与角色配置现象war 包放进 webapps 后访问http://localhost:8080/demo出现 404访问/manager/html出现 403。原因404 的根源往往是 context path 和请求路径不一致。war 包文件名决定了 context pathdemo.war映射到/demo不是/demo.war。但应用内部的某个 Servlet 如果映射在/foo访问/demo当然看不到。403 则几乎都是 manager 角色没有配好或者请求来源 IP 不在允许列表。解决排查 404 时先确认解压目录存在且里面有 WEB-INF再访问http://localhost:8080/demo/带末尾斜杠防止重定向丢路径。看启动日志中Deploying web application archive之后有没有Completed deployment。如果 war 包是旧项目web.xml 是 Servlet 2.5 且开着注解扫描可能因为重复映射产生假 404尝试在 web.xml 根节点加metadata-completetrue。排查 403 时检查 tomcat-users.xml确认用户有 manager-gui 或 manager-script且 XML 没被转义字符破坏。改完用户后必须重启 TomcatTomcat 只在启动时解析这个文件。5.4 重启后Session丢失你以为存了其实没有现象Tomcat 正常重启或应用 redeploy 之后用户全部需要重新登录。原因Tomcat 默认 Session 管理器是 StandardManagerSession 数据只存在于 JVM 内存里。进程重启、内存释放Session 就销毁。这不是配置错误也不是因为 work 目录没有被保存。很多人被 work 目录误导以为那是 session 持久化文件实际上 work 只放 JSP 编译产物。解决开发环境不需要还原 Session接受重启退出登录即可。生产环境要做 Session 外置常见做法是项目引入 Spring Session 配合 Redis把 session 放到共享存储或者使用 Tomcat 自带的 PersistentManager把 session 序列化到文件。后者只在单机测试有意义多实例部署时文件不一致不如 Redis 可靠。另外一个细节通过 manager 页面 redeploy 应用时Tomcat 会尝试把旧 Context 的 session 迁移到新 Context有时看起来没丢但真正重启进程后一定全丢。不要用“刚才没丢”来推断重启也没事。5.5 配置文件的编码坑中文注释把Tomcat搞崩现象server.xml 或 tomcat-users.xml 里写了几行中文注释保存后重启Tomcat 启动报org.xml.sax.SAXParseException甚至提示Premature end of file整个服务起不来。原因Tomcat 的 XML 解析器默认按 UTF-8 读取配置。Windows 记事本如果用默认 ANSI 编码保存中文注释文件实际编码与 UTF-8 不一致解析器读到字节流后无法正确解析标签结构于是报错。这个问题在 Windows 下很常见尤其是直接从网页复制配置再粘贴进记事本的时候。解决所有 conf 下的 XML 文件统一另存为 UTF-8 编码。用编辑器打开时看右下角或文件菜单里的编码信息改为UTF-8后再保存。更省事的办法是配置文件里完全不用中文注释全部写英文。Tomcat 官方文档里的注释本身就接近零中文不是没有道理的。如果已经报错用文本编辑器重新打开文件另存为 UTF-8 后重启 Tomcat错误消失。6. 把8.5.43玩成开发便携机多实例、调优验证与安全升级6.1 一份解压包跑两个端口有时候你想同时跑两个不同配置的实例不需要复制整个 Tomcat。可以借助 CATALINA_BASE 只复制配置目录mkdir -p /opt/tomcat-node1/{conf,logs,temp,webapps,work} cp -r $CATALINA_HOME/conf/* /opt/tomcat-node1/conf/ export CATALINA_HOME/opt/apache-tomcat-8.5.43 export CATALINA_BASE/opt/tomcat-node1 $CATALINA_HOME/bin/startup.shCATALINA_BASE 指向实例目录CATALINA_HOME 指向 zip 解压出来的主目录。这样主目录里的 lib、bin 共用节点目录里只放 conf、logs、webapps。注意在启动前把节点目录里的 server.xml 三处端口改掉否则两个实例会冲突。这个玩法方便我在本机模拟多环境给不同目录起不同的端口和日志。6.2 用jstat和jcmd验证调优效果调优之后不能只靠“感觉变快了”。验证有一套固定动作。先找到 Tomcat 的 Java 进程jps -l | grep Bootstrap然后看 GC 情况jstat -gcutil pid 1000 5YGC 和 FGC 分别表示 YoungGC 和 FullGC 次数如果 FGC 频繁说明堆顶不住加 Xmx 或排查代码。再用 jcmd 确认参数jcmd pid VM.flags如果明显看到 MaxHeapSize 不是你设的值回到 setenv.sh 检查语法。用数据说话这是避免“以为调好了”的唯一方式。6.3 升级新版本前先做conf目录diffTomcat 8.5.x 会持续发补丁版。升级时最忌新包直接解压覆盖旧目录因为你会把新代码和一份可能是几年前的 conf 混在一起。我养成的习惯是解压新包后不急着切目录先和旧 conf 做 diffdiff -rq $CATALINA_HOME/conf /tmp/apache-tomcat-8.5.最新版/conf有差异的文件逐个看能合并就合并合并不了就把新版本的默认配置留下来再把业务需要的 server.xml 片段手工套上去。保留旧目录作为回滚点确认新实例跑满一个开发周期后再决定是否清理。这个习惯帮我避免过至少一次“升级后 manager 页面 404”的尴尬因为旧 conf 里缺了新版默认的 Valve 配置。某次升级就是我以为 conf 没变直接覆盖结果新版要求的 Context 配置缺失整个应用 403 了一天。从那以后我再也不敢直接覆盖目录先起新目录再切环境变量才有后悔药。Tomcat 8.5.43 是个老版本但作为开发环境它完全够用你只需要把它当成一台“便携机”备份、diff、验证一步步来。希望帮到你。本文还有配套的精品资源点击获取
