tomcat热部署不依赖环境变量，关键在于reloadable="true"配置、ide编译输出路径正确指向web-inf/classes、以及classloader能否成功卸载旧应用；改错环境变量反而可能导致配置文件读取失败，使热部署失效。
Tomcat热部署不依赖环境变量，改错地方反而会失效。 它靠的是配置文件里的 reloadable="true"、IDE编译路径指向 WEB-INF/classes、以及类加载器能否干净卸载——环境变量（如 CATALINA_HOME）只影响Tomcat启动位置，和热部署逻辑无关。
为什么改环境变量对热部署没用
热部署触发条件是 Tomcat 的 Context 监控到 /WEB-INF/classes 或 /WEB-INF/lib 下文件变化，然后执行 stop → reload 流程。这个过程由 Catalina 内部的 StandardContext 类控制，和 JAVA_HOME、CATALINA_BASE 等变量无直接关联。
-
CATALINA_HOME只决定 Tomcat 二进制文件在哪，不影响运行时类监控逻辑 -
JAVA_HOME影响 JVM 启动版本，但只要满足 Tomcat 版本要求（如 Tomcat 9 要 JDK 8+），就不会干扰 reload 行为 - 误把
CATALINA_BASE指向错误目录，反而可能导致 context.xml 读取失败，让reloadable配置压根不生效
真正要检查的三个配置点
热部署失效，90% 出现在以下三处，不是环境变量问题，而是配置或路径错位：
-
Context 配置是否启用：必须在
$CATALINA_HOME/conf/context.xml（全局）或$CATALINA_HOME/conf/Catalina/localhost/yourapp.xml（单应用）中明确写<context reloadable="true"></context>；仅改server.xml中的<host></host>的autoDeploy="true"不够，它只管新应用部署，不管已加载应用的重载 -
IDE 编译输出是否落到
WEB-INF/classes：IntelliJ 要确认Project Structure → Modules → Output path指向out/artifacts/xxx/WEB-INF/classes；Eclipse 要检查Deployment Assembly是否把src映射到/WEB-INF/classes；若输出到target/classes，Tomcat 根本不看那里 -
有没有框架锁住 ClassLoader：Spring、Hibernate 等常启后台线程或缓存静态引用，导致旧
WebAppClassLoader卸载失败；日志里出现Failed to stop application或appears to have started a thread就是这个信号，此时reloadable="true"会静默失效
常见“看似热部署失败”的真实原因
不是环境变量没设对，而是行为和预期错位：
- 修改了
web.xml、TLD或context.xml：这些属于“容器级”配置，Tomcat 会强制 reload 整个 Context，但若语法有错，会加载失败且控制台只报FAIL - Application at context path [/myapp] could not be started，没有具体行号提示 - 改了 JSP 文件但没生效：默认 JSP 编译策略较保守，需在
web.xml加<init-param><param-name>development</param-name><param-value>true</param-value></init-param>才开启实时编译 - 用 Maven 插件（如
tomcat7-maven-plugin）却配了manager/textURL：这走的是远程部署协议，和本地reloadable机制完全无关；它每次都是undeploy → deploy，不是热重载
最易被忽略的一点：Tomcat 的 reload 是「应用级重启」，不是字节码热替换。哪怕一切配置正确，每次修改 class 后也会经历短暂不可用（stop 阶段），且静态变量、单例对象全部丢失——这不是 bug，是设计使然。真要跳过 stop/start，得上 JRebel 或 Spring Boot DevTools 这类字节码增强工具，和 Tomcat 自身配置无关。
