Tomcat启动失败或页面打不开，主因是TOMCAT_HOME未正确生效或防火墙未开放8080端口：前者导致startup.sh静默失败、无服务监听，后者使流量被拦截；二者必须同时满足，缺一不可。
Tomcat 启动失败、页面打不开，八成不是代码问题，而是 TOMCAT_HOME 没生效，或者防火墙拦住了 8080 端口——这两个环节必须咬合，缺一不可。
为什么 TOMCAT_HOME 配错会导致防火墙设置白忙
Tomcat 的 startup.sh 和 shutdown.sh 会读取 TOMCAT_HOME 来定位 conf/server.xml 和日志路径；如果变量未正确导出，脚本可能静默失败（不报错但进程没起来），此时即使你开了 8080 端口，也根本没服务在监听。
-
TOMCAT_HOME必须指向解压后的根目录（如/opt/tomcat9），不能是/opt/apache-tomcat-9.0.82这类带版本号的原始名，否则后续 service 文件或定时任务容易路径断裂 - 在
/etc/profile中配置后，必须执行source /etc/profile，仅重启终端或用su -切换用户才继承新变量 - 验证方式不是看 echo 输出，而是运行
$TOMCAT_HOME/bin/version.sh—— 能打印出版本信息才算真正就位
firewall-cmd 开放 8080 端口的三个硬性条件
执行 firewall-cmd --add-port=8080/tcp 成功，不代表浏览器能访问。它只在当前 runtime 生效；若未加 --permanent，重启 firewalld 后自动失效。
- 必须同时执行两条命令：
firewall-cmd --add-port=8080/tcp --permanent+firewall-cmd --reload - 检查是否生效别只信
--list-ports，要连用ss -tlnp | grep :8080确认 Tomcat 进程确实在监听该端口 - 若用的是 CentOS 7/8 默认的
firewalld，禁用它改用iptables是常见翻车点：systemctl stop firewalld 不等于 iptables 规则清空，旧规则可能还在拦截
service 文件里藏着的环境变量陷阱
写 systemd service 启动 Tomcat 时，ExecStart 调用 startup.sh，但 systemd 默认不加载 /etc/profile，所以 TOMCAT_HOME 在 service 里是空的。
- 必须在
[Service]段显式声明：Environment="TOMCAT_HOME=/opt/tomcat9" - 不能依赖
PATH里的${TOMCAT_HOME}/bin，因为startup.sh内部仍需反查TOMCAT_HOME找conf和lib - 启动失败时查日志别只看
catalina.out，用journalctl -u tomcat.service -n 50才能看到 shell 解析环境变量的真实报错
最常被跳过的验证步骤：改完 server.xml 的 port 后，既没重载 firewall 规则，也没在 service 文件里同步更新 ExecStart 路径——端口变了，但防火墙和启动脚本还守着老地址。
