企业官网建设流程全解析

1. 问题本质：不是“访问不了”，而是“Spring Boot 3.x 的 Servlet API 断层了”

你敲下http://localhost:8080，浏览器空白页或报错javax.servlet.http.HttpServletRequest.getHttpServletMapping()，第一反应是“Tomcat挂了？”、“端口被占了？”、“index.html没放对位置？”。但真正卡住你的，根本不是这些表层问题——而是你正站在一个技术代际断层的边缘：Spring Boot 3.x（基于 Jakarta EE 9+）彻底废弃了javax.*包名，全面迁移到jakarta.*。那个报错里的javax.servlet.http.HttpServletRequest，在 Spring Boot 3.0+ 的世界里，已经是个“不存在的类”。

这不是配置错误，不是路径问题，更不是IDE缓存惹的祸。这是 Java Web 生态十年一遇的命名空间大迁徙。就像把所有“北京”路牌一夜之间换成“京都市”，你按旧地图找“北京市朝阳区建国门内大街1号”，导航只会显示“地址不存在”。getHttpServletMapping()这个方法，在javax.servlet下确实存在（Servlet 4.0），但在jakarta.servlet下，它被重构、重命名、甚至拆分到了不同接口中。你的代码或依赖还在用老包名调用，JVM 加载器直接抛出NoClassDefFoundError或NoSuchMethodError——连堆栈都懒得给你多打一行。

我去年帮三个团队做 Spring Boot 2.7 → 3.1 升级，80% 的“启动成功但访问报错”案例，根源都在这里。尤其当你用的是较新的 JDK 17/21 + Spring Boot 3.2，默认就是 Jakarta EE 9+ 栈。而index.html无法加载，往往是因为 Spring MVC 的静态资源处理器、欢迎页逻辑、甚至 DispatcherServlet 初始化阶段，内部就隐式调用了HttpServletRequest的 Jakarta 版本方法。一旦你项目里混入了任何javax.servlet相关的 JAR（比如老版本的servlet-api.jar、jsp-api.jar，或者某些国产中间件 SDK），冲突立刻爆发。

更隐蔽的是：IDEA 创建新项目时默认选 Spring Boot 3.x，但很多教程、博客、甚至公司脚手架模板还停留在 2.x 时代。你复制粘贴一段“完美可用”的WebMvcConfigurer配置，里面写着@Override public void addViewControllers(ViewControllerRegistry registry)，看似没问题，可如果它底层依赖javax.servlet的某个抽象类，编译能过，运行必崩。这种“伪兼容”比明摆着的报错更难排查。

所以，别急着改application.yml的server.port，也先别清.m2仓库。第一步，请打开你的pom.xml或build.gradle，用 Ctrl+F 搜javax.servlet—— 如果搜到，恭喜，你已锁定罪魁祸首。接下来的所有操作，都是围绕“如何让整个应用栈干净地站在jakarta.*这一边”展开。这不仅是解决一个 404，更是给你的项目打上现代 Java Web 的合规认证。

2. 根源深挖：从 Servlet 规范演进看 Jakarta 迁移的必然性

要真正理解为什么getHttpServletMapping()突然消失，得回溯 Servlet 规范的“产权变更史”。这不是 Spring Boot 的任性，而是整个 Java EE 生态的集体转身。

2.1 Servlet 4.0（Java EE 8）与 Jakarta EE 9 的分水岭

• Servlet 4.0（2017年发布）：属于 Oracle 主导的 Java EE 8 规范。所有核心类都在javax.servlet.*包下，HttpServletRequest接口定义了getHttpServletMapping()方法，用于获取当前请求映射到的HttpServletMapping对象（包含 servlet 名称、路径匹配模式等）。这是当时标准的、稳定的 API。

• 2017年10月，Oracle 将 Java EE 交给 Eclipse 基金会。从此，“Java EE” 正式更名为“Jakarta EE”。名字变更背后是法律和商标权的彻底切割。Eclipse 基金会不能继续使用javax.*这个 Oracle 拥有的包名前缀。

• Jakarta EE 9（2020年发布）：这是第一次“大清洗”。所有规范包名从javax.*全面升级为jakarta.*。javax.servlet.*→jakarta.servlet.*，javax.ws.rs.*→jakarta.ws.rs.*，javax.persistence.*→jakarta.persistence.*。这不是简单的字符串替换，而是二进制不兼容的断裂。一个编译好的javax.servlet.Filter类，在 Jakarta EE 9 的容器里根本无法加载。

2.2 Spring Boot 的响应：拥抱 Jakarta，放弃向后兼容

Spring Boot 作为最主流的 Java Web 框架，必须紧跟规范。其策略非常清晰：

• Spring Boot 2.5.x 是最后一个支持 Java EE 8（javax.*）的主版本。它默认使用 Tomcat 9（Servlet 4.0），底层依赖javax.servlet-api:4.0.1。

• Spring Boot 3.0.x（2022年11月发布）是 Jakarta EE 9+ 的原生支持者。它强制要求：

  • JDK 17+（最低）
  • Tomcat 10+（Servlet 5.0，jakarta.servlet.*）
  • 所有 Spring 模块（spring-web, spring-webmvc）全部重构为jakarta.*依赖
  • spring-boot-starter-web内置的spring-boot-starter-tomcat，指向的是tomcat-jakarta-servlet-api

提示：getHttpServletMapping()方法在jakarta.servlet.http.HttpServletRequest中依然存在，但它的返回类型从javax.servlet.http.HttpServletMapping变成了jakarta.servlet.http.HttpServletMapping。如果你的代码或某个第三方库，硬编码引用了javax.servlet.http.HttpServletMapping，哪怕只是一行import javax.servlet.http.HttpServletMapping;，编译期可能通过（如果 IDE 缓存了旧包），但运行时 JVM 会因类加载器找不到javax.servlet.http.HttpServletMapping而失败。这就是典型的“编译时 OK，运行时爆炸”。

2.3 为什么你的index.html特别容易中招？

静态资源处理是 Spring MVC 的“门面”，也是 Jakarta 迁移中最易暴露的环节：

• 欢迎页机制：Spring Boot 默认将/请求映射到index.html。这个逻辑由WelcomePageHandlerMapping实现，它内部会调用HttpServletRequest.getServletPath()和getHttpServletMapping()来判断请求是否匹配欢迎页规则。一旦HttpServletRequest实例是jakarta.servlet.http.HttpServletRequest，而你的某段自定义代码（比如一个Filter或Interceptor）试图用javax.servlet方式去 cast 它，就会立即触发ClassCastException。

• 静态资源处理器：ResourceHttpRequestHandler在处理index.html时，会检查HttpServletRequest的getServletContext()，而ServletContext在 Jakarta 下也变成了jakarta.servlet.ServletContext。如果项目里混入了老版本的commons-fileupload（它依赖javax.servlet），上传组件初始化时就会尝试获取javax.servlet.ServletContext，导致整个静态资源链路崩溃。

• Thymeleaf / Freemarker 模板引擎：它们的ViewResolver在渲染index.html时，同样深度依赖HttpServletRequest的 Jakarta 版本。一个过时的thymeleaf-spring4依赖（而非thymeleaf-spring6），就是完美的“定时炸弹”。

所以，localhost:8080不显示index.html，表面是 HTTP 404 或 500，根子上是你整个 Web 容器的“语言体系”发生了切换，而你的项目里还残留着旧世界的“方言词典”。

3. 实操诊断：三步精准定位 Jakarta 冲突源

别猜，别试，用数据说话。下面这套诊断流程，是我在线上环境快速定位 Jakarta 冲突的“黄金三角”，每一步都有明确的输出和判断依据。

3.1 第一步：检查项目构建产物中的javax.*残留（最致命）

这是 90% 问题的起点。打开终端，进入你的项目根目录：

# Maven 项目：生成依赖树，过滤 javax mvn dependency:tree | grep "javax\." # Gradle 项目：生成依赖报告 ./gradlew dependencies --configuration compileClasspath | grep "javax\."

重点关注以下几类“危险信号”：

注意：grep "javax\."会漏掉一些间接依赖。更保险的做法是：

# 查看最终打包的 WAR/JAR 中实际包含哪些 javax 类 jar -tf target/your-app-1.0.0.jar | grep "javax/servlet"

如果输出非空，说明javax.servlet类被打进了最终包，100% 会冲突。

3.2 第二步：验证运行时类加载器的真实面孔

编译期依赖树只是“纸面信息”，运行时 JVM 加载的才是真相。在你的ApplicationRunner或CommandLineRunner中加入这段诊断代码：

@Component public class JakartaDiagnosticRunner implements ApplicationRunner { @Override public void run(ApplicationArguments args) throws Exception { // 1. 打印 HttpServletRequest 的真实类名 HttpServletRequest request = null; // 这里需要一个真实的 request 实例 // 通常在 Controller 里获取，但为了启动时诊断，我们模拟一个 // 更简单：直接打印 ClassLoader 加载的 Servlet API 类 System.out.println("=== Runtime Servlet API Check ==="); try { Class<?> jakartaReq = Class.forName("jakarta.servlet.http.HttpServletRequest"); System.out.println("✅ jakarta.servlet.http.HttpServletRequest found: " + jakartaReq.getPackage().getName()); } catch (ClassNotFoundException e) { System.out.println("❌ jakarta.servlet.http.HttpServletRequest NOT FOUND!"); } try { Class<?> javaxReq = Class.forName("javax.servlet.http.HttpServletRequest"); System.out.println("⚠️ javax.servlet.http.HttpServletRequest found! (CONFLICT DETECTED)"); } catch (ClassNotFoundException e) { System.out.println("✅ javax.servlet.http.HttpServletRequest NOT FOUND (Clean!)"); } // 2. 检查 Tomcat 版本 String tomcatVersion = System.getProperty("catalina.version", "Unknown"); System.out.println("Tomcat Version: " + tomcatVersion); } }

启动应用，观察控制台输出。理想状态是：

=== Runtime Servlet API Check === ✅ jakarta.servlet.http.HttpServletRequest found: jakarta.servlet.http ✅ javax.servlet.http.HttpServletRequest NOT FOUND (Clean!) Tomcat Version: Apache Tomcat/10.1.15

如果看到⚠️ javax.servlet.http.HttpServletRequest found!，说明你的 classpath 里一定混入了javax.servlet-api的 JAR，必须回到第一步彻底清理。

3.3 第三步：抓取 HTTP 请求的完整生命周期日志（终极证据）

当以上两步都“干净”，但index.html还是 404，问题可能出在 Spring MVC 的内部路由。开启 DEBUG 日志，精准捕获 DispatcherServlet 的决策过程：

在application.yml中添加：

logging: level: org.springframework.web.servlet.DispatcherServlet: DEBUG org.springframework.web.servlet.handler.SimpleUrlHandlerMapping: DEBUG org.springframework.web.servlet.resource.ResourceHttpRequestHandler: DEBUG

重启应用，访问http://localhost:8080，查看日志。关键线索藏在这里：

• 正常流程：你会看到类似Mapped to ResourceHttpRequestHandler，然后ResourceHttpRequestHandler: Resolving resource [index.html]，最后ResourceHttpRequestHandler: Found resource [class path resource [static/index.html]]。

• 异常流程：如果看到No handler mapping found for [/]或ResourceHttpRequestHandler: No matching resources found，说明欢迎页映射根本没注册成功。这通常意味着WelcomePageHandlerMapping初始化失败，而失败原因，十有八九是它在构造时尝试调用了一个已被 Jakarta 迁移“阉割”的javax.servlet方法。

此时，再结合mvn dependency:tree的结果，就能 100% 锁定那个“偷偷摸摸”引入javax.servlet的依赖——它可能藏在一个你从未注意过的工具类库里，比如某个 Excel 导出组件、某个 PDF 生成工具，甚至是一个老旧的logback-classic版本（某些极老版本依赖javax.servlet做异步日志）。

4. 彻底修复：四套组合拳，覆盖所有迁移场景

诊断清楚后，修复就是一场精准手术。根据你的项目现状，选择对应的“手术方案”。没有万能药，只有对症下药。

4.1 方案一：全新项目，Spring Boot 3.x + Jakarta 原生（推荐新手）

如果你是从零开始，或者可以接受重构，这是最干净、最可持续的方案。核心原则：从创建项目那一刻起，就只和jakarta.*打交道。

步骤详解：

1. 创建项目时，严格指定 Spring Boot 版本：

   • 访问 https://start.spring.io
   • Project：Maven
   • Spring Boot：3.2.0（或最新稳定版）
   • Dependencies：Spring Web,Spring Boot DevTools
   • 关键！不要勾选任何带有legacy、old、2.x字样的依赖。特别是Spring Web Services（老版 SOAP）、Spring Security OAuth2（已废弃）。

2. 检查生成的pom.xml：

   <parent> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-parent</artifactId> <version>3.2.0</version> <!-- 确保是 3.x --> <relativePath/> </parent> <dependencies> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> <!-- 这个 starter 内部已声明 jakarta.servlet-api --> </dependency> </dependencies>

3. 放置index.html的正确位置：

   • src/main/resources/static/index.html（推荐，资源文件优先级高）
   • src/main/resources/public/index.html
   • src/main/resources/templates/index.html（需配合 Thymeleaf，且 Controller 返回"index"）

4. 验证application.yml无需额外配置：

   # Spring Boot 3.x 默认 welcome page 就是 static/index.html # 无需任何配置，只要文件存在，/ 请求自动映射 server: port: 8080

实操心得：我用这个方案初始化了 12 个新项目，0 冲突。最大的坑是——不要手贱去pom.xml里手动添加javax.servlet-api依赖。有些教程说“加个 servlet-api 依赖方便写 Filter”，这是 Spring Boot 2.x 的思维惯性，在 3.x 里纯属自找麻烦。Spring Boot 的spring-boot-starter-web已经为你准备好了所有 Jakarta 依赖，你只需要“用”，不需要“管”。

4.2 方案二：老项目升级，Spring Boot 2.7.x → 3.2.x（企业主力）

这是最常见的场景。你的项目跑得好好的，但老板说“要上 JDK 21，必须用 Spring Boot 3”。升级不是点鼠标，而是一场代码考古。

升级清单（必须逐项核对）：

最关键的web层迁移：

• 删除所有javax.servletimport：全局搜索import javax.servlet，全部删掉。Spring Boot 3.x 的@Controller,@RestController,@RequestMapping注解，底层已自动适配jakarta.servlet。

• 检查Filter和Interceptor：

  // ❌ Spring Boot 2.x 写法（会崩） @Component public class MyFilter implements Filter { @Override public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException { HttpServletRequest httpRequest = (HttpServletRequest) request; // 这里会 ClassCastException！ // ... 业务逻辑 } }

  // ✅ Spring Boot 3.x 正确写法 @Component public class MyFilter implements Filter { @Override public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException { // 直接使用 jakarta.servlet.http.HttpServletRequest if (request instanceof jakarta.servlet.http.HttpServletRequest) { jakarta.servlet.http.HttpServletRequest httpRequest = (jakarta.servlet.http.HttpServletRequest) request; // ... 业务逻辑 } } }

• WebMvcConfigurer的addViewControllers：这个方法签名没变，但内部实现已切换。确保你的ViewControllerRegistry是org.springframework.web.servlet.config.annotation.ViewControllerRegistry，而不是老版本的org.springframework.web.servlet.config.annotation.WebMvcConfigurerAdapter（已废弃）。

注意事项：升级后，第一个启动成功的标志不是“Started Application”，而是http://localhost:8080能打开index.html。如果还是 404，立刻执行第 3 节的诊断三步法，99% 的问题都能定位。

4.3 方案三：混合部署，宝兰德（BES）替代 Tomcat（国产化刚需）

你提到springboot 如何最小改造使用内嵌宝兰德替换tomcat，这在国内政务、金融项目中非常典型。宝兰德（BES）是国产中间件，其 Servlet 容器实现了 Jakarta EE 9+ 规范，但细节有差异。

核心挑战：BES 的HttpServletRequest实现，与标准 Tomcat 的jakarta.servlet行为不完全一致。

最小改造步骤：

1. 排除默认 Tomcat：

   <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> <exclusions> <exclusion> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-tomcat</artifactId> </exclusion> </exclusions> </dependency>

2. 引入 BES 官方 Starter（假设为bes-spring-boot-starter）：

   <dependency> <groupId>com.bes</groupId> <artifactId>bes-spring-boot-starter</artifactId> <version>3.2.0</version> <!-- 必须与 Spring Boot 3.x 版本对齐 --> </dependency>

3. 关键配置application.yml：

   server: # BES 的端口配置方式与 Tomcat 不同 bes: http: port: 8080 host: 0.0.0.0 # 关闭 Tomcat 相关配置 tomcat: max-connections: 0 # 无效，但显式关闭避免混淆

4. index.html加载的特殊处理： BES 对静态资源的welcome-file-list解析有时更严格。必须在src/main/webapp/WEB-INF/web.xml中显式声明：

   <?xml version="1.0" encoding="UTF-8"?> <web-app xmlns="http://xmlns.jcp.org/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/web-app_4_0.xsd" version="4.0"> <welcome-file-list> <welcome-file>index.html</welcome-file> </welcome-file-list> </web-app>

   提示：src/main/webapp/WEB-INF/web.xml在 Spring Boot 项目中默认不存在，需要你手动创建。这是 BES 的“老派”要求，Spring Boot 的自动配置对此无感，必须靠传统web.xml“兜底”。

5. 测试getHttpServletMapping()的兼容性： 写一个最简 Controller：

   @RestController public class TestController { @GetMapping("/test-mapping") public String testMapping(HttpServletRequest request) { // BES 的 HttpServletRequest 实现，此方法返回值可能为空或格式不同 HttpServletMapping mapping = request.getHttpServletMapping(); return "Mapping: " + (mapping == null ? "NULL" : mapping.getPattern()); } }

   访问/test-mapping，如果返回NULL，说明 BES 的实现未完全遵循 Jakarta EE 9 规范，你需要在业务代码中做null判断，不能直接调用mapping.getPattern()。

4.4 方案四：紧急回滚，退回 Spring Boot 2.7.x（临时救火）

当上线 deadline 压顶，而升级风险不可控时，回滚是最务实的选择。但“回滚”不是简单改个版本号。

安全回滚 checklist：

• JDK 版本锁定：pom.xml中<java.version>17</java.version>改为<java.version>11</java.version>，并确保JAVA_HOME指向 JDK 11。

• Spring Boot Parent 版本：

  <parent> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-parent</artifactId> <version>2.7.18</version> <!-- 2.7.x 最后一个维护版 --> <relativePath/> </parent>

• 所有 Starter 依赖版本对齐：spring-boot-starter-web、spring-boot-starter-data-jpa等，必须使用2.7.18对应的版本。绝对禁止混合使用2.7.x的 parent 和3.x的 starter。

• application.yml中移除 Jakarta 专属配置：如spring.mvc.pathmatch.matching-strategy: ant_path_matcher（Spring Boot 2.7.x 默认ant_path_matcher，3.x 改为path_pattern_parser），回滚后必须删除或注释掉。

• 重新验证index.html：回滚后，localhost:8080应该立刻恢复正常。如果还是不行，说明问题根本不在 Spring Boot 版本，而是你的index.html文件本身权限不对、路径放错，或者 Nginx/Apache 反向代理配置干扰了/请求。

实操心得：我做过 3 次紧急回滚，最长的一次花了 4 小时。回滚的最大陷阱是“依赖污染”。开发同学在升级过程中，可能已经把jakarta.servlet-api的 JAR 手动拷贝到了lib目录，或者在pom.xml里加了provided作用域的javax.servlet-api。回滚前，务必执行第 3 节的诊断三步法，确保 classpath 干净。否则，你回滚了 Spring Boot，却留下了一个javax.servlet的“幽灵”，问题照旧。

5. 常见问题与避坑指南：那些文档里不会写的血泪教训

纸上谈兵终觉浅，下面这些，全是我在客户现场、线上巡检、Code Review 中亲手踩出来的坑。没有理论，全是实录。

5.1 问题速查表：症状、原因、解决方案

5.2 独家避坑技巧：提升效率的实战经验

• 技巧一：用mvn clean compile -X查看详细依赖解析
  当mvn dependency:tree结果模糊时，加上-X参数（debug 模式）：

  mvn clean compile -X 2>&1 | grep -A 5 -B 5 "javax\.servlet"

  这会输出 Maven 解析依赖的完整决策日志，精确告诉你哪个 POM 的哪一行，引入了javax.servlet-api。

• 技巧二：IDEA 的 Dependency Analyzer 是神器
  右键点击pom.xml→Maven→Show Dependencies。IDEA 会以图形化方式展示依赖树，并高亮显示冲突（红色节点）。点击冲突节点，右键Exclude，即可一键排除。

• 技巧三：index.html的 MIME Type 陷阱
  有时index.html能加载，但浏览器显示乱码或空白。检查响应头Content-Type。Spring Boot 3.x 默认是text/html;charset=UTF-8。如果看到text/html;charset=ISO-8859-1，说明你的index.html文件本身保存编码不是 UTF-8。用 VS Code 打开index.html，右下角看编码，点击切换为UTF-8 with BOM（或直接Save with Encoding→UTF-8）。

• 技巧四：Docker 部署时的 JDK 版本陷阱
  本地用 JDK 17 开发，Dockerfile 却写FROM openjdk:11-jre-slim。镜像里是 JDK 11，运行 Spring Boot 3.x 必然失败。Dockerfile 必须同步：

  FROM openjdk:17-jre-slim # 或更推荐 FROM eclipse-temurin:17-jre-focal COPY target/*.jar app.jar ENTRYPOINT ["java","-jar","/app.jar"]

• 技巧五：getHttpServletMapping()的替代方案
  如果你确实需要获取请求的 servlet 映射信息，又不想被 Jakarta 版本差异困扰，最稳妥的方式是放弃getHttpServletMapping()，改用HttpServletRequest.getServletPath()和HttpServletRequest.getRequestURI()组合计算：

  // 通用、安全、跨版本 String servletPath = request.getServletPath(); // 例如 "/api/user" String requestURI = request.getRequestURI(); // 例如 "/api/user/123" String pathInfo = requestURI.substring(servletPath.length()); // "/123"

  这比依赖一个可能在不同容器里行为不一的getHttpServletMapping()方法，要可靠得多。

5.3 面试高频题解析：为什么 Spring Boot 3.x 要强制 Jakarta？

这个问题常出现在高级 Java 工程师面试中。答案不能只说“因为版权”，要体现架构视野：

“强制 Jakarta 迁移，核心是解耦与主权。Java EE 时代，Oracle 拥有规范制定权和商标权，社区创新受掣肘。迁移到 Jakarta EE 后，Eclipse 基金会作为中立组织，能更快地响应云原生、Serverless 等新需求，比如 Jakarta EE 10 新增的@Asynchronous和@Transactional的云原生语义。Spring Boot 3.x 拥抱 Jakarta，不是被动跟随，而是主动选择一个开放、快速迭代、不受单一厂商控制的未来。对开发者而言，这意味着更少的 vendor lock-in，更多的技术选择自由。代价是短期的迁移阵痛，但长期看，这是 Java Web 生态走向成熟的必经之路。”

这句话，我讲过 7 次，每次都被面试官点头认可。因为它把技术决策，上升到了生态战略层面。

6. 后续演进：Spring Boot 3.x 的稳定与未来

解决了localhost:8080的index.html问题，你的项目才刚刚站上 Spring Boot 3.x 的起跑线。接下来，还有更广阔的天地。

6.1 Spring Boot 3.2.x 的稳定性红利

Spring Boot 3.2.x（2023年10月发布）是目前最成熟、最推荐的生产版本。它带来了几个关键改进：

• GraalVM 原生镜像支持正式 GA：你可以用native-image将 Spring Boot 应用编译成单个二进制文件，启动时间从秒级降到毫秒级，内存占用降低 70%。对于index.html这种静态资源服务，原生镜像简直是“神装”。命令很简单：

  ./mvnw spring-boot:build-image # 或 ./mvnw native:compile

• Observability（可观测性）深度集成：spring-boot-starter-actuator+micrometer-registry-prometheus，开箱即用。/actuator/metrics/http.server.requests会自动统计每个 URL 的 QPS、延迟、错误率。你再也不用手写监控埋点，index.html的访问量、成功率，一目了然。

• Spring Security 6.x 的零信任模型：@EnableMethodSecurity替代了老式的@EnableGlobalMethodSecurity，权限控制粒度更细。你可以轻松实现