企业官网建设流程全解析

简介：本资源是面向Java后端工程师、Spring Boot初学者及备战架构师岗位面试者的专项题库，聚焦Spring Boot核心原理与高频考点，覆盖基础知识、自动配置机制、Starter依赖管理、内嵌容器、Actuator监控、DevTools热部署等33道典型问题及详实解析。资源为单文件Word文档（.docx），体积精简仅25KB，内容结构清晰、排版规范，便于快速查阅与离线学习。已有319人下载学习，适合用于面试前突击复习、技术查漏补缺或团队内部技术分享材料。每道题均含概念阐释、原理剖析与实践要点，如JavaConfig的类型安全优势、YAML分层配置价值、Spring Initializr项目创建流程、Actuator端点监控方式等，兼具理论深度与落地指导性。

1. Spring Boot 面试不考“Hello World”，考的是自动配置的「黑匣子」怎么拆

你背熟了@SpringBootApplication的三个组成注解，却在面试官问“为什么加了spring-boot-starter-data-jpa，连DataSource都没配，项目就能连上数据库？”时卡壳——这不是知识盲区，是考点错位。Spring Boot 架构师级面试早已越过“是什么”“有什么优点”的入门层，直击自动配置生效链路、条件装配失效场景、多环境配置加载冲突、Actuator端点安全暴露边界、Starter依赖传递污染这五大硬核模块。33题里，真正拉开差距的不是第1题“什么是Spring Boot”，而是第14、28、29、30、33题构成的「自动配置五连问」：它要求你不仅能复述@EnableAutoConfiguration从spring.factories读类，更要能画出BeanDefinitionRegistryPostProcessor → ConfigurationClassPostProcessor → @ConditionalOnClass校验 → @ConditionalOnMissingBean兜底 → EnvironmentPropertySourceLoader加载顺序的完整执行流；要能说出application.yml中spring.profiles.active=dev和--spring.profiles.active=test启动参数谁优先、为什么bootstrap.yml在Cloud场景下不可被覆盖；更要能在面试白板上手写一个自定义Starter的META-INF/spring.factories注册方式，并解释其与autoconfigure模块的协作边界。这份33题资源，本质是一份面向真实生产排障能力的考点切片图——适合已用Spring Boot交付过2个以上中型项目、正冲击高级/架构岗的开发者，不是给刚写完CRUD的新人看的“语法手册”。

2. 高频考点：自动配置原理与Starter机制（含真题逐题拆解）

2.1 自动配置的「三重门」：@EnableAutoConfiguration如何精准开关Bean？

Spring Boot自动配置不是魔法，而是一套可追溯、可干预、可调试的条件化装配系统。它的核心逻辑分三层：

• 第一重门：入口发现
  @SpringBootApplication隐式包含@EnableAutoConfiguration，该注解通过ImportSelector导入AutoConfigurationImportSelector。后者读取所有jar包中META-INF/spring.factories文件里org.springframework.boot.autoconfigure.EnableAutoConfiguration=开头的全限定类名列表。注意：这个读取发生在Spring容器刷新前的BeanDefinition注册阶段，早于任何@Bean方法执行。

• 第二重门：条件裁决
  每个xxxAutoConfiguration类都标注了大量@Conditional注解，最常见的是：

  • @ConditionalOnClass({ DataSource.class })：要求类路径存在指定类（非实例化，仅检查ClassLoader是否能load）；
  • @ConditionalOnMissingBean(type = "javax.sql.DataSource")：容器中尚未注册该类型Bean才生效；
  • @ConditionalOnProperty(prefix = "spring.datasource", name = "enabled", havingValue = "true", matchIfMissing = true)：配置项存在且值匹配，matchIfMissing=true表示配置项不存在时也通过。

• 第三重门：属性绑定与组件注入
  条件通过后，AutoConfiguration类中的@Bean方法开始执行。这些方法通常依赖一个xxxProperties类（如DataSourceProperties），该类用@ConfigurationProperties(prefix="spring.datasource")绑定配置文件中的属性。关键点：Properties类本身也是由Spring Boot自动注册的Bean，且其字段命名必须严格匹配yml中的key层级（如spring.datasource.hikari.maximum-pool-size → maximumPoolSize）。

提示：面试官常追问“如果我在application.yml里写了spring.datasource.url但没写driver-class-name，HikariCP会报错吗？”——答案是会，因为DataSourceProperties的url字段有@NotBlank校验，且HikariConfig在构造时强制校验driverClassName，此时自动配置虽已注入DataSourceProperties，但后续DataSourceBuilder.build()会抛异常。这说明条件装配成功 ≠ 应用启动成功。

2.2 Starter的本质：不是依赖集合，而是「约定大于配置」的契约包

starter不是简单的pom依赖聚合，它是Spring Boot生态的能力交付单元，必须同时满足三个契约：

1. 自动配置契约：提供xxxAutoConfiguration类，实现条件化Bean装配；
2. 属性绑定契约：提供xxxProperties类，将配置文件映射为Java对象；
3. 依赖传递契约：在pom.xml中声明compile scope的“能力依赖”（如spring-boot-starter-jdbc）和optional scope的“实现依赖”（如HikariCP），确保使用者可自由替换底层实现。

以spring-boot-starter-web为例，其pom.xml中：

<dependencies> <!-- 能力契约：定义WebMvcConfigurer等接口 --> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter</artifactId> </dependency> <!-- 实现契约：内嵌Tomcat --> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-tomcat</artifactId> <scope>compile</scope> </dependency> <!-- 可选契约：用户可排除此依赖，换Jetty --> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-validation</artifactId> <optional>true</optional> </dependency> </dependencies>

注意：面试官可能让你现场设计一个mybatis-spring-boot-starter的最小结构。正确答案必须包含：①META-INF/spring.factories中注册MyBatisAutoConfiguration；②MyBatisProperties绑定mybatis.mapper-locations等配置；③ pom中声明mybatis-spring和mybatis为compile依赖，spring-boot-starter-jdbc为optional（因用户可能用JPA）。

2.3 真题实战：第14、29、30题组合拳（自动配置原理三连问）

题目14（原文）：springboot自动配置的原理？
题目29（原文）：自动配置原理？
题目30（原文）：怎么用好自动配置，精髓？

这三题实为同一考点的递进式考察，面试官要听的不是教科书定义，而是你能否把源码级流程转化为排障语言。以下是标准答题节奏：

第一步：定位入口（答14题）

“自动配置始于@SpringBootApplication注解，它通过@EnableAutoConfiguration触发AutoConfigurationImportSelector。这个Selector会扫描所有jar包的META-INF/spring.factories文件，加载其中org.springframework.boot.autoconfigure.EnableAutoConfiguration键对应的全类名列表。比如spring-boot-autoconfigure.jar里就定义了100+个AutoConfiguration类。”

第二步：描述执行链（答29题）

“加载后的每个AutoConfiguration类都是一个@Configuration类，但它们不会无条件生效。Spring Boot在创建BeanDefinition时，会解析其上的@Conditional系列注解。例如DataSourceAutoConfiguration上有@ConditionalOnClass(DataSource.class)和@ConditionalOnMissingBean(DataSource.class)，这意味着只有当类路径有DataSource且容器还没DataSource Bean时，它才注册HikariDataSource。所有条件判断都在BeanDefinition注册阶段完成，不涉及Bean实例化。”

第三步：给出落地策略（答30题）

“用好自动配置的关键是‘查-看-改’三步法：
① 查：启动时加--debug参数，控制台会输出‘CONDITIONS EVALUATION REPORT’，列出所有AutoConfiguration类的匹配/不匹配原因；
② 看：在IDEA中Ctrl+Click进入某个AutoConfiguration类（如RedisAutoConfiguration），看它依赖的RedisProperties和@Conditional条件；
③ 改：若需定制，优先在application.yml中修改对应prefix的属性（如spring.redis.timeout），而非重写AutoConfiguration——这是Spring Boot‘约定大于配置’的设计哲学。”

3. 高频考点：配置管理与多环境加载（含真题逐题拆解）

3.1 application.yml vs bootstrap.yml：谁先加载？谁不能被覆盖？

Spring Boot的配置加载不是简单的“后加载覆盖前加载”，而是分阶段、分来源、分优先级的精密体系。核心规则如下：

关键细节：

• --spring.profiles.active=prod启动参数 >SPRING_PROFILES_ACTIVE环境变量 >application.yml中spring.profiles.active配置；
• bootstrap.yml中spring.cloud.config.enabled=false会直接禁用Config Client，此时application.yml里的配置中心地址无效；
• 若同时存在bootstrap.yml和application.yml，且都定义了spring.application.name，则bootstrap.yml的值会作为应用名注册到Config Server，application.yml的值会被忽略——这是很多候选人踩坑的点。

提示：面试官可能问“为什么微服务要用bootstrap.yml而不是application.yml连配置中心？”——答案是：Config Client需要在Spring Context创建前就获取配置，否则像@Value("${db.url}")这种注入会在Context初始化时报错。bootstrap.yml正是为此设计的“预加载配置层”。

3.2 Profile激活的四种方式及优先级陷阱

Profile不是简单的“开发/测试/生产”标签，而是配置隔离的运行时开关。Spring Boot支持四种激活方式，优先级从高到低：

1. 命令行参数：java -jar app.jar --spring.profiles.active=prod,mysql

   • ✅ 支持多profile逗号分隔
   • ❌ 无法在Docker中用ENV变量替代（ENV变量优先级低于命令行）

2. JVM系统属性：java -Dspring.profiles.active=test -jar app.jar

   • ✅ 在IDEA Run Configuration中设置VM options即可
   • ⚠️ 若同时设了-D和--，--优先级更高

3. 操作系统环境变量：export SPRING_PROFILES_ACTIVE=dev

   • ✅ Docker中常用docker run -e SPRING_PROFILES_ACTIVE=prod
   • ❌ Windows PowerShell需用$env:SPRING_PROFILES_ACTIVE="dev"

4. application.yml内配置：spring: profiles: active: dev

   • ⚠️这是最低优先级！且一旦被更高优先级覆盖，此配置完全失效

血泪经验：某次线上事故源于Docker部署时，运维在k8s yaml中写了env: - name: SPRING_PROFILES_ACTIVE value: "prod"，但开发在application.yml里也写了spring.profiles.active: test。结果应用以prod启动，却加载了test的数据库配置（因application-test.yml被错误加载）——根本原因是profile激活方式只决定激活哪个profile，但配置文件加载还受spring.config.location和spring.config.name控制。正确做法是：生产环境禁用application.yml中的profile配置，全部由外部环境变量或启动参数控制。

3.3 真题实战：第18、23、28题组合（配置文件与Profile）

题目18（原文）：Spring Boot的核心配置文件有哪几个？它们的区别是什么？
题目23（原文）：什么是Spring Profiles？
题目28（原文）：配置文件的加载顺序？

这三题必须串联回答，展现配置体系全景。推荐结构化应答：

答18题（定义）：

“Spring Boot有两个核心配置文件：application.yml和bootstrap.yml。前者是主配置文件，用于定义应用自身的业务配置（如server.port、spring.datasource）；后者是引导配置文件，专为Spring Cloud设计，在ApplicationContext创建前加载，用于配置Config Client连接信息、加密解密密钥等基础设施参数。二者最大区别在于加载时机和作用域——bootstrap.yml的配置不可被application.yml覆盖，且其配置项仅对Config Client生效。”

答23题（场景）：

“Spring Profiles是配置分组机制，通过@Profile("dev")注解或spring.profiles.active属性激活特定配置块。典型场景有三：① 环境隔离：dev环境用H2内存库，prod用MySQL；② 功能开关：QA环境启用Swagger，生产环境禁用；③ 第三方服务降级：测试环境mock支付接口，生产调真实网关。关键技巧是使用@Profile("!prod")实现‘非生产环境启用’的反向逻辑。”

答28题（顺序）：

“配置加载顺序遵循‘外部优先、profile优先、后覆盖前’原则，具体为：

1. bootstrap-{profile}.yml（外部）→ 2.bootstrap.yml（外部）→ 3.application-{profile}.yml（外部）→ 4.application.yml（外部）→ 5.bootstrap-{profile}.yml（内部）→ 6.bootstrap.yml（内部）→ 7.application-{profile}.yml（内部）→ 8.application.yml（内部）。
   特别注意：若application-dev.yml和application-prod.yml同时存在，且spring.profiles.active=dev,prod，则dev配置会覆盖prod中同名属性——因为dev在active列表中位置更前。”

4. 易错点：自动配置失效、配置加载冲突、Actuator安全漏洞（高频翻车现场）

4.1 自动配置失效的三大“玄学”原因（面试必问）

错在哪：在application.yml中配置了spring.redis.host=localhost，但应用启动后RedisTemplate仍连不上，Debug发现RedisAutoConfiguration未生效。
为什么错：候选人只检查配置项是否存在，忽略了自动配置的前置条件。RedisAutoConfiguration要求：① 类路径有lettuce-core.jar或jedis.jar；② 容器中无RedisConnectionFactoryBean；③spring.redis.enabled=true（默认true）。若项目中手动定义了@Bean RedisConnectionFactory，则自动配置直接跳过。
怎么答对：启动时加--debug，查看CONDITIONS EVALUATION REPORT中RedisAutoConfiguration的Exclusions和Negative matches，定位具体不匹配的条件（如@ConditionalOnMissingBean不满足）。

错在哪：自定义了一个MyDataSourceProperties并用@ConfigurationProperties("my.datasource")绑定，但配置文件中my.datasource.url的值始终为null。
为什么错：@ConfigurationProperties类必须被Spring容器管理（即标注@Component或在@Configuration类中用@Bean返回），且需在启动类上加@EnableConfigurationProperties(MyDataSourceProperties.class)。若只加注解不注册，Spring Boot不会为其绑定属性。
怎么答对：两种正确姿势：①@Component @ConfigurationProperties("my.datasource")；②@ConfigurationProperties("my.datasource")+@EnableConfigurationProperties(MyDataSourceProperties.class)。推荐方案①，更简洁。

错在哪：在@SpringBootApplication上加了@EnableAutoConfiguration(exclude = {DataSourceAutoConfiguration.class})，但启动时仍报Failed to configure a DataSource。
为什么错：exclude参数只排除指定的AutoConfiguration类，但Spring Boot的启动检查（如DataSourceHealthIndicator）可能依赖其他组件。更彻底的方式是：① 排除DataSourceAutoConfiguration；② 排除DataSourceHealthIndicatorAutoConfiguration；③ 在application.yml中设management.health.db.show-details=never。
怎么答对：直接告诉面试官：“排除AutoConfiguration只是第一步，还需同步处理健康检查、指标监控等衍生组件，否则启动失败是必然的。”

4.2 配置加载冲突的致命陷阱（生产事故高发区）

错在哪：Docker部署时，-e SPRING_PROFILES_ACTIVE=prod和-v /conf:/config挂载了包含application-prod.yml的目录，但应用却加载了application-dev.yml。
为什么错：spring.config.location的优先级高于profile激活。若挂载的/config目录下有application.yml，它会覆盖所有profile配置——因为Spring Boot先加载spring.config.location指定的文件，再根据其中的spring.profiles.active去加载对应profile文件。
怎么答对：明确配置加载流程：① 解析spring.config.location；② 加载该路径下的application.yml；③ 读取其中的spring.profiles.active；④ 加载{location}/application-{profile}.yml。解决方案：挂载时指定-e SPRING_CONFIG_LOCATION=file:/config/，并在/config/application.yml中只写spring.profiles.active: prod，避免放其他配置。

错在哪：在bootstrap.yml中配置了spring.cloud.config.uri=http://config-server，但应用启动时报Connection refused，而Config Server明明在运行。
为什么错：bootstrap.yml的加载发生在ApplicationContext创建前，此时logging.level等日志配置尚未生效，导致网络错误堆栈被吞掉。更隐蔽的原因是：spring.cloud.config.fail-fast=true（默认false）未开启，应用会静默降级为本地配置。
怎么答对：生产环境必须设spring.cloud.config.fail-fast=true，并配合spring.cloud.config.retry.*参数。同时，在bootstrap.yml中显式配置logging.level.org.springframework.cloud.config.client.ConfigServicePropertySourceLocator=DEBUG，捕获底层HTTP请求详情。

4.3 Actuator端点的安全裸奔（架构师必答红线）

错在哪：为方便监控，开放了/actuator/health和/actuator/metrics，但未做任何权限控制，导致攻击者通过/actuator/env获取到数据库密码。
为什么错：Spring Boot 2.x默认只暴露/actuator/health和/actuator/info，其他端点需显式开启。但开发者常在application.yml中写management.endpoints.web.exposure.include=*，这等于把所有端点（包括/env、/beans、/mappings）全部暴露。
怎么答对：安全三原则：①最小暴露：只开必需端点，如management.endpoints.web.exposure.include=health,metrics,prometheus；②路径保护：用Spring Security配置/actuator/**需AUTHORITY_ACTUATOR角色；③敏感信息过滤：management.endpoint.env.show-values=WHEN_AUTHORIZED（默认为NEVER，但部分旧版本为ALWAYS）。终极方案是：生产环境禁用/env、/beans、/mappings，用Prometheus+Grafana替代Metrics拉取。

提示：面试官若问“如何让/actuator/health返回详细信息给运维，但对前端隐藏敏感字段？”，正确答案是：配置management.endpoint.health.show-details=when_authorized，并为运维账号分配ACTUATOR权限，前端调用时不带认证头则只返回status。

5. 高频考点：Actuator监控与微服务治理（含真题逐题拆解）

5.1 Actuator端点的生产级用法：不只是看健康状态

Actuator不是玩具，而是生产环境故障定位的瑞士军刀。33题中第8、33题直指其核心价值，但面试官想听的是你如何用它解决真实问题：

• /actuator/health：不只是返回UP/DOWN。通过show-details=always可看到各组件（db、redis、rabbitmq）的详细健康状态。更关键的是自定义HealthIndicator：

  @Component public class CustomDbHealthIndicator implements HealthIndicator { @Override public Health health() { try { // 执行轻量级SQL验证连接 jdbcTemplate.queryForObject("SELECT 1", Integer.class); return Health.up().withDetail("message", "DB OK").build(); } catch (Exception e) { return Health.down() .withDetail("error", e.getMessage()) .withDetail("timestamp", System.currentTimeMillis()) .build(); } } }

  关键点：HealthIndicator必须轻量（<100ms），不能执行耗时查询，否则影响K8s liveness probe。

• /actuator/metrics：不是只看JVM内存。它暴露了Micrometer指标，可对接Prometheus：

  management: endpoints: web: exposure: include: health,metrics,prometheus endpoint: prometheus: scrape-interval: 15s

  启动后访问/actuator/prometheus即可被Prometheus抓取，指标如http_server_requests_seconds_count{method="GET",status="200",uri="/api/user"}可直接用于APM告警。

• /actuator/threaddump：线程死锁的“后悔药”。当应用CPU飙升但无日志时，调用此端点生成jstack快照，用jstack -l <pid>对比分析线程状态。注意：生产环境需配合management.endpoint.threaddump.show-locks=true显示锁信息。

5.2 微服务集群监控：单点监控的“自杀式”方案

题目33问“如何监视所有Spring Boot微服务？”，答“每个服务开Actuator”是自杀式方案。架构师必须给出集中化、可扩展、低侵入的方案：

方案一：Prometheus + Grafana（推荐）

• 每个服务暴露/actuator/prometheus端点；
• Prometheus定时scrape所有服务的metrics；
• Grafana配置Dashboard展示全局QPS、错误率、P95延迟；
• 优势：无中心节点，Prometheus拉取模式天然抗单点故障；劣势：服务发现需配合Consul或K8s Service。

方案二：Spring Boot Admin（企业级）

• 单独部署Admin Server，所有微服务作为Client注册；
• Admin Server提供UI统一查看健康状态、JVM内存、线程、日志级别；
• 支持邮件/Webhook告警（如DOWN状态持续2分钟触发告警）；
• 关键配置：Client端需加spring.boot.admin.client.url=http://admin-server:8080，Server端加spring.boot.admin.ui.public-url=http://admin-server:8080。

方案三：ELK + 自定义Logback Appender（日志驱动）

• 所有服务配置Logback的<appender class="net.logstash.logback.appender.LogstashTcpSocketAppender">；
• 日志发送到Logstash，经Elasticsearch索引，Kibana可视化；
• 适用场景：需审计操作日志、追踪跨服务调用链（需集成Sleuth）。

提示：面试官可能追问“如果微服务有50个，Prometheus如何高效scrape？”，答案是：用Prometheus联邦模式——边缘Prometheus采集本机房服务，中心Prometheus从各边缘Prometheus拉取聚合指标，避免单点压力过大。

5.3 真题实战：第8、33题深度应答（监控体系设计）

题目8（原文）：Spring Boot中的监视器是什么？
题目33（原文）：我们如何监视所有Spring Boot微服务？

必须跳出“端点列表”层面，展现架构思维：

答8题（定义升维）：

“Spring Boot Actuator不是简单的监控工具，而是生产环境可观测性（Observability）的基石。它通过标准化的REST端点（如/health、/metrics、/threaddump）将应用内部状态外化，使运维人员无需登录服务器即可获取实时数据。更重要的是，它提供了SPI扩展点——你可以实现自定义Endpoint（如/actuator/db-migration-status）或HealthIndicator（如验证下游服务连通性），将业务逻辑的健康状态纳入监控体系。这才是Actuator的真正价值：把‘应用是否活着’升级为‘业务是否正常’。”

答33题（方案设计）：

“监视50个微服务绝不能靠人工点开50个/actuator/health。我推荐三级监控体系：
第一级：基础设施监控——用Prometheus抓取所有服务的JVM内存、GC次数、线程数，阈值告警（如老年代内存>85%）；
第二级：业务指标监控——在关键Controller加@Timed注解，暴露http.server.requests指标，用Grafana看各接口P95延迟和错误率；
第三级：调用链监控——集成Spring Cloud Sleuth + Zipkin，当订单服务调用支付服务超时，Zipkin能精准定位是网络延迟还是支付服务自身慢。
安全底线：所有Actuator端点必须用Spring Security保护，/actuator/env等敏感端点生产环境禁用，指标数据通过TLS加密传输。”

6. 答题心法：从“背答案”到“讲故事”的三步跃迁

面试不是知识复述，而是用技术叙事证明你解决过真实问题。我带过的几十位学员，从被问懵到拿下架构岗，靠的不是死记硬背33题，而是把每个考点转化成一个“我遇到过、我排查过、我解决过”的故事。以下是我的血泪经验总结：

6.1 把“原理”翻译成“排障流水线”

面试官问“自动配置原理”，别急着背@EnableAutoConfiguration。先说场景：

“去年我们有个服务上线后连不上Redis，日志只报‘Cannot determine embedded database driver class for database type NONE’。我当时第一反应是检查application.yml，但配置完全正确。后来加了--debug参数，发现RedisAutoConfiguration被@ConditionalOnMissingBean(RedisConnectionFactory.class)排除了——原来同事在配置类里手动定义了一个@Bean RedisConnectionFactory，但忘了加@ConditionalOnMissingBean。我删掉那个Bean，问题立刻解决。这件事让我深刻理解：自动配置不是万能的，它是一套精密的条件开关，而--debug就是打开这个开关的钥匙。”

这种回答，把抽象原理变成了可复现的排障动作，面试官瞬间知道你真干过。

6.2 用对比表格锚定“决策依据”

当被问“application.yml和bootstrap.yml怎么选？”，别罗列定义。甩出这张表，然后讲故事：

“这个表是我从三次生产事故里总结的。第一次把config uri放application.yml，服务启动失败；第二次把encrypt.key放application.yml，配置解密报错；第三次才明白：bootstrap.yml是‘信任根’，application.yml是‘业务层’，二者职责必须泾渭分明。”

6.3 用代码块证明“我亲手调通过”

面试官说“讲讲Actuator怎么用”，别光说理论。打开IDEA，现场敲两行关键代码：

// 自定义健康检查：验证下游服务可用性 @Component public class PaymentServiceHealthIndicator implements HealthIndicator { private final RestTemplate restTemplate; public PaymentServiceHealthIndicator(RestTemplate restTemplate) { this.restTemplate = restTemplate; } @Override public Health health() { try { String result = restTemplate.getForObject( "http://payment-service/actuator/health", String.class); return Health.up().withDetail("payment-service", result).build(); } catch (Exception e) { return Health.down() .withDetail("error", "Payment service unreachable") .build(); } } }

“这段代码我们线上跑了两年。当payment-service宕机时，/actuator/health会返回DOWN，K8s自动重启我们的服务。关键是RestTemplate要配置超时（connect-timeout=2s, read-timeout=2s），否则健康检查本身会拖垮整个应用。”

从那以后我每次写HealthIndicator，都强制走一遍超时配置、异常捕获、日志记录三步。希望帮到你。

本文还有配套的精品资源，点击获取