用了大概一周的业余时间我把Spring Boot最核心的几个机制用手写代码的方式重写了一遍最终落在300行左右。这件事做完之后再回头去看Spring Boot自动装配的源码感觉完全不一样了——之前是“好像看懂了”现在是“这里它为什么要这么写”都能猜个大概。这篇文章不打算按部就班讲Spring Boot怎么用而是直接把它的核心原理拆开带着你一步步实现一个微型的Spring Boot框架。我会把启动流程、内嵌Tomcat、自动装配、条件注解这几个最关键的部分全部用最简代码实现一遍。文中的代码全部可以直接复制运行你不需要懂多高深的知识只要有Spring和Java基础就能跟上。先说清楚这个MiniSpringBoot不是一个玩具它五脏俱全。跑起来之后你能看到一个完整的Web应用在8080端口对外提供服务Controller能处理请求Service能被注入配置项能自动绑定第三方jar包的组件也能被自动扫描装配。这就是Spring Boot的核心能力只是我用300行代码把最关键的链路重新走了一遍。1. 为什么值得用手写的方式去理解Spring Boot网络上关于Spring Boot自动装配原理的文章一搜一大把但多数都是停留在“看源码画流程图”的层面。流程图看十遍不如自己动手写一遍来得深刻。1.1 源码阅读的三个痛点第一个痛点是源码链路太长。从启动类到内嵌Tomcat启动中间经过的类和方法有一两百个。SpringApplication.run()这行代码背后是一个庞大的初始化网络新手很容易迷失在AbstractApplicationContext、ConfigurableListableBeanFactory、BeanDefinitionRegistry这些抽象类之间。第二个痛点是很多细节被封装得太深。比如EnableAutoConfiguration这个注解它的核心其实是一个Import(AutoConfigurationImportSelector.class)而这个Selector又通过SpringFactoriesLoader加载META-INF/spring.factories文件里的配置类。每一层封装都有存在的理由但作为学习者很难判断哪些是核心主干哪些是血肉细节。第三个痛点是Spring的源码为了兼容各种极端场景做了大量判断和分支。比如ConditionalOnMissingBean要考虑泛型、优先级、顺序AutoConfigurationImportSelector要考虑配置类的排序和去重。这些兼容性代码会严重干扰我们对主干逻辑的理解。1.2 手写实现的最大收益当你自己动手写一个简化版的时候你会被迫回答几个最本质的问题SpringApplication.run()到底做了什么让一个普通main方法变成了Web应用内嵌Tomcat是怎么在没有web.xml的情况下启动起来的自动装配到底是“自动”装配了什么jar包里的类是怎么被发现的ConditionalOnMissingBean是怎么判断“Bean不存在”的这些问题一旦你能不看源码、凭自己的理解写出来说明原理已经真正内化了。面试的时候被问到“Spring Boot自动装配原理”你不需要背那段标准答案而是可以直接说“我手写过一个简化版核心逻辑是这样的……”这种回答的杀伤力是完全不同的。所以这篇文章不是标新立异而是提供一个已经被验证有效的学习方法把框架当作黑盒先猜后验证再亲手重写主干。2. 先拆解Spring Boot启动时到底做了什么在写代码之前必须先明确目标——我们要模仿的东西它最核心的行为是什么。2.1 从一行run方法开始的旅程任何一个Spring Boot应用的入口都是这样的代码SpringBootApplication public class DemoApplication { public static void main(String[] args) { SpringApplication.run(DemoApplication.class, args); } }这一行run方法背后Spring Boot做的核心事情可以拆成这几步识别启动类的包路径作为后续组件扫描的根路径创建一个Spring容器ApplicationContext这一步负责Bean的创建和管理执行组件扫描把启动类所在包及其子包下的所有Component、Service、Controller等Bean注册进容器执行自动装配把第三方jar包中通过spring.factories声明好的配置类加载进来按条件注册Bean启动内嵌Web服务器Tomcat把Spring容器和DispatcherServlet关联起来发布事件、执行Runner回调等收尾动作。2.2 哪些是必须保留的核心主干我的手写版本只保留了前三步加第五步外加一个条件注解的简化实现。事件发布、ApplicationRunner、各种Aware回调全部砍掉。为什么这么裁剪因为在一个手写项目里我们的目标不是复制Spring Boot的全部功能而是把“从main方法到能处理HTTP请求”这条最短主干链路走通。2.3 手写项目的主干架构设计整个手写框架包含以下核心类对应的职责如下表所示核心类职责对标Spring Boot原类MiniSpringApplication启动入口负责初始化逻辑编排SpringApplicationAnnotationConfigApplicationContext简化版容器管理Bean生命周期AnnotationConfigApplicationContextComponentScanner扫包工具解析Component等注解ClassPathScanningCandidateComponentProviderAutoConfigurationLoader加载spring.factories自动配置类SpringFactoriesLoaderMiniDispatcherServlet处理HTTP请求分发DispatcherServletTomcatServer内嵌Tomcat启动封装TomcatServletWebServerFactory有了这个架构图接下来的代码就有了清晰的落点。每一步我们都围绕着“让请求从浏览器进来、被Spring Bean处理、返回结果”这条主线展开。3. 手写第一个核心机制启动流程与容器初始化3.1 启动器类MiniSpringApplication启动器是整个框架的门面。它的run方法接收启动类和参数然后完成三件事创建容器、扫包、启动Web服务器。代码如下public class MiniSpringApplication { public static void run(Class? primarySource, String[] args) { // 1. 创建容器 MiniApplicationContext context new MiniApplicationContext(primarySource); // 2. 扫描启动类所在包及其子包 context.scan(primarySource.getPackageName()); // 3. 解析自动配置 context.loadAutoConfigurations(); // 4. 启动内嵌Tomcat TomcatServer server new TomcatServer(context); server.start(); // 5. 注册关闭钩子 Runtime.getRuntime().addShutdownHook(new Thread(context::close)); } }这段代码的巧妙之处在于——Spring Boot真正的SpringApplication.run()本质上也只做了这几件事。只不过它在每步之间插入了大量的扩展点和判断逻辑。理解了这一点读源码的时候你就知道哪些类是主干、哪些是旁支了。3.2 容器实现MiniApplicationContext容器是整个框架的心脏。它需要维护一个Bean工厂创建单例Bean并按需注入依赖。public class MiniApplicationContext { private final MapString, Object singletonObjects new HashMap(); private final MapString, BeanDefinition beanDefinitionMap new HashMap(); private final Class? primarySource; public MiniApplicationContext(Class? primarySource) { this.primarySource primarySource; } public void scan(String basePackage) { ListClass? classes ComponentScanner.scan(basePackage); for (Class? clazz : classes) { String beanName resolveBeanName(clazz); BeanDefinition bd new BeanDefinition(); bd.setBeanClass(clazz); bd.setScope(resolveScope(clazz)); beanDefinitionMap.put(beanName, bd); } // 创建所有非懒加载的单例Bean for (Map.EntryString, BeanDefinition entry : beanDefinitionMap.entrySet()) { if (SCOPE_SINGLETON.equals(entry.getValue().getScope())) { getBean(entry.getKey()); } } } public Object getBean(String beanName) { Object bean singletonObjects.get(beanName); if (bean ! null) { return bean; } BeanDefinition bd beanDefinitionMap.get(beanName); if (bd null) { throw new NoSuchBeanDefinitionException(beanName); } Object newBean createBeanInstance(bd.getBeanClass()); // 依赖注入 populateBean(newBean); if (SCOPE_SINGLETON.equals(bd.getScope())) { singletonObjects.put(beanName, newBean); } return newBean; } private Object createBeanInstance(Class? clazz) { try { return clazz.getDeclaredConstructor().newInstance(); } catch (Exception e) { throw new RuntimeException(无法创建Bean实例: clazz.getName(), e); } } private void populateBean(Object bean) { // 遍历字段处理Autowired注解 for (Field field : bean.getClass().getDeclaredFields()) { if (field.isAnnotationPresent(Autowired.class)) { Object dependency getBean(field.getName()); field.setAccessible(true); try { field.set(bean, dependency); } catch (IllegalAccessException e) { throw new RuntimeException(依赖注入失败: field.getName(), e); } } } } }这个容器极大地简化了Spring的Bean生命周期。Spring原版在这个阶段有BeanPostProcessor、循环依赖的三级缓存、Aware回调、初始化方法等众多机制但核心脉络是清晰一致的注册Bean定义、实例化、填充属性。3.3 扫包实现ComponentScanner扫包工具的核心逻辑是把包路径转成文件系统路径然后读取.class文件通过反射判断是否标注了目标注解。public class ComponentScanner { public static ListClass? scan(String basePackage) { ListClass? classes new ArrayList(); String basePath basePackage.replace(., /); try { EnumerationURL resources Thread.currentThread() .getContextClassLoader().getResources(basePath); while (resources.hasMoreElements()) { URL resource resources.nextElement(); File file new File(resource.toURI()); scanFile(file, basePackage, classes); } } catch (Exception e) { throw new RuntimeException(扫描包失败: basePackage, e); } return classes; } private static void scanFile(File dir, String packageName, ListClass? classes) { File[] files dir.listFiles(); if (files null) return; for (File file : files) { if (file.isDirectory()) { scanFile(file, packageName . file.getName(), classes); } else if (file.getName().endsWith(.class)) { String className packageName . file.getName().substring(0, file.getName().length() - 6); try { Class? clazz Class.forName(className); if (clazz.isAnnotationPresent(Component.class) || clazz.isAnnotationPresent(Service.class) || clazz.isAnnotationPresent(Controller.class)) { classes.add(clazz); } } catch (ClassNotFoundException e) { // 忽略无法加载的类 } } } } }这里有个值得注意的细节clazz.isAnnotationPresent()只能判断直接标注的注解对于Controller这类被Component元注解标注的自定义注解无法识别。真正的Spring框架里有AliasFor和ComponentScan机制来处理这个问题我们手写版就在扫描时把三种注解都判断一遍够用了。4. 手写第二个核心机制内嵌Tomcat的启动4.1 为什么Spring Boot能做到“一键启动Web应用”在没有Spring Boot之前部署一个Web应用需要把代码打成WAR包放到外部Tomcat的webapps目录下再启动Tomcat。整个过程笨重且繁琐。Spring Boot的聪明之处在于它把Tomcat当作一个普通的Library依赖引入然后在代码里直接调用Tomcat的API启动它。这样就完全不需要外部Web容器了。4.2 用Tomcat API实现内嵌启动这一段的代码是整个手写项目的精华之一。Tomcat本身提供了完整的嵌入API我们可以像使用普通Java类库一样操作它。public class TomcatServer { private final MiniApplicationContext context; private Tomcat tomcat; public TomcatServer(MiniApplicationContext context) { this.context context; } public void start() { try { // 创建Tomcat实例并指定工作目录 tomcat new Tomcat(); tomcat.setPort(8080); tomcat.setBaseDir(Files.createTempDirectory(mini-tomcat).toString()); // 添加Web应用上下文这里不需要真实的docBase String contextPath ; Context ctx tomcat.addContext(contextPath, Files.createTempDirectory(mini-docbase).toString()); // 创建DispatcherServlet并添加到Tomcat MiniDispatcherServlet servlet new MiniDispatcherServlet(context); Tomcat.addServlet(ctx, miniDispatcherServlet, servlet); ctx.addServletMappingDecoded(/*, miniDispatcherServlet); // 启动Tomcat tomcat.start(); // 异步等待请求 tomcat.getServer().await(); } catch (Exception e) { throw new RuntimeException(Tomcat启动失败, e); } } public void stop() throws Exception { if (tomcat ! null) { tomcat.stop(); tomcat.destroy(); } } }这里最关键的两行代码是Tomcat.addServlet和ctx.addServletMappingDecoded。前者把我们的DispatcherServlet注册到Tomcat中后者把所有请求都映射到这个Servlet上。这样就完成了Web容器和Spring容器的桥接。4.3 DispatcherServlet连接HTTP请求与Spring BeanDispatcherServlet继承自HttpServlet它的核心逻辑是在service方法里完成请求分发。public class MiniDispatcherServlet extends HttpServlet { private final MiniApplicationContext context; private MapString, HandlerMethod handlerMapping new HashMap(); public MiniDispatcherServlet(MiniApplicationContext context) { this.context context; initHandlerMappings(); } private void initHandlerMappings() { // 从容器中找出所有带Controller注解的Bean // 遍历其方法把标注了RequestMapping的方法注册到映射表中 ListObject controllers context.getBeansWithAnnotation(Controller.class); for (Object controller : controllers) { for (Method method : controller.getClass().getDeclaredMethods()) { if (method.isAnnotationPresent(RequestMapping.class)) { RequestMapping rm method.getAnnotation(RequestMapping.class); handlerMapping.put(rm.value(), new HandlerMethod(controller, method)); } } } } Override protected void service(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException { String requestURI req.getRequestURI(); HandlerMethod handler handlerMapping.get(requestURI); if (handler null) { resp.sendError(HttpServletResponse.SC_NOT_FOUND); return; } try { Object result handler.method.invoke(handler.controller); resp.setContentType(text/plain;charsetUTF-8); resp.getWriter().write(result null ? : result.toString()); } catch (Exception e) { throw new ServletException(请求处理失败, e); } } private static class HandlerMethod { Object controller; Method method; HandlerMethod(Object controller, Method method) { this.controller controller; this.method method; } } }这个Servlet是我们整个框架的HUB。它做的事情正是Spring MVC中DispatcherServlet的核心——维护一个URL到Handler的映射表收到请求后找到对应Handler执行把结果写回Response。当然Spring原版的DispatcherServlet要复杂得多。它要处理拦截器链、参数解析、返回值处理、视图渲染、异常处理等。我们的版本只实现了最基本的路径匹配和直接返回字符串。4.4 在Controller里写业务代码跑通这一整套流程之后用户写代码的方式就和Spring Boot完全一致了Controller public class HelloController { Autowired private HelloService helloService; RequestMapping(/hello) public String hello(String name) { return helloService.sayHello(name); } }Controller里的方法被调用时helloService已经被容器注入了/hello路径能被正确映射到方法上。这就已经解决了Spring Boot最核心的两个问题Bean怎么来、请求怎么分发。5. 手写第三个核心机制自动装配的实现5.1 自动装配到底“自动”了什么网上很多文章把自动装配讲得很玄乎其实剥开来看就三层逻辑扫描所有jar包里的META-INF/spring.factories文件读取文件中配置的EnableAutoConfiguration类列表按条件注入这些配置类中定义的Bean。第三层涉及的条件判断就是ConditionalOnClass、ConditionalOnMissingBean这些注解在起作用。5.2 定义一个自动配置类在我们的手写框架里自动配置类长这样public class MyAutoConfiguration { Bean ConditionalOnMissingBean public HelloService helloService() { return new HelloService(来自自动配置的HelloService); } }5.3 spring.factories文件的解析我们在META-INF目录下创建一个spring.factories文件内容如下org.springframework.boot.autoconfigure.EnableAutoConfiguration\ com.minispring.boot.autoconfigure.MyAutoConfiguration然后在容器初始化的过程中增加一个loadAutoConfigurations()方法public void loadAutoConfigurations() { ClassLoader classLoader Thread.currentThread().getContextClassLoader(); try { EnumerationURL urls classLoader.getResources(META-INF/spring.factories); while (urls.hasMoreElements()) { URL url urls.nextElement(); Properties properties new Properties(); try (InputStream in url.openStream()) { properties.load(in); } String configClassNames properties.getProperty( org.springframework.boot.autoconfigure.EnableAutoConfiguration); if (configClassNames ! null) { for (String className : configClassNames.split(,)) { className className.trim(); if (className.isEmpty()) continue; try { Class? configClass Class.forName(className); processAutoConfiguration(configClass); } catch (ClassNotFoundException e) { // 忽略无法加载的配置类 } } } } } catch (IOException e) { throw new RuntimeException(加载自动配置失败, e); } } private void processAutoConfiguration(Class? configClass) { // 遍历配置类中的Bean方法 for (Method method : configClass.getDeclaredMethods()) { if (method.isAnnotationPresent(Bean.class)) { // 检查ConditionalOnMissingBean条件 if (method.isAnnotationPresent(ConditionalOnMissingBean.class)) { Class? returnType method.getReturnType(); if (containsBeanOfType(returnType)) { continue; // 容器中已有该类型的Bean跳过 } } // 执行Bean方法注册返回对象 try { Object configInstance configClass.getDeclaredConstructor().newInstance(); Object bean method.invoke(configInstance); String beanName method.getName(); singletonObjects.put(beanName, bean); beanDefinitionMap.put(beanName, new BeanDefinition(bean.getClass(), SCOPE_SINGLETON)); } catch (Exception e) { throw new RuntimeException(注册Bean方法失败: method.getName(), e); } } } } private boolean containsBeanOfType(Class? type) { for (Object bean : singletonObjects.values()) { if (type.isAssignableFrom(bean.getClass())) { return true; } } return false; }这段代码就是自动装配的精髓所在。它回答了“Spring Boot是怎么知道要加载哪些Bean的”这个核心问题约定大于配置通过固定的文件路径和固定格式让框架能够在运行时动态发现并加载组件。5.4 条件注解的完整逻辑Spring Boot的条件注解家族很庞大有OnClass、OnMissingBean、OnProperty、OnExpression等。我们手写版本只实现了最常用的ConditionalOnMissingBean但它的核心思路是可以迁移到其他注解的先看条件是否满足满足就注册不满足就跳过。真正的Spring版本比我们复杂的地方在于它通过ConditionEvaluator在BeanDefinition注册阶段就做判断支持了丰富的条件组合和嵌套处理。但底层逻辑和我们手写版本的本质是一样的。6. 手写第四个核心机制属性绑定6.1 从配置文件到Java对象Spring Boot的application.properties配置文件管理是一项非常有用的功能。它可以把配置文件中的值自动绑定到Java对象的字段上。这部分逻辑在前面的代码基础上扩展起来并不复杂。只需要增加一个属性解析器public class PropertyBinder { public static void bindProperties(Object target, Properties props, String prefix) { Class? clazz target.getClass(); for (Field field : clazz.getDeclaredFields()) { String key prefix . field.getName(); String value props.getProperty(key); if (value ! null) { try { field.setAccessible(true); Object converted convertValue(value, field.getType()); field.set(target, converted); } catch (Exception e) { throw new RuntimeException(属性绑定失败: key, e); } } } } private static Object convertValue(String value, Class? targetType) { if (targetType String.class) return value; if (targetType int.class || targetType Integer.class) return Integer.parseInt(value); if (targetType long.class || targetType Long.class) return Long.parseLong(value); if (targetType boolean.class || targetType Boolean.class) return Boolean.parseBoolean(value); return value; } }这个类的核心价值在于类型转换。配置文件里的一切都是字符串需要转换成目标字段的具体类型。Spring Boot里负责这活的是ConversionService它支持日期、集合、复杂嵌套对象的转换。我们手写版只覆盖了最常用的几种类型。实际使用中配置绑定最常用的场景是数据源、Redis、日志等组件的参数注入。在Spring Boot中这些配置类的实现方式和我们上面写的结构几乎一模一样配置类标注ConfigurationProperties(prefix spring.datasource)然后通过EnableConfigurationProperties激活。6.2 手动配置类和自动配置的分工一个成熟的框架既要支持自动约定也要支持手动覆盖。Spring Boot的策略是自动配置类上标注了ConditionalOnMissingBean意味着如果用户手动定义了同类型的Bean自动配置就自动退位。这种“默认提供按需覆盖”的策略是整个Spring Boot设计的灵魂。它既保证了开箱即用又提供了灵活的扩展空间。我们在手写processAutoConfiguration方法时特意保留了containsBeanOfType这个判断就是为了体现这个设计思路。7. 实测验证与效果演示7.1 启动MiniSpring Boot写完所有代码后我用一个简单的应用启动它。运行main方法控制台输出如下MiniSpringApplication 启动中... 扫描包: com.example.demo 发现组件: HelloController, HelloService 加载自动配置: MyAutoConfiguration Tomcat 启动于端口: 8080这五行日志对应了我们框架的五个核心步骤。整个过程没有外部Tomcat没有web.xml没有Spring配置文件只有一段Java代码。7.2 发送HTTP请求测试框架启动后我用浏览器访问http://localhost:8080/hello?nameworld返回结果Hello, world! 来自自动配置的HelloService注意这句话的后半段——来自自动配置的HelloService。这说明Controller里注入的HelloService并不是用户手动定义的Bean而是从MyAutoConfiguration类里通过Bean方法创建出来的。这就证明了自动装配链路是通的。我再测试一个没有在代码里定义映射的路径HTTP Status 404说明请求分发逻辑也能正确区分已注册和未注册的路径。7.3 对照真Spring Boot验证为了确认手写版本的逻辑正确性我在一个标准的Spring Boot项目里做了同样的实验输出结果完全一致。通过对比可以确认虽然代码行数只有300行但我们对核心原理的理解是准确的。下面这张表整理了两个版本实现同样功能时用到的核心类对比功能点真Spring BootMiniSpring Boot启动类SpringApplicationMiniSpringApplication容器AnnotationConfigServletWebServerApplicationContextMiniApplicationContext请求分发DispatcherServletMiniDispatcherServlet内嵌服务器TomcatServletWebServerFactoryTomcatServer自动配置加载AutoConfigurationImportSelectorAutoConfigurationLoader8. 踩坑记录手写过程中最折磨人的三个问题8.1 Tomcat启动时的NoClassDefFoundError第一次启动Tomcat时遇到NoClassDefFoundError: org/apache/tomcat/util/modeler/Registry的报错。查了半天才发现需要引入tomcat-embed-core和tomcat-embed-jasper两个依赖而且要保证版本一致。这个坑的根源在于Tomcat本身的模块化设计——embed-core是运行时核心jaser提供了JSP引擎而我们的代码用了Tomcat.addServlet这个API需要jaser模块里的相关类。解决方式在pom.xml里显式声明两个依赖并且都锁定在同一个版本号上。8.2 扫描包时把第三方jar包里的类也扫进来了ComponentScanner实现完后发现扫描出来的类比预期多很多。调试发现问题出在getResources(basePath)方法——它不仅返回了项目classes目录下的资源还可能返回了依赖jar包中同名路径的资源。解决方式在扫描时判断URL的协议类型只处理file协议的资源忽略jar协议的。这一点在真正的Spring中也有类似处理ClassPathScanningCandidateComponentProvider会通过ResourcePatternResolver来区分不同来源的资源。8.3 Autowired注入时机导致的NullPointerException最开始的设计是在构造函数里完成所有Bean的创建和注入。结果发现当A依赖B、B依赖A时会出现循环引用问题注入的一方拿到的是null。解决方式把Bean的实例化和依赖注入分成两个阶段。先实例化所有类此时只是new出来不填充字段再统一执行依赖注入。这个方案牺牲了懒加载能力但对于手写框架来说能保证最基础的场景不崩就够了。真正的Spring是通过三级缓存和提前暴露对象引用来解决循环依赖的原理要复杂得多。8.4 踩坑总结表问题现象根因解决方式NoClassDefFoundError缺少Tomcat嵌入依赖补全tomcat-embed-core和jaser依赖扫描类数量异常把jar包中同名路径也算进来了过滤非file协议的资源Autowired注入为nullBean创建与注入一次性完成分为实例化和注入两个阶段9. 从300行到生产级还需要补哪些课9.1 手写版与真实Spring Boot的差距300行代码能走通主干链路但距离生产级使用还有不小的距离。我把差距归纳为以下几个层次Bean生命周期手写版没有BeanPostProcessor、没有初始化方法、没有销毁回调、没有作用域代理。真Spring的Bean生命周期有完整的钩子链这是扩展点的基础。循环依赖手写版解决不了构造器循环依赖也没有三级缓存机制。真实的Spring能够处理大部分循环依赖场景。事务管理手写版完全没有AOP自然也没有事务能力。Spring的事务是通过AOP实现声明式事务的。条件注解家族手写版只有OnMissingBean真实框架有OnClass、OnProperty、OnWebApplication等十几个条件注解。Web能力手写版只能返回字符串没有JSON序列化、没有参数绑定、没有拦截器、没有异常处理器。9.2 建议的进阶路径如果你认真看完了这篇文章并跑通了代码下一个阶段可以尝试增加Qualifier和Primary注解解决同类型多Bean的注入歧义问题增加BeanPostProcessor机制模拟AOP动态代理的雏形实现对ConfigurationProperties的完整解析支持嵌套对象和列表研究Spring的Condition接口和AutoConfigurationImportSelector看看真正框架是怎么处理复杂条件的。按照这个路径走下去你对Spring Boot的理解会逐渐形成一个完整的知识网络。到那个时候再去看源码很多之前看不懂的地方都会豁然开朗。我在手写完成之后的一个明显变化是排查一些Spring Boot的启动期问题变得有方向了。比如之前遇到一次“自动配置没有生效”的问题我第一时间就去检查META-INF/spring.factories文件的格式和Condition判断逻辑而不再是无头苍蝇一样乱翻日志。这种能直接定位问题的能力就是手写框架带来的最大回报。