1. 问题本质与典型场景还原你刚在本地用 IntelliJ IDEA 新建了一个 Spring Boot 项目JDK 版本选的是 17 或 21Spring Boot 版本默认是 3.2.x 或 3.3.x写完RestController和一个简单的index.html放进src/main/resources/static/目录后兴冲冲地点击 Run控制台显示Tomcat started on port(s): 8080 (http)浏览器输入http://localhost:8080—— 页面空白F12 看 Network 标签页状态码是 404再输http://localhost:8080/index.html还是 404最后点开 Console赫然一行红字java.lang.NoSuchMethodError: javax.servlet.http.HttpServletMapping javax.servlet.http.HttpServletRequest.getHttpServletMapping()。你截图发到技术群老同事回一句“你这 Spring Boot 版本太高了Servlet API 不兼容。”——没错这不是你代码写错了也不是 Tomcat 没启动而是你正踩在一个被大量新手忽略、但 Spring Boot 官方文档里埋得极深的Servlet 规范断层陷阱上。这个报错关键词javax.servlet.http.HttpServletRequest.getHttpServletMapping是核心线索。它不是你写的代码调用的而是 Spring Boot 内部某个自动配置类比如WelcomePageHandlerMapping在尝试解析请求路径时反射调用了这个方法。而该方法首次出现在Servlet 4.0 规范中对应 Java EE 8 / Jakarta EE 8要求 Servlet 容器必须提供HttpServletRequest的getHttpServletMapping()方法。但问题在于Spring Boot 3.x 默认依赖的是 Jakarta Servlet 5.0即 Servlet 5.0而你的本地 Tomcat 实例尤其是 IDEA 自带的嵌入式 Tomcat如果版本偏低或者你手动指定了旧版 Tomcat就很可能只实现了 Servlet 4.0 或更早规范压根没有这个方法。更隐蔽的是有些开发环境比如某些企业定制版 JDK 或老旧 IDE 插件会偷偷加载旧版servlet-api.jar到 classpath导致运行时实际加载的是 Servlet 3.1 的类而编译期却按 Servlet 5.0 的接口去调用直接触发NoSuchMethodError。我去年帮三个不同团队排查过类似问题一个是在金融客户现场他们强制要求 JDK 17 Spring Boot 3.1但运维给的 Docker 基础镜像里 Tomcat 是 9.0.41Servlet 4.0结果所有静态资源 404另一个是外包项目前端同学用 Vue CLI 起了个 dev server后端 Spring Boot 3.2 服务跑在 8080他试图用fetch(/api/user)调后端结果连预检请求都失败抓包发现 OPTIONS 请求返回 500根源也是getHttpServletMapping找不到第三个最典型——应届生小张用最新版 IDEA 2023.3 创建 Spring Boot 3.3 项目没改任何配置mvn spring-boot:run启动后访问localhost:8080就报这个错查了一整天 Stack Overflow最后发现是 IDEA 的 Maven 插件缓存了旧版tomcat-embed-core。所以这个问题的本质不是“本地无法访问”而是Spring Boot 运行时环境与 Servlet 规范版本之间出现了不可调和的契约撕裂。它不发生在编译阶段IDE 不报错也不发生在启动日志里Tomcat 显示正常启动而是在第一个 HTTP 请求抵达 DispatcherServlet 时由 Spring MVC 的欢迎页处理器触发属于典型的“运行时契约违约”。2. 核心原理拆解为什么 Spring Boot 3.x 一定要用 Servlet 5.0要真正解决这个问题不能只靠“降版本”这种粗暴方案必须理解 Spring Boot 3.x 对 Servlet 规范升级背后的底层逻辑。这里没有黑魔法全是 Jakarta EE 生态演进的必然结果。2.1 Jakarta EE 迁移从 javax.* 到 jakarta.* 的生死线2019 年Oracle 将 Java EE 移交给 Eclipse 基金会并更名为 Jakarta EE。这一迁移不仅是名字变更更是包名的彻底重构。Java EE 8 及之前所有 Servlet 相关类都在javax.servlet.*包下而 Jakarta EE 9 开始全部迁移到jakarta.servlet.*。Spring Boot 2.5 是最后一个支持javax.servlet的主版本Spring Boot 3.0 强制要求 Jakarta EE 9即所有依赖必须使用jakarta.servlet.*包名。这意味着编译期你的pom.xml里dependencygroupIdjakarta.servlet/groupIdartifactIdjakarta.servlet-api/artifactId/dependency必须存在且版本 ≥ 5.0Servlet 5.0 对应 Jakarta EE 9.1运行时嵌入式容器Tomcat/Jetty/Undertow提供的HttpServletRequest实现类其字节码必须声明实现jakarta.servlet.http.HttpServletRequest接口且该接口中定义了getHttpServletMapping()方法如果你的 classpath 里混入了旧版javax.servlet-api-3.1.0.jar常见于某些老旧的 Maven 仓库镜像或企业私库JVM 类加载器可能优先加载它导致运行时HttpServletRequest是javax.servlet版本而 Spring Boot 3.x 的代码却在调用jakarta.servlet接口里的方法——这就会引发NoClassDefFoundError或IncompatibleClassChangeError比NoSuchMethodError更致命。2.2 getHttpServletMapping() 的真实用途静态资源路由的基石很多人以为这个方法只是个摆设其实它是 Spring MVC 处理欢迎页welcome page和静态资源的核心枢纽。我们来还原一次http://localhost:8080/请求的完整链路请求到达嵌入式 Tomcat被封装为jakarta.servlet.http.HttpServletRequest实例Tomcat 将请求交给 Spring Boot 的DispatcherServletDispatcherServlet调用HandlerMapping寻找处理器其中WelcomePageHandlerMapping负责处理根路径/WelcomePageHandlerMapping的核心逻辑是调用request.getHttpServletMapping().getPattern()获取当前请求匹配的 Servlet 模式如/*再结合ServletContext.getRealPath(/)定位静态资源根目录最后按顺序查找index.html、index.htm等欢迎文件如果getHttpServletMapping()方法不存在第 4 步直接抛出NoSuchMethodError整个链路中断index.html永远不会被读取。这个设计在 Servlet 4.0 中引入目的是让容器能精确告知框架“当前请求是被哪个 Servlet 映射规则捕获的”从而让 Spring MVC 能智能区分/*默认 Servlet和/api/*DispatcherServlet等不同映射避免静态资源和动态接口的路由冲突。Spring Boot 3.x 的ResourceWebHandler、WelcomePageHandlerMapping等组件深度依赖此能力。所以这不是一个可有可无的 API而是现代 Web 框架路由机制的基础设施。2.3 Spring Boot 版本与 Servlet 规范的严格绑定关系Spring Boot 官方文档明确列出了各版本对 Servlet 容器的最低要求。这不是建议而是硬性约束Spring Boot 版本最低 Jakarta Servlet 版本对应 Tomcat 版本对应 Jetty 版本典型 JDK 要求3.0.x - 3.1.x5.0 (Servlet 5.0)10.0.x11.0.xJDK 173.2.x6.0 (Servlet 6.0)10.1.x12.0.xJDK 173.3.x6.0 (Servlet 6.0)10.1.x12.0.xJDK 21注意Tomcat 10.0.x 是第一个完全支持 Jakarta Servlet 5.0 的版本。Tomcat 9.x包括 9.0.8x只支持 Jakarta Servlet 4.0即 Servlet 4.0其HttpServletRequest接口根本没有getHttpServletMapping()方法。如果你的项目里显式依赖了tomcat-embed-core版本号却是9.0.83那无论你 Spring Boot 是 3.0 还是 3.3只要运行时加载的是这个 jar就必然报错。同理Jetty 11.x 才支持 Servlet 5.0Jetty 10.x 只支持 Servlet 4.0。3. 四步精准定位与修复方案附实操命令与配置遇到这个报错别急着删项目重来。按以下四步90% 的情况能在 5 分钟内定位并解决。每一步我都给出 Linux/macOS 和 Windows 的实操命令以及关键日志判断依据。3.1 第一步确认 Spring Boot 和嵌入式容器的真实版本这是最关键的起点。很多人只看pom.xml里的version却忽略了 Maven 的依赖传递和 IDE 的缓存。操作在项目根目录执行 Maven 命令生成完整的依赖树# Linux/macOS mvn dependency:tree -Dincludesorg.springframework.boot:spring-boot-starter-web,org.apache.tomcat.embed:tomcat-embed-core,jakarta.servlet:jakarta.servlet-api | grep -E (spring-boot|tomcat|jakarta):: Windows PowerShell mvn dependency:tree -Dincludesorg.springframework.boot:spring-boot-starter-web,org.apache.tomcat.embed:tomcat-embed-core,jakarta.servlet:jakarta.servlet-api | Select-String spring-boot|tomcat|jakarta预期输出示例健康状态[INFO] \- org.springframework.boot:spring-boot-starter-web:jar:3.3.0:compile [INFO] - org.springframework.boot:spring-boot-starter-tomcat:jar:3.3.0:compile [INFO] | \- org.apache.tomcat.embed:tomcat-embed-core:jar:10.1.24:compile [INFO] \- jakarta.servlet:jakarta.servlet-api:jar:6.0.0:compile危险信号需立即处理tomcat-embed-core:jar:9.0.83→ Tomcat 版本太低不支持 Servlet 5.0javax.servlet:javax.servlet-api:jar:3.1.0→ 混入了旧版 javax 包必须排除jakarta.servlet:jakarta.servlet-api:jar:4.0.4→ Jakarta Servlet 版本过低应为 5.0 或 6.0提示如果mvn dependency:tree输出里看不到tomcat-embed-core说明你可能在pom.xml中显式排除了它或者使用了spring-boot-starter-undertow/spring-boot-starter-jetty。此时请将命令中的tomcat-embed-core替换为undertow-core或jetty-server并检查其版本是否符合对应 Servlet 规范。3.2 第二步检查运行时实际加载的类来源终极验证Maven 依赖树反映的是编译期依赖而 JVM 运行时加载的类可能来自不同路径。我们需要在应用启动时强制打印HttpServletRequest类的加载位置。操作修改application.properties添加 JVM 参数启用类加载日志# application.properties # 启动时打印 HttpServletRequest 类的加载路径 logging.level.org.springframework.webDEBUG # 可选如果想看更底层的类加载加这个参数到 VM options # -verbose:class -XX:TraceClassLoading然后在 IDEA 的 Run Configuration 中找到 “VM options” 栏填入-verbose:class -XX:TraceClassLoading | grep HttpServletRequest启动应用观察控制台输出正常情况你会看到类似Loaded jakarta.servlet.http.HttpServletRequest from file:/.../tomcat-embed-core-10.1.24.jar的日志危险情况如果看到Loaded javax.servlet.http.HttpServletRequest from file:/.../servlet-api-3.1.0.jar说明旧版 javax 包被加载必须在pom.xml中排除它。注意-verbose:class会产生大量日志建议只在排查时开启日常开发关闭。更轻量的方法是在报错堆栈中找到getHttpServletMapping()被调用的类通常是WelcomePageHandlerMapping在其handle方法里加断点调试时查看request.getClass().getProtectionDomain().getCodeSource().getLocation()直接获取 jar 包路径。3.3 第三步针对性修复三种场景任选其一根据前两步的诊断结果选择对应的修复方案。不要盲目降 Spring Boot 版本那是治标不治本。场景一Tomcat 版本过低最常见症状dependency:tree显示tomcat-embed-core:9.0.83且你未在pom.xml中显式指定版本。原因Spring Boot 3.x 的父 POM 默认管理tomcat-embed-core为 10.1.x但如果你的pom.xml继承了某个老旧的公司 parent POM或者 Maven settings.xml 配置了错误的仓库镜像可能导致拉取到旧版。修复在pom.xml的properties中强制指定 Tomcat 版本properties !-- Spring Boot 3.3.x 对应 Tomcat 10.1.x -- tomcat.version10.1.24/tomcat.version /properties或者在dependencies中显式声明依赖推荐dependency groupIdorg.apache.tomcat.embed/groupId artifactIdtomcat-embed-core/artifactId version10.1.24/version /dependency验证执行mvn clean compile再次运行dependency:tree确认tomcat-embed-core版本已更新。场景二混入 javax.servlet 旧包次常见症状dependency:tree或-verbose:class显示javax.servlet-api被加载。原因某个第三方依赖如老版本的spring-boot-starter-data-jpa、mybatis-spring-boot-starter传递引入了javax.servlet-api。修复在pom.xml中全局排除javax.servletdependencyManagement dependencies dependency groupIdjavax.servlet/groupId artifactIdjavax.servlet-api/artifactId version3.1.0/version scopeprovided/scope /dependency /dependencies /dependencyManagement dependencies !-- 你的其他依赖 -- dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId !-- 排除所有 javax.servlet 传递依赖 -- exclusions exclusion groupIdjavax.servlet/groupId artifactIdjavax.servlet-api/artifactId /exclusion /exclusions /dependency /dependencies验证mvn dependency:tree -Dincludesjavax.servlet应该返回空。场景三IDEA 缓存污染新手高频症状dependency:tree显示正确版本但-verbose:class仍加载旧 jar或者你刚升级 Spring Boot重启 IDEA 后问题依旧。原因IDEA 的 Maven 插件会缓存依赖的 jar 文件有时不会自动刷新。修复彻底清理 IDEA 缓存菜单栏File → Invalidate Caches and Restart → Invalidate and Restart重启后在项目根目录执行mvn clean右键项目 →Maven → Reload project再次运行应用。实操心得我在某银行项目组见过最离谱的案例——开发机上~/.m2/repository/org/apache/tomcat/embed/tomcat-embed-core/目录下同时存在9.0.83和10.1.24两个文件夹IDEA 随机加载其中一个。解决方案是rm -rf ~/.m2/repository/org/apache/tomcat/embed/然后mvn clean compile重新下载。3.4 第四步终极兜底方案——降级 Spring Boot仅当上述无效如果以上三步都试过问题依旧且你无法控制基础环境比如公司统一要求 JDK 17 但 Tomcat 9.x 是标准镜像那么降级 Spring Boot 是唯一选择。但请注意Spring Boot 2.7.x 是最后一个支持 JDK 17 的 2.x 版本且它仍使用javax.servlet与 Tomcat 9.x 完全兼容。操作修改pom.xmlparent groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-parent/artifactId version2.7.18/version !-- Spring Boot 2.7.x 的最终维护版 -- relativePath/ /parent同时确保spring-boot-starter-web依赖正确dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId !-- Spring Boot 2.7.x 默认使用 Tomcat 9.0.x -- /dependency代价你将失去 Spring Boot 3.x 的所有新特性如 GraalVM 原生镜像、Jakarta EE 9 的全面支持、新的 Actuator 端点等且 2.7.x 已于 2023 年 11 月结束官方维护。所以这只是临时方案长期务必升级基础设施。4. 静态资源访问失效的深层原因与配置补救即使getHttpServletMapping问题解决了localhost:8080仍可能不显示index.html。这是因为 Spring Boot 的静态资源处理机制有多个层级任何一个环节出错都会导致 404。4.1 Spring Boot 静态资源默认路径与优先级Spring Boot 2.x/3.x 对静态资源的默认配置是一致的但底层实现因 Servlet 版本而异。src/main/resources/static/是最高优先级的路径其次是src/main/resources/public/、src/main/resources/resources/、src/main/resources/META-INF/resources/。当你访问/时Spring Boot 会按此顺序查找index.html。验证方法在application.properties中开启静态资源调试# 启用静态资源日志 logging.level.org.springframework.web.servlet.resourceDEBUG # 可选强制指定静态资源路径 spring.web.resources.static-locationsclasspath:/static/,classpath:/public/,classpath:/resources/,classpath:/META-INF/resources/启动后访问localhost:8080观察控制台 DEBUG 日志正常ResourceHttpRequestHandler: Resource not found: class path resource [static/index.html]→ 说明找到了文件但可能因 MIME 类型或编码问题未渲染异常ResourceHttpRequestHandler: No matching resources found→ 说明路径配置错误或文件未编译到 target 目录。注意mvn compile后target/classes/static/index.html必须存在。如果index.html在src/main/webapp/下传统 WAR 结构Spring Boot 默认不扫描该路径必须手动配置spring.web.resources.static-locationsclasspath:/static/,file:src/main/webapp/。4.2 Welcome Page Handler 的激活条件WelcomePageHandlerMapping不是永远生效的。它有一个隐藏开关只有当DispatcherServlet的 servlet mapping pattern 是/*时它才工作。如果你在application.properties中配置了# 错误这会让 DispatcherServlet 只处理 /api/*根路径 / 交给默认 Servlet spring.mvc.servlet.path/api那么localhost:8080/请求根本不会进入 Spring MVC而是直接由 Tomcat 的 DefaultServlet 处理。此时index.html能访问但getHttpServletMapping报错不会出现——因为 Spring MVC 根本没参与。正确配置让DispatcherServlet处理所有请求默认行为# 保持默认不要修改 # spring.mvc.servlet.path/或者如果你想保留/api前缀但又想让根路径走欢迎页可以这样// Java Config 方式 Configuration public class WebConfig { Bean public WelcomePageHandlerMapping welcomePageHandlerMapping(ApplicationContext applicationContext) { return new WelcomePageHandlerMapping(new ClassPathResource(static/index.html), applicationContext); } }4.3 MIME 类型与字符编码陷阱即使index.html被成功读取浏览器也可能显示乱码或空白。这是因为 Spring Boot 3.x 默认的Content-Type是text/html;charsetUTF-8但如果index.html文件本身是 GBK 编码保存的浏览器就会解析失败。修复统一文件编码在 IDEA 中File → Settings → Editor → File Encodings设置Global Encoding和Project Encoding为UTF-8右键index.html→File Encoding→Convert to UTF-8在index.html的head中显式声明meta charsetUTF-8验证用curl -I http://localhost:8080/查看响应头确认Content-Type: text/html;charsetUTF-8。5. 常见问题速查表与独家避坑技巧以下是我在 12 个真实项目中总结的高频问题及解决方案附带“为什么”和“怎么查”。问题现象根本原因快速诊断命令修复方案我的实操心得localhost:8080404但localhost:8080/index.html200WelcomePageHandlerMapping未生效curl -v http://localhost:8080/看响应头是否有X-Application-Context检查spring.mvc.servlet.path是否被修改确认index.html在static/下这个问题常被误认为是静态资源路径错其实是 DispatcherServlet 的 mapping pattern 问题。用curl -v看响应头比看浏览器更准。控制台报NoSuchMethodError但dependency:tree显示 Tomcat 10.1.xMaven 依赖树正确但运行时加载了旧版 jarjps -l找到进程 PIDjstack PID | grep -A5 HttpServletRequest清理~/.m2/repository重启 IDEA检查settings.xml是否指向了错误的 Nexus 仓库我曾在一个项目里发现公司 Nexus 仓库的tomcat-embed-core10.1.x 版本被人工覆盖成了 9.0.x 的 jar导致所有开发机都中招。index.html显示中文乱码index.html文件编码与 HTTP 响应头不一致file -i src/main/resources/static/index.html在 IDEA 中统一设为 UTF-8index.html加meta charsetUTF-8用file -i命令比肉眼判断编码更可靠。Windows 记事本保存的文件默认是 ANSI极易出问题。使用spring-boot-starter-jetty仍报错Jetty 版本不匹配mvn dependency:tree -Dincludesorg.eclipse.jetty:jetty-serverSpring Boot 3.3.x 需jetty-server:12.0.5在pom.xml中显式声明Jetty 的版本命名很反直觉Jetty 11.x Servlet 5.0Jetty 12.x Servlet 6.0。别被数字迷惑。Docker 部署后localhost:8080404本地正常Docker 镜像中target/目录未包含static/docker run -it image ls -l /app/target/classes/static/确保mvn clean package后target/classes/static/存在Dockerfile 中COPY target/*.jar app.jar很多人用mvn compile打包但compile不会把static/复制到classes/必须用package。独家避坑技巧技巧一创建一个“版本快照”脚本在项目根目录新建check-env.shLinux/macOS或check-env.batWindows内容如下# check-env.sh echo Spring Boot Version mvn help:evaluate -Dexpressionproject.parent.version -q -DforceStdout echo Tomcat Version mvn dependency:tree -Dincludesorg.apache.tomcat.embed:tomcat-embed-core -q | grep tomcat-embed-core echo Jakarta Servlet Version mvn dependency:tree -Dincludesjakarta.servlet:jakarta.servlet-api -q | grep jakarta.servlet-api每次环境变更后运行它5 秒内掌握核心版本信息。技巧二用Controller替代RestController测试欢迎页如果RestController返回 JSONindex.html无法测试可以临时加一个Controller public class IndexController { GetMapping(/) public String index() { return index; // 会跳转到 templates/index.html } }这样能绕过WelcomePageHandlerMapping直接验证 Controller 层是否正常。技巧三IDEA 启动时强制刷新依赖在 Run Configuration 的 “Before launch” 里勾选Build project并添加Run Maven goalclean compile。这样每次启动都保证是最新的 classpath。6. 从面试官视角看这个问题为什么它常出现在 Spring Boot 面试题中如果你正在准备 Spring Boot 面试这个问题绝不是考你“会不会降版本”而是考察你对Java Web 生态演进、框架底层机制、以及工程化排错能力的综合理解。面试官问“getHttpServletMapping报错怎么解决”期待听到的不是步骤而是你的思考链条。6.1 面试官想考察的三个维度第一维度生态演进认知你能说出 Jakarta EE 迁移的背景吗为什么 Spring Boot 3.x 必须放弃javax.*Servlet 4.0、5.0、6.0 的核心差异是什么getHttpServletMapping解决了什么历史问题这背后反映的是 Java 生态从 Oracle 主导到 Eclipse 基金会主导的权力转移你了解吗第二维度框架原理穿透力WelcomePageHandlerMapping是如何工作的它和ResourceHttpRequestHandler是什么关系DispatcherServlet的init()方法里getServletConfig().getInitParameter(contextConfigLocation)是做什么的如果你用EnableWebMvc关闭了 Spring Boot 的自动配置欢迎页功能会怎样为什么第三维度工程化排错能力当你看到NoSuchMethodError第一反应是查什么答先看类加载路径再看依赖树最后看源码如何用最小成本验证是环境问题还是代码问题答用curl -v和jps/jstack而不是反复重启如果客户生产环境不允许升级 Tomcat你有哪些替代方案答用Controller手动返回视图或用 Nginx 做静态资源代理6.2 高分回答模板供参考“这个问题我遇到过三次每次原因都不一样。第一次是 Maven 依赖传递引入了javax.servlet-api-3.1.0我用mvn dependency:tree -Dincludesjavax.servlet定位并exclusion掉第二次是公司 Nexus 仓库的 Tomcat 10.1.x jar 被覆盖我清理了本地仓库并联系运维修复第三次最有趣——是前端同学在index.html里写了script src/js/app.js/script但app.js文件名大小写写错了App.js导致 404而浏览器控制台只报 JS 加载失败掩盖了真正的getHttpServletMapping错误。所以我现在排查这类问题第一步永远是curl -v http://localhost:8080/看原始响应第二步jpsjstack看类加载第三步才看代码。因为 90% 的‘框架报错’其实都是环境或配置的锅。”这个回答展示了你有实战经验、有系统性思维、有工具链意识而且知道如何把复杂问题拆解成可验证的原子步骤。这才是面试官想看到的“资深开发者”画像。7. 后续扩展方向当你要对接真实业务时解决了localhost:8080的欢迎页问题只是万里长征第一步。在真实项目中你很快会遇到更复杂的场景7.1 前后端分离部署下的静态资源处理如果你的前端是 Vue/React构建产物放在dist/目录需要 Spring Boot 作为后端 API 网关同时托管前端静态资源。这时index.html不再是欢迎页而是 SPA 的入口。你需要配置spring.web.resources.add-mappingstrue默认 true设置spring.web.resources.static-locationsclasspath:/static/,file:./dist/添加Controller处理所有未匹配的 GET 请求返回index.html让前端路由生效Controller public class SpaController { GetMapping(value /**/{[a-z]}*) public String forwardToIndex() { return forward:/index.html; } }7.2 容器化部署时的路径映射Docker 中-v ./dist:/app/static将前端构建产物挂载到容器内但 Spring Boot 默认只扫描classpath:/static/。你需要FROM openjdk:17-jdk-slim COPY target/myapp.jar app.jar COPY dist/ /app/static/ # 将 dist 拷贝到容器内 ENTRYPOINT [java,-Dspring.web.resources.static-locationsfile:/app/static/,classpath:/static/,-jar,app.jar]7.3 安全加固禁用目录遍历与敏感文件访问生产环境必须防止http://localhost:8080/WEB-INF/web.xml这类路径泄露。Spring Boot 3.x 默认已禁用但如果你自定义了ResourceHttpRequestHandler要确保Bean public WebMvcConfigurer webMvcConfigurer() { return new WebMvcConfigurer() { Override public void addResourceHandlers(ResourceHandlerRegistry registry) { registry.addResourceHandler(/static/**) .addResourceLocations(classpath:/static/) .setCachePeriod(3600) .resourceChain(true) .addResolver(new PathResourceResolver() { Override protected Resource resolveResourceInternal(HttpServletRequest request, String requestPath, List? extends Resource locations, ResourceResolverChain chain) { // 拦截非法路径 if (requestPath.contains(..) || requestPath.contains(WEB-INF) || requestPath.contains(META-INF)) { return null; } return super.resolveResourceInternal(request, requestPath, locations, chain); } }); } }; }这些问题每一个都比getHttpServletMapping报错更贴近真实业务。而解决它们的基础正是你今天对 Servlet 规范、Spring Boot 自动配置、以及类加载机制的深入理解。所以别把这次报错当成一个 bug把它当作打开 Java Web 底层世界的一把钥匙。