SpringMVC404错误解决方法详解

Spring MVC应用启动后出现404错误，往往并非路由配置或页面路径问题，而是底层DispatcherServlet未能成功初始化——根源在于Spring 6.x与Thymeleaf 3.1.x等新版本组件存在隐式兼容性断裂，导致HandlerMapping和ViewResolver等核心组件静默注册失败；真正有效的解决路径是统一降级至稳定兼容的Spring 5.3.24（支持Java 17且完美适配Thymeleaf 3.1.x及Jakarta EE过渡层），并严格清理依赖冲突、重置本地仓库与IDE缓存；若追求长期可维护性，可转向Spring Boot自动版本对齐方案，但深入理解传统Spring MVC的版本协同逻辑，仍是掌握其请求调度本质的关键一步。

Spring MVC应用启动后访问控制器返回404，常因Spring框架各模块版本不兼容（如Spring Web MVC 6.0.x与Thymeleaf 3.1.x不匹配）或DispatcherServlet配置失效导致，需重点核查依赖版本一致性与组件注册完整性。

Spring MVC应用启动后访问控制器返回404，常因Spring框架各模块版本不兼容（如Spring Web MVC 6.0.x与Thymeleaf 3.1.x不匹配）或DispatcherServlet配置失效导致，需重点核查依赖版本一致性与组件注册完整性。

在基于传统XML配置（web.xml + applicationContextMVC.xml）的Spring MVC入门项目中，出现“HTTP Status 404 – Not Found”且提示 “The origin server did not find a current representation for the target resource”，往往并非路由映射缺失或JSP路径错误，而是更底层的容器初始化失败——即 DispatcherServlet 根本未成功加载或其关联的HandlerMapping、ViewResolver等核心组件未能注册。这类问题在Spring 6+与较新生态组件（如Thymeleaf 3.1+）混用时尤为典型。

? 根本原因：Spring 6.x 与 Thymeleaf 3.1.x 的兼容性断裂

Spring Framework 6.0 起全面要求 Java 17+ 和 *Jakarta EE 9+（即 `jakarta.命名空间）**，而 Thymeleaf 3.1.1 虽已支持 Jakarta EE 9，但其官方兼容矩阵明确指出： ✅ **Thymeleaf 3.1.x 官方推荐搭配 Spring Framework 5.3.24+（非6.x）** ❌ Spring Framework 6.0.x（如6.0.5/6.0.6）与 Thymeleaf 3.1.x 存在隐式依赖冲突，尤其影响ViewResolver初始化和模板资源定位逻辑，导致DispatcherServlet` 启动时跳过视图解析器注册——此时即使Controller正确响应，最终也无法将Model渲染为JSP/HTML，请求直接落入404。

? 注意：该问题与Tomcat版本（9.0.73）、Maven插件（如maven-war-plugin）或web.xml配置无直接关系，而是Spring容器上下文在刷新阶段静默失败所致。

✅ 正确解决方案：降级Spring至5.3.x稳定分支

将 pom.xml 中所有Spring相关BOM依赖统一降级至 5.3.24（Spring 5最后一个维护版本，完全兼容Java 17 + Jakarta EE 8/9过渡层）：

    5.3.24



    
        org.springframework
        spring-webmvc
        ${spring.version}
    
    
        org.springframework
        spring-context
        ${spring.version}
    
    
        org.springframework
        spring-core
        ${spring.version}
    
    
        org.springframework
        spring-web
        ${spring.version}
    
    
    
        org.thymeleaf
        thymeleaf-spring5
        3.1.1.RELEASE
    

⚠️ 关键检查点：

• 删除任何显式声明的 spring-beans、spring-aop 等子模块版本（由spring-webmvc传递依赖自动引入）；
• 若使用JSP，确保web.xml中为org.springframework.web.servlet.DispatcherServlet，且正确指向applicationContextMVC.xml；
• 清理Maven本地仓库中可能残留的Spring 6.x快照包（执行 mvn clean dependency:purge-local-repository）；
• 重启IDE（IntelliJ/Eclipse）并重新部署到Tomcat，观察控制台是否输出 Mapped URL path [/hello] onto method ... —— 这是DispatcherServlet成功注册Handler的标志。

? 补充建议：面向未来的轻量替代方案

若希望长期避免此类兼容陷阱，建议逐步迁移至现代Spring Boot方式：

• 使用 spring-boot-starter-web（自动适配Spring 6.x + Jakarta EE 9）；
• 以@Controller + @ResponseBody替代XML配置；
• 用Thymeleaf 3.1.x + spring-boot-starter-thymeleaf（内置版本对齐）。

但对学习Spring MVC底层机制而言，精准控制Spring 5.3.x版本仍是理解DispatcherServlet生命周期、HandlerMapping与ViewResolver协作原理的最佳实践入口。

总结：404不是“找不到页面”，而是“没启动好调度器”。版本兼容性是传统Spring MVC项目的隐形地雷——坚持使用Spring 5.3.x系列，是兼顾Java 17、稳定性与教学清晰性的最优解。

文中关于的知识介绍，希望对你的学习有所帮助！若是受益匪浅，那就动动鼠标收藏这篇《SpringMVC404错误解决方法详解》文章吧，也可关注golang学习网公众号了解相关技术文章。