orderedClassNames = new ArrayList<>(classNames);
Collections.sort(orderedClassNames);
orderedClassNames.sort((o1, o2) -> {
int i1 = classes.get(o1).getOrder();
int i2 = classes.get(o2).getOrder();
return Integer.compare(i1, i2);
});
// Then respect @AutoConfigureBefore @AutoConfigureAfter
orderedClassNames = sortByAnnotation(classes, orderedClassNames);
return orderedClassNames;
}
```
### 分支与失败边界
相互before/after形成循环会导致排序失败，属于配置依赖图错误。即使A配置在B之前，A里的懒加载Bean也可能直到业务调用才实例化。若B必须使用A实例，应声明真实构造依赖，而不是仅排序配置。
### 可复现实验与观察点
创建A、B两个@AutoConfiguration，在B中用ConditionalOnBean(AService.class)，先不声明after，再给B添加@AutoConfiguration(after=A.class)。用ApplicationContextRunner记录是否登记B；最后将AService设@Lazy并观察排序不等于立即初始化。
13. Bean生命周期：从定义到初始化与代理
### 问题与设计动机
自动配置完成后得到的是定义，生命周期把定义变成可用对象。实例化、依赖填充、Aware回调、before initialization、初始化回调、after initialization不是同一个阶段。AOP代理通常在后置处理器阶段产生，Boot并不自己重写所有Bean创建。
### 字段、状态与不变量
AbstractAutowireCapableBeanFactory.initializeBean局部wrappedBean可以从原始实例变成后置处理器返回的包装对象；RootBeanDefinition记录初始化方法等元数据。Boot的prepareContext设置allowCircularReferences/allowBeanDefinitionOverriding及懒初始化处理器，影响Framework策略而非替代它。
Bean生命周期：从定义到初始化与代理：关键状态推进 01 · 状态/交接 BeanDefinition：配方 02 · 状态/交接 实例化/填充：原始对象 03 · 状态/交接 Aware/初始化：回调 04 · 状态/交接 after初始化：可能返回代理 图13 · 关键交接点；完整调用及异常分支见正文 Called from {@link #createBean} for traditionally defined beans,
* and from {@link #initializeBean} for existing bean instances.
* @param beanName the bean name in the factory (for debugging purposes)
* @param bean the new bean instance we may need to initialize
* @param mbd the bean definition that the bean was created with
* (can also be {@code null}, if given an existing bean instance)
* @return the initialized bean instance (potentially wrapped)
* @see BeanNameAware
* @see BeanClassLoaderAware
* @see BeanFactoryAware
* @see #applyBeanPostProcessorsBeforeInitialization
* @see #invokeInitMethods
* @see #applyBeanPostProcessorsAfterInitialization
*/
@SuppressWarnings("deprecation")
protected Object initializeBean(String beanName, Object bean, @Nullable RootBeanDefinition mbd) {
invokeAwareMethods(beanName, bean);
Object wrappedBean = bean;
if (mbd == null || !mbd.isSynthetic()) {
wrappedBean = applyBeanPostProcessorsBeforeInitialization(wrappedBean, beanName);
}
try {
invokeInitMethods(beanName, wrappedBean, mbd);
}
catch (Throwable ex) {
throw new BeanCreationException(
(mbd != null ? mbd.getResourceDescription() : null), beanName, ex.getMessage(), ex);
}
if (mbd == null || !mbd.isSynthetic()) {
wrappedBean = applyBeanPostProcessorsAfterInitialization(wrappedBean, beanName);
}
return wrappedBean;
}
```
[真实源码 · SpringApplication.java:397–404 · 3.5.16](https://github.com/spring-projects/spring-boot/blob/0566f6933049aca6bc5ffc6d559fffade9cd2e0c/spring-boot-project/spring-boot/src/main/java/org/springframework/boot/SpringApplication.java#L377-L417)
```java
private void prepareContext(DefaultBootstrapContext bootstrapContext, ConfigurableApplicationContext context,
ConfigurableEnvironment environment, SpringApplicationRunListeners listeners,
ApplicationArguments applicationArguments, Banner printedBanner) {
context.setEnvironment(environment);
postProcessApplicationContext(context);
addAotGeneratedInitializerIfNecessary(this.initializers);
applyInitializers(context);
listeners.contextPrepared(context);
bootstrapContext.close(context);
if (this.properties.isLogStartupInfo()) {
logStartupInfo(context.getParent() == null);
logStartupInfo(context);
logStartupProfileInfo(context);
}
// Add boot specific singleton beans
ConfigurableListableBeanFactory beanFactory = context.getBeanFactory();
beanFactory.registerSingleton("springApplicationArguments", applicationArguments);
if (printedBanner != null) {
beanFactory.registerSingleton("springBootBanner", printedBanner);
}
if (beanFactory instanceof AbstractAutowireCapableBeanFactory autowireCapableBeanFactory) {
autowireCapableBeanFactory.setAllowCircularReferences(this.properties.isAllowCircularReferences());
if (beanFactory instanceof DefaultListableBeanFactory listableBeanFactory) {
listableBeanFactory.setAllowBeanDefinitionOverriding(this.properties.isAllowBeanDefinitionOverriding());
}
}
if (this.properties.isLazyInitialization()) {
context.addBeanFactoryPostProcessor(new LazyInitializationBeanFactoryPostProcessor());
}
if (this.properties.isKeepAlive()) {
context.addApplicationListener(new KeepAlive());
}
context.addBeanFactoryPostProcessor(new PropertySourceOrderingBeanFactoryPostProcessor(context));
if (!AotDetector.useGeneratedArtifacts()) {
// Load the sources
Set sources = getAllSources();
Assert.state(!ObjectUtils.isEmpty(sources), "No sources defined");
load(context, sources.toArray(new Object[0]));
}
listeners.contextLoaded(context);
}
```
### 分支与失败边界
构造循环无法仅靠早期引用解决；setter循环也受allowCircularReferences、作用域、代理等限制。初始化方法抛异常包装BeanCreationException并使非懒单例启动失败。懒加载只把失败推迟到首次访问，不等于修复依赖。循环引用默认禁用已在2.6时代发生，不能归为3.x专属改变。
### 可复现实验与观察点
样例加入实现BeanNameAware与InitializingBean的组件及自定义BeanPostProcessor，输出beanName和阶段；构造器→Aware→before→afterPropertiesSet→after是应观察的关键顺序。再在afterPropertiesSet抛错，定位BeanCreationException的根cause。
14. Servlet上下文：创建服务器与启动服务器
### 问题与设计动机
容器refresh需要创建WebServer，也需要让Servlet注册到ServletContext；真正对外启动则通过SmartLifecycle交接。将getWebServer当成唯一启动点，会忽略后面的WebServerStartStopLifecycle与初始化事件。外部WAR容器已有ServletContext时还走另一条路径。
### 字段、状态与不变量
ServletWebServerApplicationContext的webServer字段最初null，servletContext可能来自外部容器。createWebServer仅在两者都null时找ServletWebServerFactory，创建webServer并注册webServerGracefulShutdown与webServerStartStop单例。已有servletContext则执行selfInitializer而不创建嵌入式服务器。
Servlet上下文：创建服务器与启动服务器：关键状态推进 01 · 状态/交接 无ServletContext：嵌入式路径 02 · 状态/交接 factory.getWebServer：构建对象 03 · 状态/交接 Lifecycle.start：开放连接 04 · 状态/交接 有ServletContext：外部WAR注册 图14 · 关键交接点；完整调用及异常分支见正文 15. Tomcat工厂与Servlet注册：适配器的责任
### 问题与设计动机
Boot把server.port、连接器定制、上下文设置和ServletContextInitializer组装为嵌入式Tomcat。它提供可替换工厂和Customizer，Tomcat自身负责Socket、请求解析与Servlet调度。研究Boot时追到工厂边界，研究连接调度时再进入Tomcat仓库。
### 字段、状态与不变量
TomcatServletWebServerFactory持有protocol、baseDirectory、additionalTomcatConnectors等；Tomcat内部有Server、Service、Engine、Host、Context。ServletContextInitializerBeans维护initializers映射与sortedList，把Servlet/Filter/Listener Bean适配成注册对象。seen集合避免重复适配注册。
Tomcat工厂与Servlet注册：适配器的责任：关键状态推进 01 · 状态/交接 Boot属性/Customizer 02 · 状态/交接 Tomcat树与Connector 03 · 状态/交接 Initializer排序/去重 04 · 状态/交接 ServletContext注册映射 图15 · 关键交接点；完整调用及异常分支见正文 16. MVC：Boot提供默认值，DispatcherServlet处理请求
### 问题与设计动机
Boot的MVC自动配置提供转换器、静态资源、格式化、视图等默认组合。一次HTTP请求如何找Handler、适配调用、处理异常，仍在Framework的DispatcherServlet。加@EnableWebMvc通常意味着自己接管MVC配置，原因可从MissingBean条件直接看见。
### 字段、状态与不变量
WebMvcAutoConfiguration要求SERVLET环境、Servlet/DispatcherServlet/WebMvcConfigurer存在，以及没有WebMvcConfigurationSupport Bean。DispatcherServlet持有handlerMappings、handlerAdapters、handlerExceptionResolvers等策略；doDispatch里的mappedHandler与mv记录本次请求状态。
MVC：Boot提供默认值，DispatcherServlet处理请求：关键状态推进 01 · 状态/交接 HTTP请求：Servlet进入 02 · 状态/交接 HandlerMapping：找到处理器 03 · 状态/交接 HandlerAdapter：参数/调用 04 · 状态/交接 异常解析/视图或响应体 图16 · 关键交接点；完整调用及异常分支见正文 The handler will be obtained by applying the servlet's HandlerMappings in order.
* The HandlerAdapter will be obtained by querying the servlet's installed HandlerAdapters
* to find the first that supports the handler class.
*
All HTTP methods are handled by this method. It's up to HandlerAdapters or handlers
* themselves to decide which methods are acceptable.
* @param request current HTTP request
* @param response current HTTP response
* @throws Exception in case of any kind of processing failure
*/
@SuppressWarnings("deprecation")
protected void doDispatch(HttpServletRequest request, HttpServletResponse response) throws Exception {
HttpServletRequest processedRequest = request;
HandlerExecutionChain mappedHandler = null;
boolean multipartRequestParsed = false;
WebAsyncManager asyncManager = WebAsyncUtils.getAsyncManager(request);
try {
ModelAndView mv = null;
Exception dispatchException = null;
try {
processedRequest = checkMultipart(request);
multipartRequestParsed = (processedRequest != request);
// Determine handler for the current request.
mappedHandler = getHandler(processedRequest);
if (mappedHandler == null) {
noHandlerFound(processedRequest, response);
return;
}
// Determine handler adapter for the current request.
HandlerAdapter ha = getHandlerAdapter(mappedHandler.getHandler());
// Process last-modified header, if supported by the handler.
String method = request.getMethod();
boolean isGet = HttpMethod.GET.matches(method);
if (isGet || HttpMethod.HEAD.matches(method)) {
long lastModified = ha.getLastModified(request, mappedHandler.getHandler());
if (new ServletWebRequest(request, response).checkNotModified(lastModified) && isGet) {
return;
}
}
if (!mappedHandler.applyPreHandle(processedRequest, response)) {
return;
}
// Actually invoke the handler.
mv = ha.handle(processedRequest, response, mappedHandler.getHandler());
if (asyncManager.isConcurrentHandlingStarted()) {
return;
}
applyDefaultViewName(processedRequest, mv);
mappedHandler.applyPostHandle(processedRequest, response, mv);
}
catch (Exception ex) {
dispatchException = ex;
}
catch (Throwable err) {
// As of 4.3, we're processing Errors thrown from handler methods as well,
// making them available for @ExceptionHandler methods and other scenarios.
dispatchException = new ServletException("Handler dispatch failed: " + err, err);
}
processDispatchResult(processedRequest, response, mappedHandler, mv, dispatchException);
}
catch (Exception ex) {
triggerAfterCompletion(processedRequest, response, mappedHandler, ex);
}
catch (Throwable err) {
triggerAfterCompletion(processedRequest, response, mappedHandler,
new ServletException("Handler processing failed: " + err, err));
}
finally {
if (asyncManager.isConcurrentHandlingStarted()) {
// Instead of postHandle and afterCompletion
if (mappedHandler != null) {
mappedHandler.applyAfterConcurrentHandlingStarted(processedRequest, response);
}
asyncManager.setMultipartRequestParsed(multipartRequestParsed);
}
else {
// Clean up any resources used by a multipart request.
if (multipartRequestParsed || asyncManager.isMultipartRequestParsed()) {
cleanupMultipart(processedRequest);
}
}
}
}
```
### 分支与失败边界
没找到Handler走noHandlerFound；找到但没合适Adapter是另一种配置错误；转换失败与控制器抛错由异常解析器链处理。@EnableWebMvc导入WebMvcConfigurationSupport相关配置后，Boot MVC自动配置退让，而不是仅“增加一个注解功能”。静态资源404也不能先假设控制器未扫描。
### 可复现实验与观察点
样例/ping返回字符串；加入WebMvcConfigurer自定义拦截器，预期保留Boot默认行为。然后临时加@EnableWebMvc并--debug，观察WebMvcAutoConfiguration不再匹配；比较静态资源与消息转换器配置，再移除注解。
17. Binder：源名称、目标类型和错误策略
### 问题与设计动机
@Value偏向一个键的表达式求值，@ConfigurationProperties偏向结构化对象绑定。Binder必须同时知道配置名、目标类型、当前绑定上下文与处理器，才能处理Duration、嵌套对象、Map/List及错误。宽松名称匹配是来源适配能力，不意味着任意拼写都能成功。
### 字段、状态与不变量
Binder保存ConfigurationPropertySources、placeholdersResolver、conversionService和dataObjectBinders；Bindable携带ResolvableType、注解及已有值；Context跟踪当前深度与来源；BindHandler可在onStart/onSuccess/onFailure/onFinish中改变策略。
Binder：源名称、目标类型和错误策略：分支条件对照 01 · 条件分支 名称demo + Bindable类型 02 · 条件分支 PropertySource适配/查找 03 · 条件分支 直接值/聚合/对象分派 04 · 条件分支 Handler处理成功或错误 图17 · 分支分区，四格不表示顺序执行 T bind(ConfigurationPropertyName name, Bindable target, BindHandler handler, Context context,
boolean allowRecursiveBinding, boolean create) {
try (ConfigurationPropertyCaching.CacheOverride cacheOverride = this.configurationPropertyCaching.override()) {
try {
Bindable replacementTarget = handler.onStart(name, target, context);
if (replacementTarget == null) {
return handleBindResult(name, target, handler, context, null, create);
}
target = replacementTarget;
Object bound = bindObject(name, target, handler, context, allowRecursiveBinding);
return handleBindResult(name, target, handler, context, bound, create);
}
catch (Exception ex) {
return handleBindError(name, target, handler, context, ex);
}
}
}
```
### 分支与失败边界
List覆盖与Map按键合并有不同规则，不要说“所有集合逐项叠加”。转换错误不会自动回退低优先级来源：高优先级已命中的非法值通常使绑定失败。@ConfigurationProperties(ignoreInvalidFields=true)会改变错误策略，应清楚其可能留下默认值的后果。
### 可复现实验与观察点
第27章record DemoProperties中Duration timeout默认来自demo.timeout=2s。传--demo.timeout=abc，预期启动绑定失败并报告配置键与来源；传--demo.timeout=PT3S，预期可转换。对Binder.bindObject设断点观察目标是Duration还是完整record。
18. ConfigurationProperties生命周期、构造绑定与校验
### 问题与设计动机
可变JavaBean需要先创建再填充；不可变record必须用配置值调用构造器。这两条路径不能同时套在同一个普通@Component Bean上。绑定后应在应用接流量前验证约束，否则无效重试次数、超时或URL会进入业务。
### 字段、状态与不变量
BindMethod区分JAVA_BEAN与VALUE_OBJECT；ConfigurationPropertiesBindingPostProcessor跳过已构造绑定的value object，对常规Bean在before initialization时绑定。ConfigurationPropertiesBinder根据注解创建BindHandler，并可追加ValidationBindHandler、IgnoreErrorsBindHandler及UnboundElementsBindHandler。
ConfigurationProperties生命周期、构造绑定与校验：关键状态推进 01 · 状态/交接 JavaBean：先创建后绑定 02 · 状态/交接 Value Object：绑定后构造 03 · 状态/交接 ValidationBindHandler：验证 04 · 状态/交接 失败→阻断启动 图18 · 关键交接点；完整调用及异常分支见正文
* Note: To use constructor binding the class must be enabled using
* {@link EnableConfigurationProperties @EnableConfigurationProperties} or configuration
* property scanning. Constructor binding cannot be used with beans that are created by
* the regular Spring mechanisms (e.g.
* {@link org.springframework.stereotype.Component @Component} beans, beans created via
* {@link org.springframework.context.annotation.Bean @Bean} methods or beans loaded using
* {@link org.springframework.context.annotation.Import @Import}).
*
* @author Phillip Webb
* @since 2.2.0
* @see ConfigurationProperties
*/
@Target({ ElementType.TYPE, ElementType.CONSTRUCTOR })
@Retention(RetentionPolicy.RUNTIME)
@Documented
public @interface ConstructorBinding {
```
### 分支与失败边界
3.x单个参数化构造器通常可推断构造绑定，多个构造器则需明确选择；@ConstructorBinding不是用于把任何@Component改成值对象。3.x注解在context.properties.bind包并针对构造器，2.7.18在context.properties包且可标记类型。@Validated需实际验证实现，例如starter-validation，只有注解而没有Provider不能假定校验已执行。
### 可复现实验与观察点
样例record标记@Validated，给int retries加@Min(1)，pom引入starter-validation；--demo.retries=0应失败，--demo.retries=2应成功。把record改成普通@Component并保留构造绑定意图，观察普通Bean构造依赖与属性绑定之间的冲突，再恢复扫描注册。
19. Actuator：发现、可用性、暴露与鉴权是四个问题
### 问题与设计动机
“有Actuator依赖”不代表所有管理接口都可HTTP访问。端点先被发现并转换为操作模型，再受访问/启用与暴露策略过滤，最后由Web适配层映射；认证授权通常由Spring Security配置负责。将404当作安全证明，或把暴露当作认证，都容易误判。
### 字段、状态与不变量
EndpointDiscoverer缓存endpoints；EndpointBean保存id、Bean与操作；createEndpointBeans按EndpointId建LinkedHashMap并检查重复。3.5.x端点访问属性与最大允许访问限制形成端点可用性边界；WebEndpointDiscoverer及暴露过滤器控制哪些端点进入HTTP映射。
Actuator：发现、可用性、暴露与鉴权是四个问题：关键状态推进 01 · 状态/交接 Bean发现：EndpointId唯一 02 · 状态/交接 访问策略：是否有操作 03 · 状态/交接 Web暴露：是否映射HTTP 04 · 状态/交接 Security：谁能调用 图19 · 关键交接点；完整调用及异常分支见正文 discoverEndpoints() {
Collection endpointBeans = createEndpointBeans();
addExtensionBeans(endpointBeans);
return convertToEndpoints(endpointBeans);
}
private Collection createEndpointBeans() {
Map byId = new LinkedHashMap<>();
String[] beanNames = BeanFactoryUtils.beanNamesForAnnotationIncludingAncestors(this.applicationContext,
Endpoint.class);
for (String beanName : beanNames) {
if (!ScopedProxyUtils.isScopedTarget(beanName)) {
EndpointBean endpointBean = createEndpointBean(beanName);
EndpointBean previous = byId.putIfAbsent(endpointBean.getId(), endpointBean);
Assert.state(previous == null, () -> "Found two endpoints with the id '" + endpointBean.getId() + "': '"
+ endpointBean.getBeanName() + "' and '" + previous.getBeanName() + "'");
}
}
return byId.values();
}
```
### 分支与失败边界
重复id直接Assert失败；显式暴露不自动创建被访问策略禁用的端点。management.server.port不同会影响管理上下文与端口路由。health成功也不证明所有业务依赖与数据正确；探针聚合要看具体HealthIndicator/group。
### 可复现实验与观察点
样例只暴露health,info,conditions。访问/actuator/health应有结果，/actuator/beans预期404。临时增加beans暴露再检查变化；若加入Security，应验证未登录与登录分别返回什么。本样例供本机学习，不建议将管理端口直接公开。
20. Runner与可用性：存活不等于就绪
### 问题与设计动机
系统可能已经启动线程和端口，业务仍在加载索引。Liveness回答进程内部是否处于可继续工作的状态，Readiness回答是否适合接受新请求。Boot先发布started与CORRECT，Runner执行后才ready与ACCEPTING_TRAFFIC，为预热过程留出明确状态。
### 字段、状态与不变量
ApplicationAvailabilityBean的events按AvailabilityState类型保存最后事件；两个状态可以独立变化。SpringApplication从BeanFactory收集Runner实例，利用排序器与Bean工厂来源信息排序。Runner是启动时同步执行的回调，不是常驻后台线程接口。
Runner与可用性：存活不等于就绪：关键状态推进 01 · 状态/交接 refresh完成：CORRECT 02 · 状态/交接 Runner预热：未Ready 03 · 状态/交接 全部Runner成功 04 · 状态/交接 ACCEPTING_TRAFFIC 图20 · 关键交接点；完整调用及异常分支见正文 instancesToBeanNames = new IdentityHashMap<>();
for (String beanName : beanNames) {
instancesToBeanNames.put(beanFactory.getBean(beanName, Runner.class), beanName);
}
Comparator comparator = getOrderComparator(beanFactory)
.withSourceProvider(new FactoryAwareOrderSourceProvider(beanFactory, instancesToBeanNames));
instancesToBeanNames.keySet().stream().sorted(comparator).forEach((runner) -> callRunner(runner, args));
}
private OrderComparator getOrderComparator(ConfigurableListableBeanFactory beanFactory) {
Comparator dependencyComparator = (beanFactory instanceof DefaultListableBeanFactory defaultListableBeanFactory)
? defaultListableBeanFactory.getDependencyComparator() : null;
return (dependencyComparator instanceof OrderComparator orderComparator) ? orderComparator
: AnnotationAwareOrderComparator.INSTANCE;
}
```
[真实源码 · SpringApplication.java:793–798 · 3.5.16](https://github.com/spring-projects/spring-boot/blob/0566f6933049aca6bc5ffc6d559fffade9cd2e0c/spring-boot-project/spring-boot/src/main/java/org/springframework/boot/SpringApplication.java#L792-L798)
```java
@SuppressWarnings("unchecked")
private void callRunner(Class type, Runner runner, ThrowingConsumer call) {
call.throwing(
(message, ex) -> new IllegalStateException("Failed to execute " + ClassUtils.getShortName(type), ex))
.accept((R) runner);
}
```
[真实源码 · SpringApplication.java:754–761 · 2.7.18](https://github.com/spring-projects/spring-boot/blob/0c8b382d42db22b92efcf47000d0ff9ef4971629/spring-boot-project/spring-boot/src/main/java/org/springframework/boot/SpringApplication.java#L754-L761)
```java
private void callRunner(ApplicationRunner runner, ApplicationArguments args) {
try {
(runner).run(args);
}
catch (Exception ex) {
throw new IllegalStateException("Failed to execute ApplicationRunner", ex);
}
}
```
[真实源码 · ThrowingConsumer.java:58–69 · 6.2.19](https://github.com/spring-projects/spring-framework/blob/6214eae8bd02c2ed7ab382bb8d16a9cc6de49522/spring-core/src/main/java/org/springframework/util/function/ThrowingConsumer.java#L52-L69)
```java
/**
* Performs this operation on the given argument, wrapping any thrown
* checked exceptions using the given {@code exceptionWrapper}.
* @param exceptionWrapper {@link BiFunction} that wraps the given message
* and checked exception into a runtime exception
*/
default void accept(T t, BiFunction exceptionWrapper) {
try {
acceptWithException(t);
}
catch (RuntimeException ex) {
throw ex;
}
catch (Exception ex) {
throw exceptionWrapper.apply(ex.getMessage(), ex);
}
}
```
### 分支与失败边界
HTTP端口可监听而Readiness尚未接受流量；如果负载均衡器忽略就绪探针，仍可能把请求送来。长Runner阻塞后续Runner及ready；Runner失败会关闭上下文。Liveness通常不应因外部数据库短暂不可用而触发无限重启，具体依赖放在哪个健康组要按业务恢复策略设计。
### 两版对照的依据
实测教学Runner抛IllegalStateException时，3.5.16向调用者重新抛出该RuntimeException，消息仍是原始teaching failure；2.7.18的callRunner直接catch(Exception)并统一包装Failed to execute ApplicationRunner。3.5.16采用Framework ThrowingConsumer，RuntimeException原样传播，checked Exception才调用包装器。Ready不发布这一结果仍然相同，测试不要只硬编码旧错误消息。
### 可复现实验与观察点
样例添加一个3秒Runner，再监听AvailabilityChangeEvent输出状态类型及值。预期CORRECT先出现，3秒后ACCEPTING_TRAFFIC；改成失败Runner，不应出现ACCEPTING_TRAFFIC。对外流量是否被阻挡取决于部署平台探针设置，单机日志不证明负载均衡已遵守它。
21. 日志与FailureAnalyzer：早期初始化和诊断链
### 问题与设计动机
日志必须在Bean创建前工作，否则配置解析失败时没有可用诊断。LoggingApplicationListener先beforeInitialize抑制不合适输出，Environment准备后再按logging配置初始化。FailureAnalyzer则把异常转成描述与建议；它提升可读性，但不能替代根异常。
### 字段、状态与不变量
LoggingApplicationListener持有loggingSystem、logFile和loggerGroups；环境事件到来时才能读完整日志配置。FailureAnalyzers保存按工厂加载的analyzers；FailureAnalysis包括description/action/cause，FailureAnalysisReporter负责输出。分析器自身异常被记录并继续尝试下一个。
日志与FailureAnalyzer：早期初始化和诊断链：关键状态推进 01 · 状态/交接 starting：日志占位初始化 02 · 状态/交接 Environment：完整日志配置 03 · 状态/交接 异常：分析器链 04 · 状态/交接 结构化建议或通用堆栈 图21 · 关键交接点；完整调用及异常分支见正文 analyzers) {
for (FailureAnalyzer analyzer : analyzers) {
try {
FailureAnalysis analysis = analyzer.analyze(failure);
if (analysis != null) {
return analysis;
}
}
catch (Throwable ex) {
logger.trace(LogMessage.format("FailureAnalyzer %s failed", analyzer), ex);
}
}
return null;
}
private boolean report(FailureAnalysis analysis) {
List reporters = this.springFactoriesLoader.load(FailureAnalysisReporter.class);
if (analysis == null || reporters.isEmpty()) {
return false;
}
for (FailureAnalysisReporter reporter : reporters) {
reporter.report(analysis);
}
return true;
}
```
### 分支与失败边界
@PropertySource上的logging.level可能晚于日志初始化。FailureAnalyzer返回null意味着不负责该异常，不是“没有错误”。分析器提供的建议要和根cause核对，例如端口冲突、循环依赖、配置绑定错误有不同触发点。--debug条件报告解释配置决策，不等于开启所有业务DEBUG日志。
### 可复现实验与观察点
运行样例--logging.level.org.springframework.boot.context.config=TRACE观察早期配置解析；再以--demo.timeout=abc制造绑定失败，记录FailureAnalysis中的属性、值、来源与建议。对比Runner自定义异常没有专用分析器时的通用堆栈，确认二者诊断层次不同。
22. AOT与Native：构建期固定结构的代价
### 问题与设计动机
Native编译需要提前知道反射、资源与代理用法；Boot3整合AOT处理，用构建时可分析的应用上下文生成初始化代码与运行提示。它不是在生产第一次请求时再编译，也不意味着所有动态条件能在Native运行时任意改变。
### 字段、状态与不变量
SpringApplicationAotProcessor保存applicationArgs，继承Framework ContextAotProcessor。AotProcessorHook截获启动过程，获取为AOT准备的GenericApplicationContext；运行时AotDetector.useGeneratedArtifacts决定加载生成初始化器，主类名后缀__ApplicationContextInitializer必须存在。
AOT与Native：构建期固定结构的代价：关键状态推进 01 · 状态/交接 构建：准备上下文/条件 02 · 状态/交接 生成初始化代码与Hints 03 · 状态/交接 Native编译：闭世界 04 · 状态/交接 运行：装配已生成结构 图22 · 关键交接点；完整调用及异常分支见正文 > initializers) {
if (AotDetector.useGeneratedArtifacts()) {
List> aotInitializers = new ArrayList<>(
initializers.stream().filter(AotApplicationContextInitializer.class::isInstance).toList());
if (aotInitializers.isEmpty()) {
String initializerClassName = this.mainApplicationClass.getName() + "__ApplicationContextInitializer";
if (!ClassUtils.isPresent(initializerClassName, getClassLoader())) {
throw new AotInitializerNotFoundException(this.mainApplicationClass, initializerClassName);
}
aotInitializers.add(AotApplicationContextInitializer.forInitializerClasses(initializerClassName));
}
initializers.removeAll(aotInitializers);
initializers.addAll(0, aotInitializers);
}
}
```
### 分支与失败边界
反射调用未登记Hints可能在Native运行时失败；条件决定的Bean图在构建期固定，运行时改变profile或影响Bean存在性的配置不能假设重建图。正常Bean属性值仍有运行时绑定场景，但结构与值要分开判断。构建main中的副作用也可能被执行，要避免在主方法无条件写生产资源。
### 两版对照的依据
3.5.16的AOT处理入口@since 3.0.0；2.7.18主线不包含该Boot3集成入口，2.x使用Spring Native实验项目的历史路径不能直接当成3.x内置机制。
### 可复现实验与观察点
在受支持的GraalVM环境执行mvn -Pnative native:compile，再运行产物并检查/ping。比较target/spring-aot/main/sources中的生成初始化器；故意添加反射读取一个未登记类型的路径，观察并补RuntimeHintsRegistrar。本次未编译Native，实验依赖GraalVM与native插件配置。
23. 测试切片：受控容器比缩小@SpringBootTest更明确
### 问题与设计动机
控制器测试通常只需MVC相关Bean，数据库测试只需数据访问设施。切片通过关闭通用自动配置、限制类型扫描并导入特定自动配置组合减少范围。它不是简单在完整容器里让部分Bean懒加载，所以切片成功不能证明整个应用依赖都正确。
### 字段、状态与不变量
@WebMvcTest组合BootstrapWith、OverrideAutoConfiguration(enabled=false)、TypeExcludeFilters、AutoConfigureWebMvc与AutoConfigureMockMvc。SpringBootTestContextBootstrapper则选择Boot ContextLoader，搜索SpringBootConfiguration并处理WebEnvironment。测试Context缓存属于Framework测试设施，缓存键受配置/属性等影响。
测试切片：受控容器比缩小@SpringBootTest更明确：分支条件对照 01 · 条件分支 WebMvcTest：MVC范围 02 · 条件分支 ExcludeFilter：剔除业务服务 03 · 条件分支 MockMvc：Servlet内调用 04 · 条件分支 SpringBootTest：整应用/真实端口可选 图23 · 分支分区，四格不表示顺序执行 24. 2.7.18→3.5.16：迁移证据与责任归属
### 问题与设计动机
迁移需要区分Boot约定、Framework行为与第三方二进制接口。只把pom版本改成3.x会同时换Java基线、Servlet/JPA/Validation命名空间以及依赖版本。先在2.7线上清掉弃用API并建立行为测试，再切Java17+、Jakarta和新自动配置资源，更容易定位失败。
### 字段、状态与不变量
3.5.16 gradle.properties固定Framework6.2.19，2.7.18固定5.3.31；这两版不代表所有2.x和3.x小版本。Boot3运行最低Java17是上游system-requirements文档明示；Servlet指标源码从javax改jakarta；构造绑定注解位置/Target与候选注册代码存在直接差异。
2.7.18→3.5.16：迁移证据与责任归属：分支条件对照 01 · 条件分支 Java8时代基线→Java17+ 02 · 条件分支 javax Servlet→jakarta Servlet 03 · 条件分支 factories+imports→imports 04 · 条件分支 Framework5.3→6.2依赖集 图24 · 分支分区，四格不表示顺序执行 getCandidateConfigurations(AnnotationMetadata metadata, AnnotationAttributes attributes) {
List configurations = new ArrayList<>(
SpringFactoriesLoader.loadFactoryNames(getSpringFactoriesLoaderFactoryClass(), getBeanClassLoader()));
ImportCandidates.load(AutoConfiguration.class, getBeanClassLoader()).forEach(configurations::add);
Assert.notEmpty(configurations,
"No auto configuration classes found in META-INF/spring.factories nor in META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports. If you "
+ "are using a custom packaging, make sure that file is correct.");
return configurations;
}
```
[真实源码 · AutoConfigurationImportSelector.java:195–205 · 3.5.16](https://github.com/spring-projects/spring-boot/blob/0566f6933049aca6bc5ffc6d559fffade9cd2e0c/spring-boot-project/spring-boot-autoconfigure/src/main/java/org/springframework/boot/autoconfigure/AutoConfigurationImportSelector.java#L187-L205)
```java
/**
* Return the auto-configuration class names that should be considered. By default,
* this method will load candidates using {@link ImportCandidates}.
* @param metadata the source metadata
* @param attributes the {@link #getAttributes(AnnotationMetadata) annotation
* attributes}
* @return a list of candidate configurations
*/
protected List getCandidateConfigurations(AnnotationMetadata metadata, AnnotationAttributes attributes) {
ImportCandidates importCandidates = ImportCandidates.load(this.autoConfigurationAnnotation,
getBeanClassLoader());
List configurations = importCandidates.getCandidates();
Assert.state(!CollectionUtils.isEmpty(configurations),
"No auto configuration classes found in " + "META-INF/spring/"
+ this.autoConfigurationAnnotation.getName() + ".imports. If you "
+ "are using a custom packaging, make sure that file is correct.");
return configurations;
}
```
[真实源码 · WebApplicationType.java:48–49 · 2.7.18](https://github.com/spring-projects/spring-boot/blob/0c8b382d42db22b92efcf47000d0ff9ef4971629/spring-boot-project/spring-boot/src/main/java/org/springframework/boot/WebApplicationType.java#L48-L49)
```java
private static final String[] SERVLET_INDICATOR_CLASSES = { "javax.servlet.Servlet",
"org.springframework.web.context.ConfigurableWebApplicationContext" };
```
[真实源码 · WebApplicationType.java:51–52 · 3.5.16](https://github.com/spring-projects/spring-boot/blob/0566f6933049aca6bc5ffc6d559fffade9cd2e0c/spring-boot-project/spring-boot/src/main/java/org/springframework/boot/WebApplicationType.java#L51-L52)
```java
private static final String[] SERVLET_INDICATOR_CLASSES = { "jakarta.servlet.Servlet",
"org.springframework.web.context.ConfigurableWebApplicationContext" };
```
### 分支与失败边界
javax.sql.DataSource属于Java SE，不在Jakarta迁移中改包；盲目全局替换javax会破坏代码。2.7.18已经支持imports与ConfigData，循环引用默认关闭也不是3.x才发生。路径匹配、尾斜杠等MVC差异主要属Framework，需要用请求回归验证，不能从Boot候选类名推导具体路由语义。
### 两版对照的依据
证据表只对固定基线负责。Boot3.0官方迁移指南用于背景解释，具体3.5.16机制以本文固定源码为准，不能据此断言所有改动恰好在3.0一次加入。
### 可复现实验与观察点
先用同一小型业务样例在2.7.18跑测试，再升级parent到3.5.16并设Java17；逐个迁移javax.servlet/validation/persistence，检查mvn dependency:tree是否有旧API混入。自定义starter做双版本ApplicationContextRunner测试，确认imports在两版都能工作，再删除只服务旧EnableAutoConfiguration候选的factories登记。
25. DataSource退让：用一个完整案例串起条件
### 问题与设计动机
数据源自动配置是理解条件组合的好案例。JDBC类存在，应用又没有选择R2DBC连接工厂时才进入主配置；进入后还要区分嵌入式数据库与连接池分支、有没有用户DataSource以及驱动/连接参数是否有效。依赖可见与连接成功是两个完成点。
### 字段、状态与不变量
DataSourceAutoConfiguration带ConditionalOnClass(DataSource,EmbeddedDatabaseType)、ConditionalOnMissingBean(type="io.r2dbc.spi.ConnectionFactory")；内部EmbeddedDatabaseConfiguration与PooledDataSourceConfiguration均要求没有DataSource/XADataSource。DataSourceProperties负责参数，JdbcConnectionDetails提供可覆盖的连接信息。
DataSource退让：用一个完整案例串起条件：关键状态推进 01 · 状态/交接 JDBC类存在 02 · 状态/交接 无R2DBC ConnectionFactory 03 · 状态/交接 无用户DataSource：默认池 04 · 状态/交接 建池成功≠查询成功 图25 · 关键交接点；完整调用及异常分支见正文 26. 关闭与优雅停机：把流量状态与资源回收串起来
### 问题与设计动机
关闭不能只System.exit。应先停止接收新请求，再给在途请求有限的完成机会，最后释放线程与连接。Boot把WebServer优雅关闭放进SmartLifecycle阶段，Framework负责按phase组织停止回调和关闭Bean。能否完成仍受超时与底层服务器能力约束。
### 字段、状态与不变量
WebServerGracefulShutdownLifecycle维护running标记，stop(callback)调用webServer.shutDownGracefully并将结果接到callback；Servlet上下文doClose在active时先发布ReadinessState.REFUSING_TRAFFIC，super.doClose后destroy webServer。WebServerStartStopLifecycle的phase低于优雅关闭phase，停机逆序先执行高phase。
关闭与优雅停机：把流量状态与资源回收串起来：关键状态推进 01 · 状态/交接 REFUSING_TRAFFIC：摘流量信号 02 · 状态/交接 优雅关闭：等待在途请求 03 · 状态/交接 超时或完成：继续停止 04 · 状态/交接 Bean销毁/服务器destroy 图26 · 关键交接点；完整调用及异常分支见正文 27. 复现实验室：一个小应用验证多条主线
### 问题与设计动机
把阅读问题收敛到一个小工程：同一个/ping控制器、同一个DemoProperties、同一个Runner，可反复切换参数观察配置来源、绑定错误和就绪事件。另用ApplicationContextRunner做条件与Binder单测；它不依赖完整生产系统，也不需要真正访问数据库。
### 字段、状态与不变量
实验应用使用Java17语言级别、Spring Boot3.5.16 parent及starter-web/actuator/validation/test。示例源码在仓库的examples目录中；测试只使用临时上下文，不申请生产连接。DemoProperties是record，通过ConfigurationPropertiesScan注册，便于检查构造绑定。
复现实验室：一个小应用验证多条主线：关键状态推进 01 · 状态/交接 单测：Binder/条件/失败 02 · 状态/交接 打包：Boot可执行jar 03 · 状态/交接 运行：Servlet/MVC/Actuator 04 · 状态/交接 参数切换：验证不同状态 图27 · 关键交接点；完整调用及异常分支见正文