开篇答案
Tomcat本身不需要配置CATALINA_HOME环境变量，但你必须先配置好JAVA_HOME，否则Tomcat无法启动。如果你只是用解压版Tomcat在本地做开发测试，不配CATALINA_HOME也能跑起来；但如果你要部署到服务器、用系统服务方式运行，或者在一台机器上跑多个Tomcat实例，那就建议老老实实把环境变量配好。
为什么Tomcat依赖JAVA_HOME而不是自己的环境变量
Tomcat是用Java写的Web服务器,启动时本质上是调用java命令去加载字节码，它不会去PATH里随便找个java，而是优先读取JAVA_HOME这个环境变量来定位JDK的安装目录。
行业内有很多新手在第一次装Tomcat时,双击startup.bat发现窗口一闪而过，打开日志一看提示JAVA_HOME environment variable is not defined，这个错误几乎占了Tomcat启动失败原因的多数比例。
这里有个容易混淆的点：Tomcat官方文档里提到的是JAVA_HOME必须设置，而CATALINA_HOME可有可无。CATALINA_HOME的作用是告诉系统Tomcat装在哪个目录，它的默认值就是脚本所在位置的上一级目录，绝大多数情况下，Tomcat自己就能算出来，所以不配也不影响启动。
不同场景下到底要不要配置CATALINA_HOME
开发环境：不配也行
如果你在自己的电脑上解压了Tomcat,然后直接在IDE里配置运行，或者在命令行里进入bin目录执行startup.bat，那么完全不用管CATALINA_HOME，Tomcat脚本会通过%~dp0获取当前脚本路径，自动推导出HOME目录。
但有一个前提条件：必须设置好JAVA_HOME，Windows下建议在系统环境变量里配置，不行的话也可以在setclasspath.bat里临时指定JDK路径，但不推荐，因为换版本就得改文件。
生产环境：建议配置
服务器上部署Tomcat,尤其是Linux系统，通过systemctl或init.d服务脚本管理时，服务配置文件里通常需要引用CATALINA_HOME，如果不配，很多自动化运维脚本没法统一管理。
当你用catalina.sh脚本执行start、stop、restart操作时，如果当前目录不在Tomcat的bin目录下，脚本找不到自身的相对路径，就需要CATALINA_HOME来做定位。
多实例场景：必须配置
一台服务器运行多个Tomcat实例,比如一个跑订单系统、一个跑用户后台，这是很常见的部署方式，此时每个实例的CATALINA_HOME指向同一个Tomcat安装目录，而CATALINA_BASE指向各自的配置目录，要是不配置这两个变量，所有实例会共用默认配置，端口冲突、日志混乱立刻找上门。
业界有个共识：一旦你开始管理多个Tomcat实例，环境变量就不再是可有可无的东西，而是基础设施的一部分。
tomcat环境变量怎么配置：手把手操作步骤
Windows系统配置JAVA_HOME和CATALINA_HOME
先确认JDK安装路径,例如你装在C:\Program Files\Java\jdk-17，那JAVA_HOME就填这个路径，注意不要带\bin后缀。
右键“此电脑” → 属性 → 高级系统设置 → 环境变量，在系统变量区域点“新建”：
- 变量名：
JAVA_HOME - 变量值：
C:\Program Files\Java\jdk-17
接着新建或编辑CATALINA_HOME：
- 变量名：
CATALINA_HOME - 变量值：你解压Tomcat的目录，比如
D:\apache-tomcat-10.1.28
然后编辑Path变量，新增两条：
%JAVA_HOME%\bin%CATALINA_HOME%\bin
这样做的目的是让你在任何目录下都能直接运行startup.bat和catalina.bat。
配置完成后,一定要重新打开命令行窗口，因为新环境变量不会自动更新到已启动的进程里，切换到任意目录，输入java -version，能看到版本信息说明JAVA_HOME生效，再输入catalina.bat version，如果输出Tomcat版本信息，说明CATALINA_HOME也成功了。
Linux系统配置环境变量
编辑/etc/profile文件，在末尾追加：
export JAVA_HOME=/usr/local/jdk-17
export CATALINA_HOME=/usr/local/apache-tomcat-10.1.28
export PATH=$PATH:$JAVA_HOME/bin:$CATALINA_HOME/bin保存后执行source /etc/profile让配置立即生效，用echo $CATALINA_HOME验证。
需要留意的是,Linux下Tomcat的catalina.sh脚本会检查JAVA_HOME，如果没设好，会直接报错Neither the JAVA_HOME nor the JRE_HOME environment variable is defined，这时你先处理JDK路径，再管Tomcat的变量。
tomcat配置环境变量后不生效怎么办
这是搜索量很高的一个痛点,多数情况出现在Windows上。
命令窗口能识别，但服务启动脚本还是报错
检查是不是同时存在用户变量和系统变量里的旧值,Windows的环境变量读取顺序是先用户后系统，如果你之前给当前用户配过一个错误的JAVA_HOME，系统级的正确值会被覆盖。
打开命令行,输入echo %JAVA_HOME%，看看输出的路径是否正确，如果不正确，把用户变量里的JAVA_HOME删掉，只保留系统变量。
Path里添加了%JAVA_HOME%\bin但java命令仍提示找不到
这种情况多数是变量引用顺序问题,Path中如果存在其他JDK路径，比如之前安装Oracle JDK时留下的C:\Program Files\Common Files\Oracle\Java\javapath，它排在前面就会抢先占用java
命令。
处理办法：把%JAVA_HOME%\bin上移到Path列表的顶部，或者直接删除那些不再使用的Java路径。
修改完环境变量后，Tomcat还是读取旧路径
关掉所有命令提示符窗口,包括IDE自带的终端，环境变量只在进程启动时读取，已打开的窗口不会刷新，有个比较隐蔽的坑：如果你在IDEA中启动了Tomcat，IDEA本身的环境变量是从系统继承的，重启IDEA才能拿到新值。
行业里的一个常见建议是：配置环境变量后，不要只关闭终端窗口，最好注销当前用户再登录，确保所有系统服务都能拿到新变量。
配置环境变量时的常见认知误区
很多人以为Tomcat必须同时配置JAVA_HOME和CATALINA_HOME才能运行,实际上Tomcat安装版还会自动写入注册表，解压版则完全靠变量，这里有个极易混淆的点：
JAVA_HOME是给你的Java程序找JDK用的，Tomcat、Maven、Gradle这些工具全都要读它。CATALINA_HOME是给Tomcat自己找安装目录用的，不配时脚本能从当前路径推断。
另外要注意,设置CATALINA_HOME时，变量值必须是Tomcat的根目录，而不是bin目录，如果你误填为D:\apache-tomcat-10.1.28\bin，启动脚本在拼接类路径时会找错位置，报Cannot find bin/catalina.jar之类的错误。
还有一点,有的教程让你在startup.bat开头手动加一行set CATALINA_HOME=...，这种方式只对当次启动生效，本质上没有真正配置环境变量，如果你是为了临时测试，可以这么干；但如果是给团队用的构建脚本，建议还是写到系统环境变量里。
是否需要配置CLASSPATH
很多老教程会教你在配JAVA_HOME的同时配置CLASSPATH,变量值通常是.;%JAVA_HOME%\lib\dt.jar;%JAVA_HOME%\lib\tools.jar，但在JDK 8以后，这个配置已经完全多余了，Tomcat运行时并不依赖CLASSPATH环境变量，它自己会构建完整的类加载路径，盲目添加CLASSPATH反而可能干扰其他Java程序的运行。
所以你只需要关心JAVA_HOME和CATALINA_HOME这两个变量，其他的一概不用动。
不配置环境变量有没有替代方案
使用IDE内置的Tomcat
IDEA或Eclipse都有本地服务器配置功能,你可以直接把解压后的Tomcat目录填进去，IDE会自己找到JDK位置，完全不需要你手工设置任何环境变量，这种方式适合写代码阶段，因为它能方便地热部署和查看控制台日志。
但要注意,IDE内部使用的环境变量是它启动时从系统继承的，如果你的系统JAVA_HOME本身没配，IDE会报找不到JDK，此时你需要在IDEA的Project Structure里指定SDK路径。
使用Docker容器运行Tomcat
如果你的项目用容器化部署,那么宿主机上根本不需要安装JDK和Tomcat，更不用配环境变量，Docker镜像里已经内置了这些东西，这种情况下，你只需要关心容器内的
CATALINA_HOME，通常它是固定的/usr/local/tomcat。
这种做法的好处是环境隔离,但运维同学仍然需要了解环境变量这个底层概念，因为调整JVM参数时，还是要通过JAVA_OPTS环境变量传入给容器。
环境变量配置完成后如何验证
Windows下依次执行以下命令,每一条都有明确输出：
java -version输出JDK版本号，证明JAVA_HOME已生效。catalina.bat version输出Tomcat版本和JVM参数，证明CATALINA_HOME正确。- 进入Tomcat的
bin目录，执行startup.bat，然后浏览器访问http://localhost:8080，看到Tomcat默认首页即成功。
Linux下对应命令为：
java -version
$CATALINA_HOME/bin/catalina.sh version
$CATALINA_HOME/bin/startup.sh一个容易忽略的细节：如果8080端口被其他程序占用，Tomcat会启动失败但窗口不报错，此时去logs/catalina.out或logs/localhost.日期.log里看具体原因，环境变量配错导致的失败，日志里通常会明确提示JAVA_HOME或CATALINA_HOME相关信息。
总结一句话
Tomcat对环境变量的要求只有一条硬性规则：JAVA_HOME必须配，CATALINA_HOME视使用场景而定，开发调试时可以不配，但生产部署和多实例管理时务必配全，记住这一点，你不仅能解决启动报错，还能在服务器上更灵活地组织Tomcat的运行方式。
常见问题解答
Tomcat环境变量配置错误会导致什么后果？
如果JAVA_HOME指向了不存在的目录,Tomcat启动脚本会直接报错并退出，日志显示JAVA_HOME is set to an invalid directory，如果CATALINA_HOME配置成了Tomcat的bin子目录，启动时会提示找不到catalina.jar，两种情况都不会对系统造成破坏，修正变量值即可。
安装版Tomcat也需要配置环境变量吗？
Windows安装版Tomcat会在安装过程中把自身信息写入注册表,并自动创建服务，所以不需要手动配置CATALINA_HOME，但它仍然依赖JAVA_HOME，安装程序会检查系统是否存在JDK，如果你没有事先配置JAVA_HOME，安装器会提示找不到Java运行时，部分版本甚至直接拒绝安装。
配置了JAVA_HOME后，Maven也提示找不到JDK怎么办？
Maven读取环境变量的优先级是JAVA_HOME优先于JRE_HOME，并且它会忽略用户变量和系统变量中相互冲突的值，你可以在命令行执行echo %JAVA_HOME%确认路径无误，然后检查Maven的bin/mvn.cmd脚本中是否有硬编码的JDK路径，多数情况下，Maven失败是因为你重新打开了终端但IDEA或CI工具没有重启，实际环境变量仍是旧值。