简介本资源是一份面向Java初学者与中级开发者的Spring框架源码学习套件聚焦Spring核心机制的透彻理解有效解决入门者面对庞杂源码无从下手、缺乏上下文注释与实践引导的痛点。压缩包为ZIP格式大小36.14MB包含完整Spring各模块源码如spring-beans、spring-context、spring-aop等所有类文件均附带中文注释并配套IoC容器初始化、Autowired依赖注入、AOP代理织入、JdbcTemplate数据访问及DispatcherServlet请求处理等典型场景的可运行案例工程便于边读边验。目前已有1535人学习下载目录结构严格对应Spring官方模块划分关键类如DefaultListableBeanFactory、AutowiredAnnotationBeanPostProcessor、AspectJAutoProxyCreator、JdbcTemplate和DispatcherServlet均标注核心流程与设计意图显著降低源码阅读门槛助力开发者扎实掌握Spring底层原理与扩展能力。1. 这不是一本“源码书”而是一套可运行、可调试、可复刻的Spring学习操作系统你点开这个标题大概率是刚学完Spring Boot基础写过几个RestController配过几回application.yml但一看到Service里Autowired背后到底发生了什么就卡住或者正被面试官问“BeanFactory和FactoryBean区别在哪”“三级缓存为什么能解决循环依赖”答得支离破碎又或者想啃《Spring源码深度解析》这类经典翻到第3章AbstractBeanFactory的doCreateBean方法就头晕目眩——不是代码看不懂是根本不知道该从哪一行开始下断点不知道哪个类才是真正的入口更不知道那些密密麻麻的注释到底是作者随手写的还是真能帮你理解流程的“路标”。我带过67个Java后端新人从2015年Spring 4.1时代就开始带团队读源码。最常听到的抱怨不是“太难”而是“找不到起点”“注释像天书”“案例跑不起来”“看完还是不会改”。所以这次我把十年来沉淀下来的Spring源码学习路径彻底重构了一遍它不是把Spring Framework 6.1.0所有.java文件打包扔给你而是用一套可执行、带断点、有上下文、每行注释都经过验证的工程结构把Spring从启动到Bean创建、AOP织入、事务开启、MVC分发的完整生命周期拆成12个可独立运行的最小闭环案例。每个案例都对应一个真实问题场景——比如“为什么加了Transactional的方法内部调用不生效”你就直接打开transaction-case模块在TransactionAspectSupport.invokeWithinTransaction方法里下断点看代理对象怎么绕过、切点表达式如何匹配、事务传播行为怎么决策。所有注释不是翻译API文档而是写在关键逻辑旁的“现场笔记”这里为什么用ConcurrentHashMap而不是HashMap这个if判断漏掉会引发什么死锁这个try-catch捕获的是哪个具体异常实测下来新人平均用2.3天就能独立走通第一个IOC容器初始化流程比纯看书快4倍。核心关键词spring、源码、注释、案例、入门级不是堆砌而是五个必须同时满足的硬指标spring严格限定在Spring Framework 6.1.0非Boot封装层所有代码基于spring-beans、spring-context、spring-aop等原生jar反编译重注释源码不是截图不是PDF是IntelliJ IDEA可直接导入、F9单步调试、CtrlClick跳转的完整工程注释每行关键逻辑必有中文注释且标注来源如“来自DefaultListableBeanFactory#preInstantiateSingletons第187行Spring官方注释原文为…”案例12个独立Maven子模块每个聚焦一个核心机制如ioc-case、aop-case、tx-case、mvc-case附带README.md说明触发条件、预期现象、调试路径入门级零Spring Boot经验也可上手——所有案例均用ClassPathXmlApplicationContext或AnnotationConfigApplicationContext手动启动避开自动配置干扰直面Spring最原始的API调用链。如果你的目标是“能看懂Spring官网Javadoc背后的实现逻辑”而不是“背下BeanDefinitionRegistryPostProcessor的17个实现类”那这套材料就是为你设计的。它不教你如何成为Spring Committer但能让你在下次CR时一眼看出同事提交的BeanPostProcessor是否会在Bean初始化前就修改final字段——这才是入门级该有的深度。2. 为什么必须放弃“通读源码”的幻想我的三年踩坑路线图刚接触Spring源码时我也信过“通读论”。2016年我花了整整三个月用Notepad逐行抄写spring-beans包下所有类边抄边翻译Javadoc结果抄完refresh()方法的12个子步骤连DefaultListableBeanFactory的registerBeanDefinition()参数含义都没搞清。后来带新人时发现92%的人卡在同一个地方他们试图用“阅读小说”的方式读源码却忘了源码是“执行剧本”——没有运行时上下文没有数据流向没有调用栈压栈弹栈再详细的注释也是空中楼阁。2.1 入门级最大的认知陷阱混淆“源码结构”与“执行路径”Spring Framework源码目录看着很清晰spring-core、spring-beans、spring-context…但实际执行时代码流根本不是按包名顺序走的。比如你写一个Component类你以为流程是spring-context → ClassPathBeanDefinitionScanner → spring-beans → BeanDefinitionRegistry → spring-core → BeanFactory实际上当你调用new AnnotationConfigApplicationContext(AppConfig.class)时第一行执行的是AnnotatedBeanDefinitionReader.register(…)它直接调用BeanDefinitionRegistry.registerBeanDefinition()而这个接口的实现类GenericApplicationContext又委托给DefaultListableBeanFactory——此时你甚至还没碰到spring-context包里的任何类。更致命的是ComponentScan的扫描逻辑藏在ClassPathScanningCandidateComponentProvider里这个类在spring-core包下但它的findCandidateComponents()方法调用了ResourcePatternResolverspring-core→PathMatchingResourcePatternResolverspring-core→ClassPathResourcespring-core全程没进spring-context半步。我当年就是在这里栽了跟头在spring-context目录下疯狂搜索“ComponentScan”却不知道真正干活的是spring-core里的ClassPathScanningCandidateComponentProvider。直到某次在AnnotationConfigApplicationContext构造函数里打了个断点看着调用栈一层层往下钻才明白Spring的模块划分是编译期解耦运行时是高度交织的。所以这套材料的第一个设计原则就是抛弃包结构按执行路径组织案例。ioc-case模块里你看到的不是spring-beans包的类列表而是从AnnotationConfigApplicationContext构造开始到finishBeanFactoryInitialization()结束的完整调用链每个类都标注了“此处进入spring-core”“此处跳转spring-aop”让执行路径一目了然。2.2 注释不是越多越好而是要“注在刀刃上”网上很多所谓“带注释源码”其实是把IDEA自动生成的Javadoc翻译成中文或者把Spring官网Wiki复制粘贴。这种注释对入门者毫无价值。比如AbstractBeanFactory.doGetBean()方法开头有段注释“Return the bean instance that should be exposed for this bean definition.”——这等于没说。真正有用的注释应该回答“为什么这里要加synchronized”“为什么这个变量用volatile修饰”“如果这里抛出NoSuchBeanDefinitionException上层怎么处理”我在重注释时只保留三类内容决策型注释解释代码为何选择此方案而非彼方案。例如DefaultSingletonBeanRegistry.getSingleton()中singletonObject this.singletonObjects.get(beanName)之后有一行注释“此处不直接返回singletonObject因为可能正在创建中earlySingletonObjects存在需检查singletonsCurrentlyInCreation避免循环依赖检测失效”。陷阱型注释标注易错点。如AutowiredAnnotationBeanPostProcessor.postProcessProperties()里在field.setAccessible(true)后加注释“JDK17默认禁用反射访问private字段需添加--add-opens java.base/java.langALL-UNNAMED JVM参数否则抛InaccessibleObjectException”。溯源型注释标明该逻辑的官方依据。如ConfigurationClassPostProcessor.processConfigBeanDefinitions()中处理Bean方法时注释写“此逻辑对应Spring官方文档‘Bean Method Processing’章节要求Bean方法必须是非static的否则忽略见ConfigurationClassUtils.isBeanMethod()”。所有注释都经过实测验证我在JDK8、JDK11、JDK17三个环境分别运行对应案例确认注释描述的现象真实存在。比如关于JDK17反射限制的注释就是我在跑ioc-case时连续三次报InaccessibleObjectException后补上的——这种血泪教训比一百句理论都管用。2.3 案例不是Demo而是“故障注入式”学习单元很多入门案例喜欢写“Hello World”式的Spring应用定义一个Service注入一个Dao打印一句“Hello Spring”。这种案例的问题在于它掩盖了Spring最核心的复杂性——状态管理、时机控制、边界条件。真正的Spring难点永远出现在“意外发生时”。所以这套材料的12个案例全部采用“故障注入”设计ioc-case故意在Bean定义里设置scopeprototype然后在单例Bean里Autowired它观察每次getBean()是否真的创建新实例答案是否定的因为Autowired注入的是容器提前创建的原型Bean引用aop-case在目标方法里throw new RuntimeException()然后对比Transactional(propagation Propagation.REQUIRED)和Propagation.REQUIRES_NEW下事务回滚范围差异mvc-case把RequestMapping写成RequestMapping(/user/{id})但Controller方法参数用PathVariable Long id故意不加PathVariable(id)看Spring如何解析路径变量会报MissingPathVariableException注释里详解ParameterDescriptor如何匹配。每个案例的pom.xml都精确锁定Spring版本6.1.0、JDK版本17、Maven版本3.8.6并预置好mvn clean compile exec:java一键运行脚本。你不需要配置任何环境下载解压后cd进对应模块敲./run.shLinux/Mac或run.batWindows就能看到控制台输出完整的调用栈、Bean创建日志、AOP代理生成过程。这种“所见即所得”的反馈比看十页文字描述都有效。3. 核心细节拆解从AnnotationConfigApplicationContext启动到Bean创建的17个关键节点现在我们以ioc-case为例完整走一遍Spring IOC容器初始化流程。这不是泛泛而谈的“refresh()八步法”而是精确到每一行代码、每一个对象状态变化的实战记录。所有路径、类名、方法名、参数值均来自实际调试截图。3.1 第1步AnnotationConfigApplicationContext构造——真正的入口在此很多人以为refresh()是起点其实AnnotationConfigApplicationContext的构造函数才是整个流程的发动机。当你写下ApplicationContext context new AnnotationConfigApplicationContext(AppConfig.class);执行的第一行是AnnotationConfigApplicationContext的父类GenericApplicationContext构造函数public GenericApplicationContext() { this.beanFactory new DefaultListableBeanFactory(); }注意这里beanFactory被初始化为DefaultListableBeanFactory实例但此时它还是个空壳——没有BeanDefinition没有注册任何Bean。真正的“活化”发生在AnnotationConfigApplicationContext自己的构造函数里public AnnotationConfigApplicationContext(Class?... annotatedClasses) { // 关键此处创建AnnotatedBeanDefinitionReader负责解析Configuration类 this.reader new AnnotatedBeanDefinitionReader(this); // 关键此处创建ClassPathBeanDefinitionScanner负责扫描Component等注解 this.scanner new ClassPathBeanDefinitionScanner(this); // 关键此处注册AppConfig.class为Configuration类 this.register(annotatedClasses); // 关键此处触发refresh()但注意此时容器尚未初始化 this.refresh(); }提示this.register(annotatedClasses)这行代码会调用AnnotatedBeanDefinitionReader.register()将AppConfig.class包装成AnnotatedGenericBeanDefinition然后调用BeanDefinitionRegistry.registerBeanDefinition()存入beanFactory.beanDefinitionMap。这意味着在refresh()执行前容器里已经有一个BeanDefinition了——就是你的配置类本身。这是后续所有Bean方法解析的基础。3.2 第2步refresh()——12个子方法的执行顺序与依赖关系refresh()是Spring容器初始化的总控方法但它本身不干活只是按顺序调用12个protected方法。这12个方法不是并列关系而是强依赖链前一个方法的输出是后一个方法的输入。比如obtainFreshBeanFactory()必须在prepareBeanFactory()之前执行因为后者需要前者创建的ConfigurableListableBeanFactory。我们重点关注前5个方法它们构成了IOC容器的骨架prepareRefresh()设置容器启动时间、活跃标志位、初始化PropertySources用于占位符解析。obtainFreshBeanFactory()销毁旧的BeanFactory如果有创建新的DefaultListableBeanFactory并将其赋值给this.beanFactory。prepareBeanFactory(beanFactory)为BeanFactory配置核心组件设置ClassLoader默认为当前线程上下文类加载器添加EmbeddedValueResolver用于解析${}占位符注册ApplicationContextAwareProcessor实现ApplicationContextAware接口的Bean会在此处被注入ApplicationContext最关键的一步注册ApplicationListenerDetector这是一个BeanPostProcessor它会在Bean初始化后检查是否实现了ApplicationListener接口如果是则将其加入事件监听器列表。postProcessBeanFactory(beanFactory)留给子类扩展的钩子方法。AnnotationConfigApplicationContext在此处调用reader.loadBeanDefinitions()将Configuration类中的Bean方法转换为BeanDefinition并注册到beanFactory。invokeBeanFactoryPostProcessors(beanFactory)执行BeanFactoryPostProcessor。最典型的是ConfigurationClassPostProcessor它会扫描所有Configuration类解析其中的Bean、Import、ComponentScan等注解生成对应的BeanDefinition并注册到beanFactory特别注意ComponentScan扫描出的Bean其BeanDefinition的scope属性默认为singleton而Bean方法生成的BeanDefinition其scope由方法上的Scope注解决定未声明则默认singleton。注意invokeBeanFactoryPostProcessors()执行完毕后beanFactory.beanDefinitionMap里已经有了所有用户定义的BeanDefinition包括配置类自身、Bean方法生成的Bean、Component扫描出的Bean。但此时这些Bean都还没被实例化singletonObjects单例缓存还是空的。3.3 第3步finishBeanFactoryInitialization()——单例Bean的批量创建与三级缓存登场当refresh()执行到第9步finishBeanFactoryInitialization(beanFactory)时真正的Bean创建风暴才开始。这个方法的核心逻辑是遍历beanFactory.getBeanNamesForType(Object.class, true, false)获取所有非懒加载的单例Bean名称然后对每个名称调用beanFactory.preInstantiateSingletons()。preInstantiateSingletons()方法是理解Spring三级缓存的关键。它不是简单地for循环调用getBean()而是分三阶段处理阶段1预创建Pre-instantiation对每个BeanName先检查beanFactory.isFactoryBean(beanName)如果是FactoryBean则获取其创建的Object即factoryBean.getObject()否则直接调用getBean(beanName)。阶段2getBean()的递归调用链getBean(beanName)最终会走到AbstractBeanFactory.doGetBean()这里就是三级缓存的主战场// doGetBean()核心逻辑节选 Object sharedInstance getSingleton(beanName); // 1. 查一级缓存 singletonObjects if (sharedInstance ! null) { return getObjectForBeanInstance(sharedInstance, name, beanName, null); } // 如果一级缓存没命中且是单例Bean则尝试创建 if (isSingleton()) { // 2. 创建前先将beanName放入 singletonsCurrentlyInCreation正在创建中集合 beforeSingletonCreation(beanName); try { // 3. 调用 createBean() 创建Bean实例 sharedInstance createBean(beanName, mbd, args); // 4. 创建成功后放入一级缓存并从正在创建集合移除 afterSingletonCreation(beanName); } finally { if (newlyCreated) { addSingleton(beanName, sharedInstance); } } }但createBean()过程可能触发循环依赖。比如A依赖BB依赖A。这时就需要二级和三级缓存介入一级缓存singletonObjects存放完全初始化好的单例Bean已执行完构造、属性注入、初始化方法。二级缓存earlySingletonObjects存放提前暴露的、尚未完成初始化的Bean仅执行完构造属性还未注入。三级缓存singletonFactories存放ObjectFactory用于延迟创建早期引用避免每次getEarlyBeanReference都新建代理。具体流程当A开始创建时beforeSingletonCreation(A)将其加入singletonsCurrentlyInCreation然后A的属性注入需要B于是调用getBean(B)B创建时也需A此时getSingleton(A)在一级缓存查不到就去二级缓存查也查不到最后查三级缓存——singletonFactories.get(A)返回一个ObjectFactory调用其getObject()生成A的早期引用可能是原始对象也可能是CGLIB代理放入二级缓存再返回给B。这样B就能完成属性注入接着B初始化完成放入一级缓存最后A继续完成属性注入和初始化也放入一级缓存。实操心得三级缓存的设计精妙之处在于它用ObjectFactory替代了直接存原始对象避免了“提前暴露未初始化对象”的风险。我在调试时特意在addSingletonFactory()后加断点观察singletonFactories里存的ObjectFactory如何被getEarlyBeanReference()调用——你会发现这个工厂对象里封装了getEarlyBeanReference()的完整逻辑包括是否需要生成代理、代理类型选择等。这才是读懂“三级缓存原理”的正确姿势。3.4 第4步BeanPostProcessor的介入时机与作用域BeanPostProcessor是Spring最强大的扩展点之一但新手常混淆它的两个方法postProcessBeforeInitialization()和postProcessAfterInitialization()的触发时机。以ApplicationContextAwareProcessor为例它在prepareBeanFactory()中注册它的postProcessBeforeInitialization()在Bean的afterPropertiesSet()InitializingBean和init-method之前执行它的postProcessAfterInitialization()在init-method之后、Bean放入一级缓存之前执行。而AutowiredAnnotationBeanPostProcessor处理Autowired的postProcessProperties()则在populateBean()属性注入阶段执行早于postProcessBeforeInitialization()。更关键的是BeanPostProcessor本身也是Bean它的创建和注册有严格顺序invokeBeanFactoryPostProcessors()执行时ConfigurationClassPostProcessor会扫描并注册所有BeanPostProcessor类型的BeanDefinitionregisterBeanPostProcessors()方法refresh第6步会按PriorityOrderedOrdered 普通顺序将这些BeanPostProcessor实例注册到beanFactory的beanPostProcessors列表中后续所有Bean的创建都会按此列表顺序调用每个BeanPostProcessor的相应方法。我在ioc-case里专门做了个实验定义两个BeanPostProcessor一个实现PriorityOrdered一个实现Ordered然后观察它们对同一个Service Bean的处理顺序。结果证实PriorityOrdered的postProcessBeforeInitialization()一定在Ordered的同名方法之前执行——这个顺序保证了高优先级处理器如CommonAnnotationBeanPostProcessor处理Resource能先于低优先级处理器如自定义日志处理器工作。4. 实操过程手把手带你跑通ioc-case从断点设置到日志解读现在我们进入最硬核的部分如何真正运行、调试、理解ioc-case。这不是概念讲解而是你打开IDEA后每一步该做什么、为什么这么做、预期看到什么的详细指南。4.1 环境准备三分钟完成零配置启动这套材料对环境要求极简JDK17必须因Spring 6.1.0最低要求JDK17IDEIntelliJ IDEA 2023.2免费社区版即可构建工具Maven 3.8.6自带无需额外安装。操作步骤下载项目压缩包解压到任意目录如/home/user/spring-source-study打开IDEA选择“Open” → 选中解压后的根目录IDEA会自动识别为Maven项目等待依赖下载完成约1-2分钟在项目根目录下找到ioc-case模块展开src/main/java → com.example.ioc → IocCaseApplication.java右键点击IocCaseApplication.java→ “Run IocCaseApplication.main()”。注意首次运行时IDEA可能会提示“Maven home directory not specified”点击“Auto-detect”即可。所有依赖spring-framework-6.1.0、junit-jupiter等均已声明在pom.xml中无需手动添加。4.2 断点设置聚焦四个黄金断点位置不要一上来就在refresh()打满断点。根据十年经验这四个位置能覆盖90%的IOC核心逻辑断点位置类名/方法设置理由预期观察点1AnnotationConfigApplicationContext.init()第1行观察容器初始化起点确认reader和scanner创建时机this.reader是否为AnnotatedBeanDefinitionReader实例2AbstractApplicationContext.refresh()第1行理解refresh总控流程确认12个子方法执行顺序调用栈是否显示refresh()→prepareRefresh()→obtainFreshBeanFactory()3AbstractBeanFactory.doGetBean()第1行进入Bean创建核心逻辑观察三级缓存交互getSingleton(beanName)返回值singletonFactories是否包含当前beanName4AbstractAutowireCapableBeanFactory.populateBean()第1行深入属性注入阶段理解Autowired如何工作bw.setPropertyValues(pvs)执行前后Bean字段值变化设置方法在IDEA左侧行号区点击出现红色圆点即为断点右键断点 → “Edit Breakpoint” → 勾选“Suspend: Thread”确保断点暂停对于doGetBean()断点建议右键 → “More” → 在Condition里输入beanName.equals(userService)避免被Spring内部Bean打断。4.3 调试实录以UserService Bean创建为例的完整跟踪我们以UserService为例它被Service标记且依赖UserRepository。以下是我在IDEA中实际调试的完整记录Step 1触发getBean(userService)在IocCaseApplication.main()里context.getBean(UserService.class)这一行执行后程序停在doGetBean()断点。此时beanName userServicegetSingleton(userService)返回null一级缓存为空isSingleton()返回truebeforeSingletonCreation(userService)将userService加入singletonsCurrentlyInCreation。Step 2进入createBean()F8单步进入AbstractAutowireCapableBeanFactory.createBean()。这里会调用resolveBeforeInstantiation()尝试使用InstantiationAwareBeanPostProcessor生成代理如Async调用doCreateBean()执行核心创建。Step 3doCreateBean()中的三级缓存操作在doCreateBean()里关键步骤instanceWrapper createBeanInstance(beanName, mbd, args)调用构造函数创建UserService原始对象addSingletonFactory(beanName, () - getEarlyBeanReference(beanName, mbd, bean))将ObjectFactory存入三级缓存populateBean(beanName, mbd, instanceWrapper)开始属性注入此时userService的userRepository字段为空。Step 4属性注入触发userRepository创建populateBean()调用autowireByType()发现需要UserRepository于是递归调用getBean(userRepository)。此时userRepository的doGetBean()执行同样经历getSingleton()→createBean()userRepository创建完成后userService的userRepository字段被注入userService执行initializeBean()afterPropertiesSet()和init-method最终addSingleton(userService, userService)放入一级缓存。实操心得在addSingletonFactory()后你可以直接在IDEA的“Variables”窗口里展开this.singletonFactories找到key为userService的entry双击valueObjectFactory再点击右侧的“Evaluate”按钮就能看到这个工厂对象getObject()返回的正是userService的早期引用。这种“现场验证”比看一百遍文字描述都深刻。4.4 日志解读读懂Spring启动日志背后的执行逻辑Spring默认日志级别为INFO但ioc-case模块已预置logback-spring.xml将org.springframework包日志设为DEBUG。运行时你会看到类似这样的输出[main] DEBUG o.s.b.f.s.DefaultListableBeanFactory - Creating shared instance of singleton bean appConfig [main] DEBUG o.s.b.f.s.DefaultListableBeanFactory - Creating shared instance of singleton bean userService [main] DEBUG o.s.b.f.s.DefaultListableBeanFactory - Returning cached instance of singleton bean userRepository [main] DEBUG o.s.b.f.s.DefaultListableBeanFactory - Eagerly caching bean userService to allow for resolving potential circular references这些日志不是随便打印的每一句都对应核心逻辑“Creating shared instance…” 表明getBean()正在创建该Bean“Returning cached instance…” 表明从一级缓存直接返回无需创建“Eagerly caching bean…” 是addSingletonFactory()的日志意味着三级缓存已介入。特别注意最后一句“Eagerly caching bean userService to allow for resolving potential circular references”。这句日志出现就证明Spring检测到了循环依赖风险并主动将userService的ObjectFactory放入三级缓存——这是你理解三级缓存是否生效的最直接证据。5. 常见问题与排查技巧实录那些让我熬夜三天的坑即使有了这套材料你在调试过程中依然会遇到各种“看似诡异、实则必然”的问题。以下是我和团队成员在过去三年里踩过的最典型、最高频的12个坑每个都附带真实场景、错误现象、根本原因和一招解决法。5.1 问题1断点进了refresh()但never hit doGetBean()——容器根本没创建Bean现象在IocCaseApplication.main()里打了断点F9运行程序停在refresh()但无论怎么F8都进不了doGetBean()最后抛出NoSuchBeanDefinitionException。排查过程检查AppConfig.class是否被正确Configuration标记检查ComponentScan是否扫描到了UserService所在包在refresh()执行完后添加临时代码System.out.println(context.getBeanDefinitionCount());输出为0。根本原因ComponentScan的basePackages参数写错了。比如UserService在com.example.service包下但ComponentScan(com.example.dao)只扫描了dao包。Spring不会报错只是默默不注册任何Bean。解决方案在AppConfig类上将ComponentScan改为ComponentScan(com.example)确保覆盖所有子包或者更稳妥删除ComponentScan改用SpringBootApplication但注意这会引入Boot自动配置偏离纯Framework学习目标独家技巧在refresh()执行后立即调用((ConfigurableApplicationContext) context).getBeanFactory().getBeanDefinitionNames()打印所有注册的BeanName快速定位扫描失败。5.2 问题2UserService创建成功但userRepository字段为null——Autowired失效现象UserService的构造函数和setUserRepository()方法都被调用但最终userRepository字段仍是null。排查过程检查UserRepository类是否有Repository注解检查UserRepository是否被ComponentScan扫描到在populateBean()断点处观察bw.setPropertyValues(pvs)执行前后的字段值。根本原因UserRepository类被Service标记而非Repository。虽然Service也继承Component但AutowiredAnnotationBeanPostProcessor默认只处理Autowired、Value、Inject而ResourceJSR-250需要CommonAnnotationBeanPostProcessor。但更常见的是UserRepository没有被Spring管理即它不是通过getBean()创建的而是new UserRepository()手动创建的。解决方案确保UserRepository类上有Repository或Component关键检查在IocCaseApplication.main()里不要写new UserService()必须用context.getBean(UserService.class)独家技巧在UserService的PostConstruct方法里添加System.out.println(userRepository userRepository);如果输出null说明注入失败如果输出com.example.repository.UserRepositoryxxxx说明注入成功。5.3 问题3三级缓存日志出现但循环依赖仍报错——BeanCreationException现象日志显示Eagerly caching bean userService但最终还是抛出BeanCurrentlyInCreationException。排查过程确认A和B确实互相依赖AAutowired BBAutowired A检查A和B是否都是单例Scope(singleton)在doGetBean()里观察getSingleton()返回值。根本原因A和B中有一个是原型Scope(prototype)。Spring三级缓存只解决单例Bean之间的循环依赖。如果A是单例B是原型那么每次getBean(B)都会创建新实例无法放入缓存导致循环依赖检测失败。解决方案将B也改为Scope(singleton)或者如果业务确实需要原型改用ObjectFactoryUserRepository注入而不是直接Autowired UserRepository独家技巧在AbstractBeanFactory.beforeSingletonCreation()里加断点观察singletonsCurrentlyInCreation.contains(userService)是否为true这是循环依赖检测的开关。5.4 问题4JDK17运行报InaccessibleObjectException——反射访问失败现象populateBean()执行时field.setAccessible(true)抛出java.lang.reflect.InaccessibleObjectException。排查过程确认JDK版本为17查看异常堆栈定位到Field.setAccessible()调用检查pom.xml中maven-compiler-plugin的source和target是否为17。根本原因JDK17默认启用强封装Strong Encapsulation禁止反射访问模块内非公开成员。Spring的ReflectionUtils.makeAccessible()方法失效。解决方案在IDEA的“Run Configuration” → “VM Options”里添加--add-opens java.base/java.langALL-UNNAMED --add-opens java.base/java.utilALL-UNNAMED或者在项目根目录mvnw.cmdWindows或mvnwMac/Linux脚本里在MAVEN_OPTS中添加相同参数独家技巧在pom.xml的maven-surefire-plugin配置中预置argLine确保所有测试环境都生效。5.5 问题5注释显示“此处应生成CGLIB代理”但实际是JDK动态代理——代理类型判断失误现象UserService实现了UserServiceInterface接口但日志显示Creating JDK dynamic proxy而注释说“此处应生成CGLIB代理”。排查过程检查UserService是否实现了接口检查EnableAspectJAutoProxy是否启用在DefaultAopProxyFactory.createAopProxy()断点观察proxyFactory.getProxy()参数。根本原因Spring AOP默认优先使用JDK动态代理基于接口只有当目标类没有实现接口时才用CGLIB。UserService实现了接口所以生成JDK代理是正确的。解决方案如果强制要用CGLIB添加EnableAspectJAutoProxy(proxyTargetClass true)独家技巧在AspectJAwareAdvisorAutoProxyCreator.wrapIfNecessary()里观察proxyFactory.isProxyTargetClass()返回值这就是代理类型决策的源头。提示以上5个问题覆盖了90%的入门级调试障碍。每个问题我都附上了“独家技巧”这些技巧来自真实项目中的血泪经验——比如那个getBeanDefinitionNames()技巧就是我在帮一个学员排查扫描失败时临时加的debug代码后来发现比看日志快10倍就固化成了标准操作。6. 进阶延伸从这套材料出发你能走多远这套“spring源码深度解析”材料定位非常明确它是你Spring源码学习的本文还有配套的精品资源点击获取