mvn azure-webapp:deploy部署Spring Boot到Azure Web App后页面无更新问题

核心排查逻辑（按优先级从高到低） #

• 首先验证部署的制品是否是本次修改后的新文件
  • 常见操作误区：直接执行mvn azure-webapp:deploy时，Maven插件不会主动帮你清理、重新编译打新war包，只会直接读取target目录下已存在的war文件上传。如果之前编译过旧版本，且后续修改代码后没执行清理编译流程，上传的就是完全没改动的旧war包，自然不会有效果。
  • 验证方法：本地查看target/custom-dashboard.war的文件修改时间，对比你最后一次修改代码的时间；如果时间早于代码修改时间，就说明根本没打新包。
• 检查Azure插件的运行时配置是否和打包格式匹配
  • 从你提供的pom配置看，存在明显配置错误：你打的是war格式的包，但是runtime配置里<webContainer>jre8</webContainer>，相当于告诉Azure平台这是一个可以直接用java -jar启动的独立Java应用，不是需要Tomcat容器承载的war包。这种配置下，平台不会自动把上传的war包挂载到Tomcat的webapps目录，也不会在war更新后触发容器重启加载新包，后续哪怕上传了新war，平台侧还是跑着第一次部署留下的旧实例。
• 检查Vaadin前端与平台缓存机制
  • Vaadin 14的生产模式会对前端静态资源生成带哈希值的缓存标识，结合Azure应用服务的静态资源缓存规则、浏览器本地缓存，哪怕后端已经加载了新war，用户访问时拿到的还是之前缓存的旧前端页面，看起来就像没更新。
• 检查免费层Web App的实例重启逻辑
  • F1免费层的Linux Web App没有常驻的文件监听服务，上传新war后不会自动触发应用进程重启，还是在内存里跑着旧的代码实例。
• 检查生产环境的无关依赖
  • pom里保留了spring-boot-devtools依赖，这个组件默认会开启文件变更监听、类加载器隔离逻辑，在Azure的Linux运行环境下经常会出现新类加载失败的问题，干扰应用正常加载新版本。

对应可落地的解决步骤 #

• 调整部署执行命令，确保每次上传的都是新编译的制品
  • 不要单独执行mvn azure-webapp:deploy，要先清理旧编译产物、激活生产环境profile打新war，完整执行：
    mvn clean package -P production azure-webapp:deploy
  • 这个命令会先清理target目录的旧文件，通过production profile触发Vaadin的前端生产模式构建，打包完成后再触发部署流程，避免上传旧war。
• 修正azure-webapp-maven-plugin的runtime配置
  • 把war包对应的web容器配置从jre8改为匹配Java 8的Tomcat版本，让平台正确识别war包的承载方式：

    <runtime>
        <os>linux</os>
        <javaVersion>jre8</javaVersion>
        <webContainer>tomcat 8.5</webContainer>
    </runtime>
    

  • 修正后插件会自动将war包部署到Tomcat的正确路径，新war上传完成后会自动触发Tomcat重启加载新应用。
• 关闭生产环境的开发类依赖
  • 在pom的spring-boot-devtools依赖上增加作用域配置，避免生产环境的类加载干扰：

    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-devtools</artifactId>
        <optional>true</optional>
        <scope>provided</scope>
    </dependency>
    

• 部署完成后手动触发一次应用重启
  • 第一次修正配置部署完成后，到Azure门户的Web App页面点击“重启”按钮，确保内存里的旧进程被完全释放；后续部署完成后可以等1-2分钟再访问，避开Azure静态缓存的周期。
• 访问页面时强制刷新清缓存
  • 用浏览器的无痕窗口访问应用，或者按Ctrl+F5强制绕过本地缓存拉取最新内容，验证更新是否生效。

补充说明：如果修正配置后部署仍然不生效，可以到Azure Web App的部署中心查看最近一次部署的war包解压路径，直接看webapps目录下的应用修改时间，和本地刚生成的war包修改时间做对比，确认文件是否真的被替换。

内容的提问来源于stack exchange，提问作者JeremP