系列第25篇 | 三个真实案例告诉你改src≠改targetSpring Boot不背这个锅背景“我明明改了那个CSS文件刷新页面怎么还是旧的”这句话我在最近一周内说了至少三次。每次都是信心满满地改完代码 → 刷新页面 → 看到旧内容 → 一脸懵 → 发现忘了mvn package。这是一个所有Spring Boot开发者都会遇到的问题但当我们把它放进AI Agent自动开发流程中时这个问题被放大了——Agent改完src/main/resources/static/下的文件后理所当然地认为改完了但实际上浏览器加载的仍然是旧的classpath资源。案例一改了3个页面的CSS线上纹丝不动某次任务需要修改user.html、role.html、permission.html三个页面的样式。开发者无论是人还是AI修改了src/main/resources/static/下的源文件然后自信满满地刷新了http://localhost:8080/user.html——结果页面一点变化都没有。为什么Spring Boot在开发模式下静态资源的加载路径和大多数人想的不一样。当你的项目结构是gainch-service/ ├── src/main/resources/static/ │ ├── user.html │ └── css/ └── target/classes/ └── static/ ├── user.html └── css/运行时Spring Boot读取的是**target/classes/static/**而不是你刚刚修改的src/main/resources/static/。这两个目录在mvn package或mvn compile时会同步一次但在这之后你对src做的任何修改都不会自动同步到target。案例二Agent打包部署的跳步问题在我们的AI Agent自动开发流程中小虾开发Agent完成代码修改后需要执行deploy.sh来打包部署#!/bin/bashcd/vol1/1000/workspace/file/8080/gainch-service mvn clean package-DskipTests-qjava-jartarget/gainch-service-1.0.0.jar这个脚本做了两件事mvn clean package——重新编译、打包把src/的内容同步到target/java -jar——用新JAR包启动服务有一次小虾修改完代码后跳过了部署步骤直接在回复中说开发完成。review.py检查时发现src/下的文件确实修改了文件mtime更新了但线上访问页面仍然是旧的——因为target/classes/里的还是旧文件。这个问题被review.py的mtime检查捕获到但因为review.py检查的是src/main/resources/static/下的文件mtime而不是target/classes/的所以误判为修改已生效。案例三target/classes残留导致的幽灵修改还有一个更隐蔽的问题当你修改了src/下的文件然后手动静止了Java进程用java -jar重新启动跳过mvn package这时Spring Boot会直接使用target/classes/中的旧文件。为什么因为java -jar target/gainch-service-1.0.0.jar加载的是JAR包内的classpath资源而JAR包是在上次mvn package时构建的。如果你只重启JVM而不重新打包JAR包里的静态资源文件永远是老的。有一次我连续改了三次CSS每次都重启了Java进程但页面始终没变。排查了十分钟才发现上次mvn package失败测试没通过target/gainch-service-1.0.0.jar是更早之前的版本。我一直在用旧JAR包重启改再多src文件也没用。根因分析Spring Boot的classpath机制Spring Boot的静态资源加载路径是这样的请求 /user.html ↓ Spring DispatcherServlet ↓ ResourceHttpRequestHandler ↓ classpath:/static/ (即 target/classes/static/) ↓ 返回 target/classes/static/user.html关键点src/main/resources/是源文件目录target/classes/是编译输出目录。Spring Boot运行时只认target不认src。mvn package / mvn compile ↓ src/main/resources/ ────────────→ target/classes/ (源文件) 同步 (运行时加载)这不是Bug是Spring Boot的标准设计。只有当你开启了spring-boot-devtools的LiveReload或者使用了spring.thymeleaf.cachefalse针对模板引擎时才会在开发模式下热加载静态资源。但对于生产部署或java -jar方式运行必须重新打包。经验总结改了静态文件后必须mvn package只重启JVM是不够的部署脚本是最后一道防线deploy.sh中的mvn clean package -DskipTests不能跳步检查target/classes的时间戳如果target比src旧说明部署还没生效devtools只适合本地开发对于容器化或生产环境部署必须走完整打包流程review.py应该检查target/classes/的文件mtime而不是只检查src/下的这也是我们正在修复的三个案例有一个共同点我们把改了文件等同于生效了但实际上改了文件只是第一步部署才是让修改真正生效的那一步。就像你换了房间的门锁但你的钥匙还是旧的——你需要把新钥匙配好、交到每个人手上才算真正换了锁。欢迎加入QQ频道共同交流。
系列第25篇 | 三个真实案例告诉你改src≠改targetSpring Boot不背这个锅背景“我明明改了那个CSS文件刷新页面怎么还是旧的”这句话我在最近一周内说了至少三次。每次都是信心满满地改完代码 → 刷新页面 → 看到旧内容 → 一脸懵 → 发现忘了mvn package。这是一个所有Spring Boot开发者都会遇到的问题但当我们把它放进AI Agent自动开发流程中时这个问题被放大了——Agent改完src/main/resources/static/下的文件后理所当然地认为改完了但实际上浏览器加载的仍然是旧的classpath资源。案例一改了3个页面的CSS线上纹丝不动某次任务需要修改user.html、role.html、permission.html三个页面的样式。开发者无论是人还是AI修改了src/main/resources/static/下的源文件然后自信满满地刷新了http://localhost:8080/user.html——结果页面一点变化都没有。为什么Spring Boot在开发模式下静态资源的加载路径和大多数人想的不一样。当你的项目结构是gainch-service/ ├── src/main/resources/static/ │ ├── user.html │ └── css/ └── target/classes/ └── static/ ├── user.html └── css/运行时Spring Boot读取的是**target/classes/static/**而不是你刚刚修改的src/main/resources/static/。这两个目录在mvn package或mvn compile时会同步一次但在这之后你对src做的任何修改都不会自动同步到target。案例二Agent打包部署的跳步问题在我们的AI Agent自动开发流程中小虾开发Agent完成代码修改后需要执行deploy.sh来打包部署#!/bin/bashcd/vol1/1000/workspace/file/8080/gainch-service mvn clean package-DskipTests-qjava-jartarget/gainch-service-1.0.0.jar这个脚本做了两件事mvn clean package——重新编译、打包把src/的内容同步到target/java -jar——用新JAR包启动服务有一次小虾修改完代码后跳过了部署步骤直接在回复中说开发完成。review.py检查时发现src/下的文件确实修改了文件mtime更新了但线上访问页面仍然是旧的——因为target/classes/里的还是旧文件。这个问题被review.py的mtime检查捕获到但因为review.py检查的是src/main/resources/static/下的文件mtime而不是target/classes/的所以误判为修改已生效。案例三target/classes残留导致的幽灵修改还有一个更隐蔽的问题当你修改了src/下的文件然后手动静止了Java进程用java -jar重新启动跳过mvn package这时Spring Boot会直接使用target/classes/中的旧文件。为什么因为java -jar target/gainch-service-1.0.0.jar加载的是JAR包内的classpath资源而JAR包是在上次mvn package时构建的。如果你只重启JVM而不重新打包JAR包里的静态资源文件永远是老的。有一次我连续改了三次CSS每次都重启了Java进程但页面始终没变。排查了十分钟才发现上次mvn package失败测试没通过target/gainch-service-1.0.0.jar是更早之前的版本。我一直在用旧JAR包重启改再多src文件也没用。根因分析Spring Boot的classpath机制Spring Boot的静态资源加载路径是这样的请求 /user.html ↓ Spring DispatcherServlet ↓ ResourceHttpRequestHandler ↓ classpath:/static/ (即 target/classes/static/) ↓ 返回 target/classes/static/user.html关键点src/main/resources/是源文件目录target/classes/是编译输出目录。Spring Boot运行时只认target不认src。mvn package / mvn compile ↓ src/main/resources/ ────────────→ target/classes/ (源文件) 同步 (运行时加载)这不是Bug是Spring Boot的标准设计。只有当你开启了spring-boot-devtools的LiveReload或者使用了spring.thymeleaf.cachefalse针对模板引擎时才会在开发模式下热加载静态资源。但对于生产部署或java -jar方式运行必须重新打包。经验总结改了静态文件后必须mvn package只重启JVM是不够的部署脚本是最后一道防线deploy.sh中的mvn clean package -DskipTests不能跳步检查target/classes的时间戳如果target比src旧说明部署还没生效devtools只适合本地开发对于容器化或生产环境部署必须走完整打包流程review.py应该检查target/classes/的文件mtime而不是只检查src/下的这也是我们正在修复的三个案例有一个共同点我们把改了文件等同于生效了但实际上改了文件只是第一步部署才是让修改真正生效的那一步。就像你换了房间的门锁但你的钥匙还是旧的——你需要把新钥匙配好、交到每个人手上才算真正换了锁。欢迎加入QQ频道共同交流。
)
