Spring Boot 核心与自动配置

• /actuator/conditions 展示条件评估报告
• 自动配置的匹配/不匹配原因
• 用 --debug 与 logging 输出条件评估报告

/actuator/conditions 端点是 Spring Boot Actuator 提供的条件评估报告端点，它展示每个自动配置类（AutoConfiguration）及其条件注解（如 @ConditionalOnClass、@ConditionalOnBean）的评估结果：哪些配置类被匹配（positiveMatches）、哪些未匹配（negativeMatches）及其未匹配原因。开发者据此诊断"为什么某个自动配置没生效"或"为什么被意外禁用"。除端点外，启动时加 --debug 参数或在日志配置中开启 debug 日志，也会在控制台输出 Spring Boot 的自动配置条件评估报告。

conditions 端点把"自动配置是否生效"这一黑盒透明化，是排查自动配置问题（如组件未注入、配置未加载）的第一手段。

• @Conditional 是条件装配的通用注解
• 自动配置类基于 @Conditional 系列注解生效
• 条件评估控制自动配置的加载

@Conditional 是 Spring 条件装配的通用注解，其 value 指定 Condition 实现类，根据条件评估结果决定是否注册 Bean 或配置类。Spring Boot 自动配置正是在此基础上构建：每个自动配置类（由 @AutoConfiguration 标注）都带有一组 @ConditionalOnClass/@ConditionalOnMissingBean/@ConditionalOnProperty 等条件注解，当这些条件满足时才加载对应自动配置。Spring Boot 通过 AutoConfigurationImportSelector 收集并评估自动配置类，结合条件注解决定哪些生效，实现"按需自动装配"。条件评估机制是自动配置与 @Conditional 协作的核心。

自动配置 = @Conditional 条件装配 + 自动配置类注册机制。条件注解让自动配置具备"智能判断是否生效"的能力，是 Spring Boot 开箱即用的基石。

• @ConditionalOnWebApplication 判断 Web 环境类型
• 条件类型（ANY/SERVLET/REACTIVE）
• 按环境差异化加载配置

@ConditionalOnWebApplication 用于判断当前应用是否为 Web 应用，并区分 Web 环境类型。其 type 属性可指定 ANY、SERVLET、REACTIVE 三种：SERVLET 表示基于 Servlet 的 MVC 应用，REACTIVE 表示基于 WebFlux 的反应式应用，ANY 表示任意 Web 环境。Spring Boot 通过它实现对不同 Web 应用差异化加载自动配置，例如仅在 Servlet 环境加载 WebMvcAutoConfiguration、仅在 Reactive 环境加载 WebFluxAutoConfiguration。非 Web 应用（如纯后台任务）则不会加载这些 Web 相关配置。判断依据是类路径中的 Web 相关类与容器类型。

该条件让"同一套 Spring Boot 自动配置适应 Servlet、Reactive、非 Web 三种环境"，是自动配置按环境适配的关键，也是 MVC 与 WebFlux 自动配置互不干扰的保证。

• Actuator 端点暴露敏感信息
• 通过 Spring Security 保护 /actuator/** 端点
• 认证与授权配置

Actuator 端点（如 /actuator/env、/actuator/heapdump、/actuator/configprops）可能暴露敏感配置与运行信息，必须通过 Spring Security 保护。协作方式：在 SecurityFilterChain 中为 /actuator/配置认证与授权规则，例如仅允许登录用户或具有特定角色的用户访问，使用 http.requestMatchers("/actuator/").hasRole("ADMIN") 等。同时可配合 management.endpoints.web.exposure.include 控制暴露哪些端点，配合 management.endpoint.health.show-details 控制健康详情是否对外。安全策略是"最小暴露 + 认证授权 + 流程中保护"。

Actuator 直接暴露敏感信息，安全是关键。Actuator 与 Security 的协作核心是"在 SecurityFilterChain 中为 Actuator 路径配置访问控制"，避免端点裸奔。

• Actuator 是生产级监控端点
• /health 健康检查、/metrics 指标、/info 信息
• 端点暴露与自定义

Spring Boot Actuator 是生产级监控组件，提供一系列端点暴露应用运行状态。核心端点：/actuator/health 返回健康检查状态（UP/DOWN，可展示各组件健康详情），/actuator/metrics 暴露 JVM、内存、HTTP 等指标（配合 Micrometer 与 Prometheus），/actuator/info 展示应用信息，/actuator/loggers 查看/修改日志级别，/actuator/env 暴露环境配置，/actuator/beans 展示 Bean 列表，/actuator/conditions 展示条件评估报告。端点通过 management.endpoints.web.exposure.include 控制暴露，默认仅暴露 health 与 info 等安全端点。

Actuator 把"运维监控"标准化为 HTTP 端点，与 Micrometer 指标体系结合可实现健康检查、指标采集、日志动态调整等生产运维能力。

• @Endpoint 定义自定义端点
• 操作注解（@ReadOperation/@WriteOperation/@DeleteOperation）
• @WebEndpoint 与 @JmxEndpoint

自定义 Actuator 端点通过 @Endpoint 注解定义，配合 @ReadOperation（GET）、@WriteOperation（POST/PUT）、@DeleteOperation（DELETE）标注操作方法。@Endpoint 同时暴露给 Web 与 JMX；@WebEndpoint 仅暴露 Web、@JmxEndpoint 仅暴露 JMX。端点 id 通过注解 value 指定，方法参数可作为请求参数筛选。自定义端点需注册为 Spring Bean，然后在 management.endpoints.web.exposure.include 中显式暴露其 id。可用于暴露自定义业务指标、运行状态、触发特定操作等。

@Endpoint 提供统一的"端点扩展"机制，让监控能力可定制。掌握 ReadOperation/WriteOperation 与 Web/JMX 暴露方式，即可按需扩展 Actuator。

• JDK 对 sun.misc.Unsafe 的迁移与限制
• VarHandle 作为替代 API
• Spring Boot/框架对底层 API 变化的适配

JDK 逐步限制并准备移除 sun.misc.Unsafe 的某些能力，官方推荐以 VarHandle、AtomicReference 等标准 API 替代。Spring Framework 及 Spring Boot 在底层（如并发工具、缓存、序列化）中已随 JDK 演进调整对 Unsafe 的依赖，迁移到 VarHandle 等受支持 API。对 Spring Boot 而言，这类"底层 API 适配"通常随框架版本自动完成，开发者无需显式配置；但当使用到依赖 Unsafe 的第三方库（如某些序列化、锁库）时，在 JDK 25 下需升级依赖或改为 VarHandle 实现。Spring Boot 的自动配置不会为 Unsafe 替换做业务级配置，而是由框架版本与 JDK 兼容性保证。

该问题考察"JDK 演进对框架的影响"。核心是理解 Unsafe 正被 VarHandle 等标准 API 取代，框架随版本适配，第三方库需关注兼容性。

• AOT 构建期优化（构建期生成代码、元数据）
• 支持 GraalVM Native Image
• 减少运行时反射与启动开销

Spring Boot 的 AOT（Ahead-of-Time）引擎在构建期对应用进行分析与优化，生成运行所需的代码、配置与元数据（如代理类、反射配置、Bean 定义提示），从而减少运行时反射与启动开销。它支持两种主要用途：一是生成 GraalVM Native Image 所需的静态元数据（reachability 配置），使应用可编译为原生可执行文件；二是为 JVM 模式生成优化后的启动钩子，提升启动速度。AOT 需要应用尽量满足"静态可分析"条件（避免过多动态反射）。Spring Boot 4 进一步强化了 AOT 支持，作为默认的构建期优化方向。

AOT 的核心是"把运行期的分析/反射提前到构建期"，换取更快的启动与更小的运行时开销，是 Native Image 与启动优化的基石。

• Java 17+ 基线
• Spring Framework 7.0.8+
• Maven 3.6.3+ / Gradle 8.14+（含 9.x）

Spring Boot 4.1.0 要求 Java 17 及以上（推荐 21/25），底层基于 Spring Framework 7.0.8+；构建工具方面要求 Maven 3.6.3+ 或 Gradle 8.14+（含 9.x）。这些基线意味着：应用需运行在较新的 JDK 上，使用 Jakarta EE 规范（Servlet 6.1 等），构建工具需支持新的依赖管理。Spring Boot 4 相比 3.x 提升了基线，Java 17 是下限，Java 21+ 可充分利用虚拟线程等新特性。

版本基线决定了项目可用的语言特性与生态。明确 Java 17+、Spring Framework 7、Maven/Gradle 版本，是评估升级到 Spring Boot 4 的前提。

• @AutoConfiguration 替代 @Configuration 用于自动配置类
• 注册顺序控制（@AutoConfigureBefore/@AutoConfigureAfter/@AutoConfigureOrder）
• 自动配置类去重与排序

在 Spring Boot 4.x 中，自动配置类使用 @AutoConfiguration 注解（替代 @Configuration）标注，并配合 @AutoConfigureBefore、@AutoConfigureAfter、@AutoConfigureOrder 控制注册顺序。@AutoConfigureBefore 指定本配置在某个配置之前加载，@AutoConfigureAfter 指定在其之后加载，@AutoConfigureOrder 指定整体优先级。Spring Boot 通过 AutoConfigurationImportSelector 收集所有自动配置类，先按 @AutoConfigureOrder 排序，再结合 before/after 依赖关系进行拓扑排序，并利用 DeferredImportSelector 延迟处理实现去重。正确顺序保证依赖方配置先生成（如先配置数据源再配置 JPA）。

自动配置的顺序控制是"保证依赖关系正确"的关键。@AutoConfigureBefore/After/Order 提供了声明式排序，避免自动配置类因加载顺序错误而失效。

• Profile 定义环境（dev/test/prod）
• 多配置文件与激活方式
• 环境隔离与配置外置

Spring Boot Profile 用于定义不同运行环境（如 dev、test、prod），通过 spring.profiles.active 激活。支持多配置文件形式：application-dev.yml、application-prod.yml 等，或单文件内用 --- 分隔的 profile 文档块。激活方式：命令行 --spring.profiles.active=prod、环境变量 SPRING_PROFILES_ACTIVE、application.yml 中配置。Profile 与 @Profile 注解、@ConditionalOnProperty 等配合，实现"不同环境注册不同 Bean、加载不同配置"。环境隔离的核心价值是"同一代码库，按环境切换配置与行为"，避免配置硬编码。

Profile 是环境隔离的基石。通过"配置外置 + 按 profile 切换"，实现 dev/test/prod 的差异化配置与部署，是生产实践的基础。

• @SpringBootTest 加载完整上下文
• 切片注解只加载特定层
• 测试速度与隔离度

@SpringBootTest 启动完整的 Spring 应用上下文，加载所有 Bean 与自动配置，适合集成测试（端到端验证），但启动慢、依赖完整环境。切片注解（如 @WebMvcTest 只加载 MVC 层、@DataJpaTest 只加载 JPA 层、@MyBatisTest 只加载 Mapper 层）只加载相关切片 Bean 与自动配置，配合 @MockBean 模拟依赖，启动快、隔离性好，适合单元/层测试。选择原则：验证跨层协作用 @SpringBootTest，验证单层逻辑用切片注解提升速度。

核心取舍是"完整度 vs 速度"。@SpringBootTest 完整但慢，切片注解轻量但需 mock 其他层。根据测试目标选择合适粒度。

• SpringApplication 的启动回调机制
• ApplicationContextInitializer、ApplicationListener、ApplicationRunner
• 启动事件发布顺序

SpringApplication 在启动过程中提供多个扩展回调：ApplicationContextInitializer 在 ApplicationContext 创建后、refresh 前被调用，用于自定义上下文；ApplicationListener 监听启动事件（ApplicationStartingEvent、ApplicationEnvironmentPreparedEvent、ApplicationContextInitializedEvent、ApplicationReadyEvent、ApplicationFailedEvent 等）；ApplicationRunner/CommandLineRunner 在容器启动完成、ApplicationReadyEvent 前后执行，用于启动后初始化任务。开发者可通过 SpringApplication.addInitializers、addListeners 或 spring.factories/AutoConfiguration.imports 注册这些回调。回调顺序：环境准备 → 上下文创建 → 初始化器 → refresh → Runner → 就绪事件。

SpringApplication 的回调机制是"启动阶段定制"的入口。理解初始化器、监听器、Runner 的注册与触发时机，可在启动生命周期各阶段注入自定义逻辑。

• 两者都是启动后执行的回调
• 参数形式差异（原始字符串 vs 封装命令参数）
• 用于启动初始化任务

CommandLineRunner 与 ApplicationRunner 都在 Spring Boot 应用启动完成后（ApplicationReadyEvent 时）执行，接口方法分别接收参数：CommandLineRunner.run(String... args) 接收原始字符串参数数组，ApplicationRunner.run(ApplicationArguments args) 接收封装后的 ApplicationArguments（支持选项参数与非选项参数解析、getOptionValues 等）。多个 Runner 可通过 @Order 控制执行顺序。用途：启动后执行数据初始化、预热缓存、注册消息监听等一次性任务。二者区分度只在参数形式，ApplicationArguments 更结构化。

二者都是"启动钩子"，差异在参数解析能力。ApplicationRunner 的 ApplicationArguments 提供更友好的参数访问，是更推荐的选择。

• EnvironmentPostProcessor 在环境准备阶段修改 Environment
• 自定义配置源、默认属性
• 通过 spring.factories 注册

EnvironmentPostProcessor 是 Spring Boot 提供的扩展点，在 Environment 创建后、ApplicationContext 创建前被调用，用于在环境准备阶段修改配置（添加 PropertySource、覆盖属性、设置默认值）。应用场景：引入自定义配置源（如从 DB/远程配置中心加载配置）、动态设置默认属性、读取并注入环境变量。通过 META-INF/spring.factories 的 org.springframework.boot.env.EnvironmentPostProcessor 键注册。它早于所有 Bean 创建，是"启动早期介入配置"的机制。

EnvironmentPostProcessor 让开发者在"配置加载的最早阶段"介入，适合实现自定义配置中心、默认值注入等，是 Spring Boot 配置体系的重要扩展点。

• Tomcat 11 支持 Jakarta EE 11/Servlet 6.1
• Jetty 12.1 基线
• GraalVM 25 支持 Native Image

Spring Boot 4.x 的提升基线包括：内嵌 Servlet 容器 Tomcat 11.0.x（支持 Jakarta EE 11 / Servlet 6.1）、Jetty 12.1.x；GraalVM 25+ 用于 Native Image 编译。这些基线意味着 Spring Boot 4 面向更新的 Jakarta EE 规范与更新平台，Tomcat 11 与 Jetty 12.1 提供对 Servlet 6.1 的支持，GraalVM 25 与 Spring AOT 配合支持 Native Image 原生部署。开发者可通过配置替换默认容器（Tomcat 换 Jetty/Undertow），但需匹配对应版本范围。

运行时基线决定规范支持与容器选择。Spring Boot 4 的 Tomcat 11/Jetty 12.1/GraalVM 25 基线，反映其对齐 Jakarta EE 11 与原生部署的演进方向。

• 启动事件生命周期（Starting→EnvironmentPrepared→Ready→Failed）
• 事件发布与监听
• ApplicationContextRefreshedEvent 等

Spring Boot 通过事件机制在启动生命周期各阶段发布事件，监听器可对此响应。核心事件：ApplicationStartingEvent（启动开始）、ApplicationEnvironmentPreparedEvent（环境就绪）、ApplicationContextInitializedEvent（上下文初始化）、ApplicationPreparedEvent（上下文准备）、ApplicationStartedEvent（启动完成）、ApplicationReadyEvent（容器就绪、可接收请求）、ApplicationFailedEvent（启动失败）。此外容器刷新时发布 ContextRefreshedEvent。监听器通过 ApplicationListener 实现或 @EventListener 注解注册，在对应阶段触发自定义逻辑。事件机制使启动流程可观测、可扩展。

事件机制把"启动阶段"抽象为可监听的事件序列，是启动编排与监控的基础。理解事件顺序与触发时机，可精准在关键节点织入逻辑。

• server.shutdown=graceful 配置优雅停机
• 停机流程：停止接收新请求、等待处理完成
• 超时与资源释放

通过 server.shutdown=graceful 配置优雅停机。开启后，应用收到停机信号时不再接收新请求，等待正在处理的请求完成后再关闭，避免中断进行中的业务。配合 Spring Boot 的关闭钩子（@PreDestroy、DisposableBean 等）释放资源。可用 spring.lifecycle.timeout-per-shutdown-phase 设置每个停机阶段的超时时间，防止无限等待。优雅停机对服务发布、滚动升级至关重要，保证存量请求在处理完后再下线，提升可用性。

优雅停机解决"停机中断请求"问题。核心是"先停止接收新请求，再等待存量请求完成，最后释放资源"，超时控制避免停机卡死。

• spring-boot:repackage 生成可执行 Jar
• 三层结构（BOOT-INF/classes、BOOT-INF/lib、META-INF）
• 内嵌依赖与启动入口

spring-boot:repackage 插件目标将应用打成一个可执行 Jar，把应用类放在 BOOT-INF/classes、所有依赖 Jar 放在 BOOT-INF/lib，并生成带 JarLauncher 的 META-INF/MANIFEST.MF。执行 java -jar 时，JarLauncher 通过自定义类加载器加载 BOOT-INF/lib 中的嵌套依赖，找到 main 类并启动。这种"Fat Jar/可执行 Jar"结构使应用可作为单个 Jar 独立运行，无需外部依赖目录，便于部署。

可执行 Jar 通过"嵌套 Jar + 自定义类加载器"实现"单文件可运行"。理解 BOOT-INF 结构与 JarLauncher，是理解 Spring Boot 部署与打包的基础。

• FailureAnalyzer 分析启动失败并提供可读错误信息
• 自定义 FailureAnalyzer 与 spring.factories 注册
• 结合 FailureAnalysisReporter

FailureAnalyzer 用于在 Spring Boot 启动失败时，将异常分析为可读的 FailureAnalysis（包含 description 与 action），从而替换晦涩的堆栈信息，给出清晰的故障原因与修复建议。Spring Boot 内置大量 FailureAnalyzer（如端口占用、数据源配置错误）。自定义时实现 FailureAnalyzer 接口，通过 META-INF/spring.factories 的 org.springframework.boot.diagnostics.FailureAnalyzer 键注册，并配合 FailureAnalysisReporter 输出。启动失败时 Spring Boot 会遍历所有 FailureAnalyzer 尝试匹配异常。

FailureAnalyzer 让启动报错"可读、可查、可修复"，是提升诊断体验的关键。自定义分析器可针对业务异常给出专属提示。

• Micrometer 是指标抽象层
• MicrometerRegistry 与 MeterRegistry
• 与 Prometheus、Timed 注解集成

Spring Boot 通过 Micrometer 提供指标收集能力。Micrometer 是度量抽象库，通过 MeterRegistry 统一管理计数器（Counter）、计时器（Timer）、仪表（Gauge）、分布汇总（DistributionSummary）等指标。Spring Boot 自动配置一个 MicrometerRegistry（CompositeMeterRegistry），并支持多种注册表实现（如 PrometheusMeterRegistry），通过 micrometer-registry-prometheus 依赖将指标暴露到 /actuator/prometheus，配合 Prometheus 抓取。同时提供 @Timed 等注解自动记录方法耗时，以及 HTTP、JVM、数据库等自动指标。指标系统是生产监控与告警的基础。

Micrometer 把"业务指标"抽象为统一 API，Spring Boot 自动配置注册表与 Rest 暴露，形成"埋点→汇总→暴露→抓取"的监控链路。

• 自动配置按需装配
• Starter 起步依赖简化依赖管理
• Actuator 生产监控

Spring Boot 的核心特性包括：自动配置（AutoConfiguration），根据类路径与条件注解自动装配 Bean，开箱即用；起步依赖（Starter），如 spring-boot-starter-web 聚合常用依赖，简化依赖管理；Actuator，提供生产级监控端点（健康、指标、日志）；嵌入式服务器，内置 Tomcat/Jetty/Undertow，无需外部部署容器，java -jar 即可运行。这四大特性共同构成"约定优于配置"的快速开发与生产就绪能力。

四大特性分别解决"配置繁琐、依赖管理、监控运维、部署复杂"四个痛点，是 Spring Boot 快速开发与生产就绪的核心竞争力。

• banner.txt 自定义 ASCII 图
• 关闭 Banner（spring.main.banner-mode=off）
• 启动信息定制

Spring Boot 启动时打印 Banner，可通过在 classpath 放置 banner.txt 自定义 ASCII 图，或通过 Banner 接口编程式生成。通过 spring.main.banner-mode 控制显示模式（console/log/off），SpringApplication.setBanner 可编程设置。启动信息还包括版本号、环境等，可通过 Actuator /info 或自定义 Banner 展示。Banner 主要用于品牌展示与运维辨识，生产环境常关闭（off）以减少日志。

Banner 是启动输出的定制点，属于"锦上添花"的配置。掌握 banner.txt 与 banner-mode 即可灵活控制启动输出的展示。

• Starter 聚合依赖与自动配置
• 自定义 Starter 的自动配置类、条件注解、元数据
• 命名规范（spring-boot-starter-xxx 与 xxx-spring-boot-starter）

Spring Boot Starter 的设计思想是"依赖聚合 + 自动配置"：一个 Starter 聚合相关依赖并携带自动配置类，引入后即可获得对应功能的默认配置。自定义 Starter 步骤：创建自动配置类（@AutoConfiguration 标注，用条件注解控制生效）、通过 META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports 注册、提供配置属性类（@ConfigurationProperties）、生成 spring-configuration-metadata.json 元数据提供 IDE 提示。命名规范：Spring 官方使用 spring-boot-starter-xxx，第三方自定义使用 xxx-spring-boot-starter。

Starter 把"依赖 + 配置"封装为一体，实现开箱即用。自定义 Starter 的核心是自动配置类 + 条件注解 + 注册文件 + 属性元数据。

• Spring Framework 7 的基线提升（Jakarta EE 11）
• 虚拟线程默认支持
• 语义变化与兼容性

Spring Framework 7（Spring Boot 4.x 底层）相比 6.x 有若干语义变化：基线提升到 Java 17+ 与 Jakarta EE 11（Servlet 6.1）；对虚拟线程的默认支持增强（Spring Boot 4 默认启用虚拟线程）；某些 API 的废弃与重构（如更严格的注解处理、移除部分旧 API）；AOT 与 Native Image 支持成为一等公民。这些变化要求开发者关注包名、API 迁移与配置语义调整，升级时需按官方迁移指南检查兼容性。

"语义变化"指框架在版本演进中对 API、默认行为、规范支持的调整。Spring Framework 7 的变化集中在 Jakarta EE 11、虚拟线程、AOT 与旧 API 清理。

• 虚拟线程下的线程上下文传播
• @Async 使用虚拟线程执行器
• @Transactional 的线程绑定与虚拟线程

在 Spring Boot 开启虚拟线程后，@Async、Spring MVC 请求等会运行在虚拟线程上。边界与注意点：@Async 默认使用虚拟线程执行器（Spring Boot 4 默认），但需注意任务上下文（如 ThreadLocal、SecurityContext）是否随线程传播；@Transactional 基于 ThreadLocal 绑定事务资源，虚拟线程虽能工作，但事务必须绑定在有事务的线程内完成，跨虚拟线程切换会丢失事务上下文；@Scheduled 的调度器是否使用虚拟线程需单独配置。虚拟线程的 ThreadLocal 使用需谨慎（可结合 ScopedValue 替代），且避免使用 synchronized 阻塞虚拟线程（钉住）。总之，虚拟线程改变的是"线程载体"，但 Spring 的上下文传播机制（ThreadLocal/事务绑定）边界仍需遵守。

虚拟线程的边界在于"线程上下文传播"——ThreadLocal 绑定的事务、安全上下文在虚拟线程间默认不自动传播，需显式处理。@Transactional 必须同一线程内完成事务。

• @EnableAutoConfiguration 引入自动配置机制
• AutoConfigurationImportSelector 收集自动配置类
• 条件装配决定是否生效

@SpringBootApplication 组合了 @EnableAutoConfiguration，而 @EnableAutoConfiguration 通过 @Import(AutoConfigurationImportSelector.class) 引入自动配置机制。AutoConfigurationImportSelector 读取 META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports（Spring Boot 3 起的注册文件），收集所有自动配置类，按 @AutoConfigureBefore/After/Order 排序后，逐个评估其条件注解（@ConditionalOnClass/@ConditionalOnBean/@ConditionalOnProperty 等）。只有满足条件的自动配置类才被注册为 BeanDefinition，实现"按需自动装配"。这就是"引入依赖即可自动生效"的原理。

自动配置 = 收集（imports 文件）+ 排序（before/after/order）+ 条件评估（条件注解）。三者闭环决定了哪些功能自动装配、哪些不生效。

• --debug 参数输出条件评估报告
• 报告展示匹配/未匹配的自动配置
• 帮助诊断自动配置

启动时加 --debug 参数（或设置 logging.level.root=debug 之外，Spring Boot 会额外输出条件评估报告）会输出"CONDITIONS EVALUATION REPORT"，列出所有自动配置类的匹配情况：positive matches（生效的自动配置）与 negative matches（未生效的自动配置及其未匹配原因）。该报告是诊断自动配置的权威依据，能回答"为什么某个 Bean 没注入""为什么某自动配置被跳过"。与 /actuator/conditions 端点等价，--debug 适合在启动阶段直接查看。

条件评估报告把自动配置的"决策过程"透明化。启动加 --debug 即可快速定位自动配置不生效的原因，是排查问题的第一工具。

• 自动配置类的加载顺序与并发
• @AutoConfigureBefore/@AutoConfigureAfter 的依赖陷阱
• 循环依赖与顺序错误

自动配置类由 AutoConfigurationImportSelector 统一收集并按依赖关系排序后加载，本身是串行顺序加载，不会并发。但 @AutoConfigureBefore/@AutoConfigureAfter 使用不当会产生陷阱：若形成循环依赖（A 要求在 B 前、B 又要求在 A 前），Spring 无法确定顺序，可能导致配置加载顺序错误或冲突；若 before/after 指定的类不存在，@AutoConfigureBefore 会失效（Spring 2 中会直接按默认处理）。陷阱在于：过度依赖 before/after 排序会使配置脆弱，应尽量通过条件注解（如 @ConditionalOnMissingBean）而非硬性排序来保证正确性。

顺序控制应"少用 before/after、多用条件注解"。硬性排序易产生循环依赖与脆弱耦合，条件装配更稳健。

• 自动配置类编码规范（条件注解、@AutoConfiguration）
• 测试（AutoConfigurationTestUtil、条件测试）
• 文档与元数据（配置属性、使用说明）

自定义自动配置的工程实践：编码上，自动配置类用 @AutoConfiguration 标注，用条件注解（@ConditionalOnClass/@ConditionalOnProperty/@ConditionalOnMissingBean）精确控制生效时机，避免无条件生效；将配置属性封装为 @ConfigurationProperties 类，提供默认值；测试上，用 @AutoConfigurations 或 ApplicationContextRunner 编写条件测试，验证不同类路径/配置下配置是否生效；文档上，提供 spring-configuration-metadata.json 生成 IDE 属性提示，编写使用说明与示例。最终通过 AutoConfiguration.imports 注册。

工程实践强调"条件明确、可测试、可文档化"。条件注解决定生效边界，ApplicationContextRunner 保证可测，元数据提升可维护性。

• havingValue 指定匹配的配置值
• matchIfMissing 指定属性缺失时是否匹配
• 配置属性的条件控制

@ConditionalOnProperty 用于按配置属性值控制条件装配。havingValue 指定只有配置值等于该值时条件才成立（未指定时只要属性存在即成立）；matchIfMissing 指定当配置属性缺失时条件是否成立（默认 false，即缺失时不匹配）。两者组合可精确控制"某配置存在且等于某值则生效"或"配置缺失时按默认行为生效"。例如通过一个开关属性控制某功能是否开启，matchIfMissing=true 让未配置时默认开启。

havingValue 控制"等于什么值"，matchIfMissing 控制"缺失时怎么办"。二者配合实现灵活而稳健的配置开关逻辑。

• @ConditionalOnResource 判断类路径资源是否存在
• @ConditionalOnWebApplication 判断 Web 环境
• 两者的边界与适用场景

@ConditionalOnResource 用于判断指定类路径资源是否存在（如某个配置文件、库文件），存在才生效，常用于依赖特定资源的功能；@ConditionalOnWebApplication 用于判断应用是否为 Web 应用（可区分 Servlet/Reactive/ANY），用于 Web 相关自动配置。边界：@ConditionalOnResource 关注"资源文件"，@ConditionalOnWebApplication 关注"运行环境类型"。前者适合"资源驱动的配置"，后者适合"环境驱动的配置"。二者都只能用于自动配置类/配置类，不能放在 @Bean 方法内部保证时序。

两者都是"环境/资源感知"的条件注解，边界在"判断资源"与"判断环境"。理解其适用场景可精准控制自动配置的生效条件。

• @SpringBootApplication = @SpringBootConfiguration + @EnableAutoConfiguration + @ComponentScan
• 三个注解的分工
• 复合注解的组装

@SpringBootApplication 是复合注解，由 @SpringBootConfiguration（等价于 @Configuration）、@EnableAutoConfiguration（开启自动配置）、@ComponentScan（扫描组件）三个注解组合而成。@SpringBootConfiguration 标记该类为配置类并启用自动配置入口；@EnableAutoConfiguration 通过 AutoConfigurationImportSelector 引入自动配置机制；@ComponentScan 默认扫描主类所在包及其子包下的 @Component/@Service/@Repository 等组件。三者组合使主类"一个注解搞定配置、自动配置、组件扫描"。也可通过 exclude 属性排除特定自动配置。

@SpringBootApplication 把"配置 + 自动配置 + 扫描"整合为一个注解，是"约定优于配置"的集中体现。拆开理解三个注解的分工，可解释很多启动行为。

• exclude 排除特定自动配置类
• 排除的原因与替代方案
• 边界与注意事项

@SpringBootApplication 的 exclude 属性用于排除指定自动配置类，例如 @SpringBootApplication(exclude = DataSourceAutoConfiguration.class) 排除数据源自动配置。适用场景：某自动配置不符合需求（如不需要数据源、自定义了替代配置）、或自动配置报错需绕过。边界在于：exclude 只是"不加载该自动配置类"，若该配置被其他配置依赖，可能导致依赖缺失；替代方案是自定义条件或覆盖 Bean。排除后需自行提供所需 Bean，避免因排除引发新的配置缺失。

exclude 是"排除不需要的自动配置"的开关，但需注意排除的连带影响。更精细的做法是自定义配置或条件覆盖，而非盲目排除。

• spring.threads.virtual.enabled=true 开启
• 性能提升（高并发低资源）
• 兼容性影响（线程上下文、阻塞库）

Spring Boot 3.2+ 通过 spring.threads.virtual.enabled=true 开启虚拟线程（Spring Boot 4 默认启用），开启后 Tomcat 等容器用虚拟线程处理请求。性能影响：虚拟线程阻塞代价低，可用极少平台线程支撑海量并发，提升吞吐并降低内存占用。兼容性影响：需注意阻塞调用（synchronized 可能钉住虚拟线程）、包装在虚拟线程下的 ThreadLocal 使用、以及依赖平台线程模型的库；若存在大量 synchronized 或 JNI 阻塞，虚拟线程优势会受限。总体上，对常规 IO 密集型应用是正向优化，需避开钉住与线程上下文陷阱。

开启虚拟线程是"一行配置的革新"，性能收益显著，但兼容性需评估——synchronized 钉住、ThreadLocal 传播、阻塞库是主要风险点。

• 懒加载（spring.main.lazy-initialization）
• 分层 Jar（分层打包）
• CDS（Class Data Sharing）与 AOT

Spring Boot 启动性能优化手段：懒加载（spring.main.lazy-initialization=true，Bean 延迟到首次使用才创建，减少启动时间，但首次访问变慢）；分层 Jar（spring-boot:repackage 的 layered 模式，将依赖与应用分层，便于 Docker 分层缓存与增量构建）；CDS（Class Data Sharing）通过共享类元数据加速类加载，与 AOT 结合可显著降低启动时间；AOT（Ahead-of-Time）在构建期生成代码与元数据，减少运行时反射，配合 GraalVM Native Image 或 JVM 启动优化。综合使用可把启动时间从秒级降到亚秒级。

启动优化的核心是"减少启动期做的工作"——懒加载延后 Bean 创建、CDS 加速类加载、AOT 提前生成元数据。根据场景组合使用。

• @Async 默认 SimpleAsyncTaskExecutor 每次新建线程、并发无上限
• @Scheduled 默认单线程调度器使任务互相阻塞
• 显式配置 ThreadPoolTaskExecutor/ThreadPoolTaskScheduler（核心线程数、有界队列、拒绝策略）

@Async 默认使用 SimpleAsyncTaskExecutor，它每次调用都新建线程且无并发上限，高并发下会创建海量线程导致资源耗尽；@Scheduled 默认使用单线程调度器，多个定时任务会串行执行、互相阻塞。规避方式：显式配置线程池。用 ThreadPoolTaskExecutor 配置核心/最大线程数、有界队列容量与拒绝策略（如调用者运行 CallerRunsPolicy），并作为 @Async 的默认执行器；用 ThreadPoolTaskScheduler 配置调度线程池作为 @Scheduled 的执行器，解决单线程阻塞。配置要点：核心线程数、最大线程数、队列容量、拒绝策略四要素。

默认执行器是"坑"的根源——SimpleAsyncTaskExecutor 无界新建线程、@Scheduled 单线程串行。显式配置有界线程池 + 拒绝策略是根治手段。

• /actuator/health 作为 Kubernetes 探针
• liveness 与 readiness 的区别
• 探针配置与状态差异

Spring Boot 的 /actuator/health 端点可配置为 Kubernetes 的 liveness 与 readiness 探针。通过 management.endpoint.health.probes.enabled=true 启用，并暴露 health 端点。Kubernetes 中 livenessProbe 判断容器是否存活（故障则重启），readinessProbe 判断应用是否就绪（是否可接收流量，就绪前不转发流量）。Spring Boot 的 health 端点可区分 LivenessState 与 ReadinessState（如 LivenessStateHealthIndicator、ReadinessStateHealthIndicator），分别对应 liveness 与 readiness。这样应用自身的健康状态（如依赖数据库不可用）会影响 readiness 但可能不影响 liveness，实现"就绪与存活分离"。

探针把应用健康状态暴露给 Kubernetes 编排。liveness 管"是否重启"，readiness 管"是否接入流量"，Spring Boot 的 health 探针按此区分状态。

• Native Image 与虚拟线程的协同
• Spring Boot 4.x 对两者的支持
• 协同的边界与注意点

Spring Boot 4.x 同时支持 GraalVM Native Image 与虚拟线程：AOT 引擎在构建期生成 Native 所需的元数据，应用可编译为原生可执行文件并获得极快启动；同时虚拟线程默认启用，原生二进制中虚拟线程也能正常工作（JDK 对虚拟线程与 Native 均有支持）。协同支持意味着既可用 Native 的快速启动与低内存，又能用虚拟线程的高并发。注意点：Native 下需避免过度动态反射，虚拟线程需避开 synchronized 钉住；二者结合适用于对启动与资源要求苛刻的部署（如 Serverless、容器）。

"Native + 虚拟线程"是 Spring Boot 4 的先进组合：Native 解决启动与内存，虚拟线程解决并发。边界在于动态反射与钉住问题需规避。

• 自动配置类组织与条件注解
• 配置属性类与元数据
• 注册与模块划分

自定义 Starter 的工程组织建议：将自动配置类放在独立模块（如 xxx-spring-boot-autoconfigure），将核心功能放在功能模块（xxx-spring-boot-starter 依赖 autoconfigure）。自动配置类用 @AutoConfiguration 标注，用条件注解（@ConditionalOnClass/@ConditionalOnProperty/@ConditionalOnMissingBean）精确控制生效；配置属性用 @ConfigurationProperties 类封装，提供默认值；通过 META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports 注册自动配置类；生成 spring-configuration-metadata.json 提供 IDE 提示。模块依赖清晰、条件明确、元数据完整是实现可维护 Starter 的要点。

Starter 工程实践强调"模块化 + 条件明确 + 元数据完整"。autoconfigure 与 starter 分离、注册文件、配置元数据是标准组织方式。