1. 先建立整体认知Spring框架到底是什么做了这么多年Java后端被问得最多的问题里一定有一个是“Spring框架的核心到底是什么”很多人用过Spring Boot会写Controller、Service、Mapper注解加了无数个但真要问“三级缓存是怎么回事”“Bean是怎么初始化出来的”就支支吾吾说不清楚了。这篇文章我就从使用到原理、到手写一遍核心链路把Spring框架的前因后果一次讲透。先说结论Spring框架本质上是一套管理对象的容器方案顺带解决了一堆企业级开发的通用问题。对象创建、对象依赖、对象生命周期、事务控制、安全控制、远程调用、AI对接这些看似分散的需求因为有一个统一的容器和统一的编程模型都能用很一致的方式写出来。这就是它统治Java服务端这么多年最根本的原因。这篇文章适合什么人看如果你是刚接触Spring的初学者跟着思路把IoC、AOP这些概念从“背概念”变成“懂原理”如果你已经写了两三年Spring Boot想面试进阶或者排查线上问题第三章的工程规范和第五章的排查实录值得细看如果你对“手写Spring”这种硬核练习有兴趣第四章给出了一条可以落地的实现路径。在往下拆之前我想先聊聊为什么Spring能火起来这决定了你后面理解所有机制的方向。1.1 为什么Spring能统治Java服务端二十多年回到Spring还没出生的时代。Java服务端开发被EJB这套重量级规范压得喘不过气。要写一个业务方法你得继承一堆接口配置一堆XML部署到应用服务器上写个单元测试都费劲。对象之间的依赖关系完全是硬编码想替换一个实现类得改代码重新编译。Spring的出现把局面彻底改变了。它做的第一件大事就是提供了一种极其轻量的编程模型你不需要继承任何框架类不需要实现特定接口一个普普通通的Java类通过容器配置或者一个注解就能被管理起来。这就是“POJO”思想的胜利。任何对象放进容器里容器帮你创建、帮你注入依赖、帮你管理生命周期你只需要关注业务本身。第二件大事是把“控制反转”这个思想落地成了可操作的工具。对象不再自己去new依赖的组件而是声明“我需要什么”容器在合适的时机给塞进来。听起来好像只是把new换成了注入但带来的连锁反应是巨大的代码解耦了、单元测试可以轻松换Mock实现、模块之间通过接口说话而不是具体类。这套模式到今天无论Spring Boot怎么封装、Spring Cloud怎么扩展底层心脏一直没变。再说AOP。事务管理曾经是服务端开发最痛苦的事情之一Spring用动态代理把事务切面织入到业务方法前后你写业务就像写普通的代码事务边界用注解或配置声明一下就行。日志、鉴权、性能监控凡是横向贯穿多个业务模块的逻辑都统一收口到切面里。这个设计理念现在看来平平无奇但在当时真的是降维打击。1.2 Spring框架的模块化设计思路很多人分不清Spring和Spring Boot到底谁是谁。Spring是一个庞大的框架家族Spring Boot只是其中一个让Spring应用跑得更快的启动器。Spring框架本身按照职责拆成了很多模块核心的这几层一定要分清模块作用打个比方spring-core基础工具类、资源访问、类型转换地基spring-beansBean的创建、配置、依赖注入盖房的砖块spring-contextApplicationContext容器国际化、事件、环境抽象整个房子的墙体结构spring-aop面向切面编程动态代理装修团队spring-web / spring-webmvcWeb应用上下文和MVC框架门窗水电spring-tx声明式事务管理物业管理系统为什么Spring要拆成这么多模块而不是一个大而全的包因为不是所有应用都需要Web能力也不是所有应用都用AOP。模块化让你可以按需引入。后面Spring Boot做的starter机制本质上就是帮你在这些模块之上预组装好一套默认配置让“引入即用”成为可能。层与层之间的边界也很清楚。spring-beans只干对象装配的事不依赖spring-webspring-web做得再花哨底层还是通过BeanFactory来拿对象。这种分层带来一个好处你可以在非Web环境比如批处理、消息消费端、单元测试里单独使用Spring的核心能力而不会被迫拖上一大堆用不到的依赖。1.3 从SSH到Spring Boot框架演进路线我最早接触Java后端的时候主流是SSH——Struts Spring Hibernate。Struts管Web层Spring管对象装配和事务Hibernate管数据库映射。写一个接口要配三层XML每次启动Tomcat要等一分钟。后来Spring推出了Spring Boot打着“约定大于配置”的口号把大量的默认配置直接内置了你只要写极少的配置应用就能跑起来。对开发体验的提升是革命性的。Spring Boot的核心是自动配置。它通过spring.factories或者EnableAutoConfiguration机制在classpath里发现你引入了哪些库然后自动装配对应的Bean。你引入spring-boot-starter-web它就帮你把DispatcherServlet、内嵌Tomcat、JSON序列化全部搞定。你引入mybatis-spring-boot-starter它就帮你扫描Mapper接口生成代理。这套机制把“搭建项目”从一两天的时间压缩到了十分钟。再往上是Spring Cloud。微服务时代服务发现、配置中心、网关、熔断、链路追踪每个都是分布式系统绕不开的问题。Spring Cloud把这些问题统一抽象成一组组件配合Spring Boot的自动配置让Java团队能比较平滑地从一个单体应用演进到微服务架构。热词里常有人问“Dubbo和Spring Cloud区别”最简单的说法是Dubbo更偏重RPC调用和服务治理Spring Cloud是一整套微服务技术栈两者解决的问题有重叠但也有侧重点不同。后面第三章我会专门展开。最新的大方向是Spring AI2025年Spring官方在AI领域发力很明显Spring AI Alibaba也推出了自己的方案把LLM调用、向量数据库、提示词模板抽象成Spring风格的API。我在后面也会聊到它和MCP服务的接入经验。2. 核心原理深度拆解IoC容器与三级缓存机制Spring框架最核心、面试最高频的考点集中在IoC容器。尤其是“三级缓存为什么能解决循环依赖”“Bean的完整生命周期是什么”这两个问题几乎成了Java面试的必考题。这一章我尽量不绕弯子把底层逻辑一层层剥开。2.1 IoC与依赖注入的本质“控制反转”这个词听起来玄乎其实一句话就能说清楚创建对象的控制权从程序员手里反转到了容器手里。你不用再关心“这个Service依赖的Mapper是从哪来的”你只需要在字段或构造器上声明需求容器会在合适的时机把依赖给你送过来。依赖注入是控制反转的具体实现方式。常见的注入方式有三种构造器注入、Setter注入、字段注入。实际开发中我更推荐构造器注入原因有几点一是依赖关系在创建对象那一刻就必须完整对象不会出现“半个状态”二是方便单元测试直接new一个真实依赖传进去就行三是更容易发现循环依赖启动时就报错而不是运行到某个方法才NullPointerException。IoC容器在Spring里有两个核心接口BeanFactory和ApplicationContext。BeanFactory是最底层的容器定义了getBean、containsBean这些基础方法ApplicationContext在BeanFactory之上扩展了国际化、事件发布、环境配置解析、AOP集成等能力。日常开发中你拿到的ApplicationContext本质上就是“BeanFactory 一堆企业级能力”。容器管理Bean的配置来源也越来越简单。早期全是XML后来是XML加注解混用再到Spring Boot阶段几乎全是注解。Component、Service、Repository、Controller这些注解最终都会通过ComponentScan扫描进入容器。注解只是入口Bean的完整生命周期才是理解容器能力的关键。2.2 Bean的完整生命周期一个普通的Java类从配置到真正被使用在Spring容器里要经历很多步。我把最关键的阶段列出来实例化通过反射调用构造器创建一个原始对象。属性填充把当前Bean依赖的其他Bean注入进来执行Autowired、Resource等注解的字段和方法。Aware回调如果Bean实现了BeanNameAware、BeanFactoryAware、ApplicationContextAware会回调对应方法让Bean感知自己在容器中的身份或能拿到容器引用。BeanPostProcessor的postProcessBeforeInitialization在初始化前对Bean做一些前置处理。初始化执行PostConstruct标注的方法或者实现了InitializingBean接口的afterPropertiesSet方法以及XML里配置的init-method。BeanPostProcessor的postProcessAfterInitialization这一步最关键AOP动态代理就是在这个环节被创建的。代理对象替换掉原始对象放进容器。使用容器向外界返回的是最终版本的Bean可能是代理对象。销毁容器关闭时执行PreDestroy标注的方法、DisposableBean接口的destroy方法。理解这个生命周期很多问题都能对上号了。比如为什么PostConstruct能拿到注入的属性因为属性填充发生在初始化之前。为什么Transactional在同类调用时不生效因为通过this调用时没有经过代理走的是原始对象的方法事务切面根本没机会织入。为什么代理对象能应用切面逻辑因为postProcessAfterInitialization阶段已经用ProxyFactory生成了替代品。2.3 三级缓存是如何解决循环依赖的这是Spring热词里讨论量最大的一个也是面试官最爱的地方。先明确一个问题循环依赖长什么样A依赖BB依赖A创建A的时候发现需要B创建B的时候又发现需要A如果不做处理就会陷入无限递归。Spring的三级缓存就是三个Map名字起得很直观singletonObjects一级缓存存放已经完整创建好的单例Bean。earlySingletonObjects二级缓存存放已经实例化但还未完成属性注入和初始化的早期Bean。singletonFactories三级缓存存放能生成早期Bean的ObjectFactory。为什么需要三级而不是两级这是理解整个机制的灵魂。假如只有一级缓存A在创建过程中被塞进singletonObjects但此时A的依赖还没注入完如果其他Bean这个时候拿到A去使用会拿到一个半成品出问题。所以一级缓存里只能放完整对象。如果有两级缓存一级二级A实例化后先放进二级缓存B创建时从二级缓存取到A完成属性填充B创建完放进一级缓存A再从一级缓存拿B完成注入。这样看起来也能解决循环依赖为什么Spring非要搞出第三级因为AOP代理。A的代理对象不是在实例化时就生成的而是在postProcessAfterInitialization阶段才用ObjectFactory生成代理。如果只有二级缓存早期暴露的A是原始对象等代理生成后B持有的还是原始对象代理就没法生效了。三级缓存的ObjectFactory解决了这个问题它延迟到“有人真正需要这个早期Bean”的时候才去执行getEarlyBeanReference把代理逻辑提前到这个时机。这样B拿到的就是经过代理处理的A引用和最终A对外暴露的是同一个对象。整个流程我用一个简化版的步骤来还原创建A实例化得到原始对象a。在A尚未完成属性填充前把a包装成一个ObjectFactory放入三级缓存singletonFactories。开始填充A的属性发现需要B于是调用getBean(B)。创建B同样实例化后先放入三级缓存。B填充属性时发现需要A于是调用getBean(A)。此时一级缓存没有A二级缓存也没有但三级缓存里有A的ObjectFactory。执行这个工厂方法拿到早期暴露的A引用如果A需要代理这里会提前生成代理放入二级缓存earlySingletonObjects同时从三级缓存移除。这个A的引用被注入到B中B继续完成初始化成为一个完整对象放入一级缓存。回到A的创建流程从一级缓存直接拿到已经创建好的B完成A的属性填充。A继续走初始化和BeanPostProcessor流程最终也成为完整对象放入一级缓存。这里有一个非常关键的细节三级缓存不是设计出来“专门解决循环依赖”的它的设计初衷是为了让代理对象暴露的时机保持正确。如果你完全不需要AOP二级缓存就够了。正是因为大多数Bean在初始化后会被代理包装Spring才需要第三级缓存在早期暴露时就确定引用指向。还有一个很容易被忽略的坑构造器注入的循环依赖是解决不了的。因为构造器注入在实例化阶段就必须拿到依赖此时Bean还不存在根本无法提前暴露。Spring官方对此的解决方案是建议改用字段注入或Setter注入或者用Lazy打破循环链条。所以如果你遇到循环依赖报错先检查是不是用了构造器注入。3. 工程规范与生态组件选型从单体到微服务再到AI理解了核心原理接下来聊聊实际干活中的工程落地。Spring本身只是一个框架但围绕它已经形成了一整套成熟的工程生态。这一章从项目目录规范、安全认证、微服务组件选型到Spring AI新方向把我踩过的坑和验证过的方案整理出来。3.1 一个能落地的Spring Boot项目目录规范热词里“spring boot目录规范”排得很靠前说明这是很多新团队的痛点。项目一多人一多没有规范的话代码很快变成一锅粥。我经历过好几套不同风格的修改最终沉淀下来一套最适合大部分业务系统的结构com.example.project ├── config # 配置类如WebMvcConfig、SecurityConfig、RedisConfig ├── controller # 接口层只做参数接收和结果封装 ├── service # 业务层接口定义 │ └── impl # 业务实现 ├── mapper # 数据访问层MyBatis的Mapper接口或者Repository ├── entity # 数据库实体对应表结构 ├── dto # 出入参对象和实体分离 ├── vo # 视图对象给前端返回的数据结构 ├── common # 通用类统一返回结果、异常处理、常量、工具类 └── aspect # 切面类日志切面、鉴权切面、限流切面这套结构的核心思想是分层清晰、依赖单向Controller依赖Service不依赖MapperService依赖Mapper不直接操作数据库底层细节Entity只在数据层出现对外的出入参一律用DTO和VO隔离。这样做的好处是当数据库表结构变动时影响的只有mapper和entity不会传导到接口层。再补充几个容易被忽视的工程细节。统一返回结果类需要定义好code、message、data结构并且用全局异常处理器兜底不然Controller里满屏try-catch代码根本没法维护。热词里有“模拟spring 处理静态资源”静态资源的问题也确实常见Spring Boot默认的静态资源路径是classpath下的static目录如果你把前端打包文件放进去注意不要被Security、拦截器拦住最好在WebMvcConfig里显式放行静态资源路径。日志切面建议统一打印请求参数、响应结果和耗时方便线上排查问题。3.2 Spring Security与现代认证授权说到工程落地Spring Security是绕不开的话题尤其是涉及登录认证、接口权限控制的系统。很多初学者觉得Spring Security难用配置繁琐、过滤器链复杂但如果你理解了它的核心模型其实非常优雅它本质上是一条过滤器链链上的每个过滤器处理一类安全关注点。常见的一个组合是Spring Security JWT实现无状态认证。流程大致是这样用户登录时认证成功服务端签发一个JWT返回给前端前端后续每次请求带上这个Token服务端通过OncePerRequestFilter读取Token、校验签名、解析用户信息然后放入SecurityContext供后续授权使用。难点在于怎么把自定义的过滤器插到过滤器链的正确位置。我见过很多事故发生在自定义过滤器放错了位置导致认证逻辑和授权逻辑的执行顺序乱了接口一会儿放行一会儿拦截。热词里还有一条“jdk 21 spring authorization server 自定义过滤器在usernamepasswordauthentic”看起来是复杂的定制场景。我的建议是先分段排查先确认自定义过滤器的Order位置再确认它是否在UsernamePasswordAuthenticationFilter之后执行最后检查AuthenticationManager是否明确暴露。这里有一个排查小技巧把Security过滤链的关键节点日志打开就能看到请求在每一步的状态变化问题出在哪一层一目了然。如果需要快速搭建后台管理系统的权限框架业内比较成熟的方案是直接用若依框架RuoYi改造成自己的基础工程。RuoYi把Spring Boot Spring Security MyBatis Vue这套生态整合得比较完善代码生成器、权限管理、定时任务这些模块都是现成的。很多公司都是拿它做种子工程再根据业务改造。3.3 Spring Cloud微服务组件选型与Dubbo对比单体应用发展到一定规模团队自然会考虑微服务化。Spring Cloud整个技术栈里组件选型是最容易让人纠结的。我用一张表把常见的组件和替代方案列出来这些都是实际生产验证过的主流选择需求常用组件说明注册中心Nacos / Eureka / Consul目前国内用Nacos最多自带配置中心网关Spring Cloud Gateway高性能基于WebFlux统一鉴权、路由转发远程调用OpenFeign声明式HTTP客户端配合Ribbon或LoadBalancer做负载均衡熔断限流Sentinel / Resilience4jSentinel控制台好用规则可以动态推送分布式事务SeataAT模式对业务侵入最小适合大多数场景链路追踪Micrometer Zipkin / SkyWalkingMicrometer是标准门面Actuator暴露指标做监控再说回“Dubbo和Spring Cloud区别”这个高频问题。Dubbo是国内互联网公司带火的RPC框架Spring Cloud是Spring官方主导的微服务整套生态。如果你只是要远程调用和负载均衡Dubbo单点能力很强性能高、治理完善但如果你要的是完整的微服务解决方案——网关、配置、熔断、追踪、认证一套组合拳Spring Cloud会整合得更顺。现在很多项目也会混合使用Spring Cloud做外层架构Dubbo做内部服务间的高性能调用。一句话总结我的选型心得中小团队和绝大多数业务系统用Spring Cloud全家桶就好如果是高并发内部服务调用Dubbo加Nacos也能打不要为了微服务而微服务单体加模块化在绝大多数场景下仍然是性价比最高的方案。热词里有“micrometer spring boot actuator”我补充一句Actuator暴露的health、metrics端点通过Micrometer接入Prometheus是很成熟的标准做法。生产环境一定要做好端点保护只在内网暴露别把info和health之外的端点开在公网。3.4 Spring AI与MCP服务2025年的新方向热词里“spring ai”“spring ai alibaba”热度非常高。Spring AI是Spring官方在2025年主推的AI集成框架它做的事情是把模型调用、提示词管理、结构化输出、向量检索、Agent编排全部收拢到Spring的风格里。你以前直接拼HTTP请求调大模型API现在变成注入一个ChatModel就行。我最想分享的是“如何使用别人提供的MCP服务”。MCP全称Model Context Protocol是模型上下文协议可以理解为AI应用里的“USB接口”。别人把一个MCP服务封装好后你可以像插外设一样接入自己的AI应用。Spring AI Alibaba在接入MCP上有比较完善的支持步骤大体是这样的在pom中引入spring-ai-alibaba-starter和对应的MCP客户端依赖。配置MCP服务器的地址、传输协议SSE或Streamable HTTP以及认证信息。注入McpToolRepository或直接使用工具调用的方式在运行期让模型决定何时调用外部MCP能力。如果有多个MCP服务用统一的工具注册机制管理避免命名冲突。实际操作中你会发现MCP服务返回的结果往往是结构化JSON需要定义好工具描述和入参Schema模型才知道什么时候调、传什么参数。这一点和写OpenAPI文档很像描述写得越清楚模型调用的准确率越高。如果是接入别人搭建好的MCP服务先要一份工具定义清单拿到手再在代码里做好映射。从技术趋势看Spring AI的定位更像是“Java生态与AI之间的适配层”。不要期待它能替代LangChain它的目标是让Java开发者用最少的学习成本把AI能力接入现有业务。2025年这个方向还在快速迭代API变更频繁我建议锁版开发别一有新版本就盲目升级。4. 手写简化版Spring核心链路从零复盘热词里“手写spring”排得很靠前。手写Spring并不是要重复造轮子而是通过实现一个迷你版IoC容器把前面讲的原理真正变成自己脑子里的东西。我带我团队做内部培训时就用这个方式让新人快速理解Spring的骨架。这一章我把核心步骤拆开讲。4.1 手写Spring前需要掌握的底层能力动手之前先把三个基本功打牢反射、注解解析、动态代理。反射让你能够动态地创建对象、读取字段、调用方法不需要在编译期就确定具体的类。Bean的名字是字符串具体类型只有在运行时扫描到Class对象才知道这一切都得靠反射。理解反射的代价也很重要相比直接new反射调用有性能损耗所以Spring容器里对单例Bean做了缓存不会每次都反射创建。注解解析是Spring自动化的基石。框架通过扫描classpath下的类查找标注了特定注解的Class对象再根据注解的属性值决定这个Bean的名称、作用域、依赖关系。理解了这一点你就明白为什么Component可以标记一个Bean为什么可以给注解加参数配置名字。动态代理是AOP的底层支撑。Spring在早期JDK动态代理和CGLIB之间做了适配如果目标类实现了接口用JDK动态代理如果没有实现接口用CGLIB生成子类代理。手写Spring时你至少要会用JDK的Proxy类生成一个简单的代理理解代理对象和目标对象之间的引用关系。4.2 核心实现步骤拆解一个可运行的简化版Spring IoC容器我觉得至少要有下面这七个步骤定位扫描指定包路径获取所有.class文件过滤出候选类。解析读取类上的注解比如自定义的Component、Service解析BeanName。注册把Bean的定义信息Class对象、依赖描述放到一个注册表里。实例化根据Bean定义通过反射创建原始对象。依赖注入扫描字段上的Autowired或Resource注解递归去容器里找依赖的Bean然后反射赋值。初始化调用被PostConstruct标注的方法给扩展点留口子。织入代理对需要AOP的Bean生成代理对象替换掉原始对象存储下来。这里最容易出问题的是第5步和第7步的交互——循环依赖和代理的先后顺序。如果你按照前面三级缓存的设计来组织这几个Map就会自然地实现一套完整的处理流程。我的建议是先实现一个不依赖AOP的简单版本跑通循环依赖再引入代理对象理解为什么三级缓存比二级缓存更合理。4.3 代码级思路演示下面是简化版容器核心getBean方法的伪代码重点展示查找和创建Bean的关键逻辑public Object getBean(String beanName) { // 1. 一级缓存命中说明Bean创建完成直接返回 Object singleton singletonObjects.get(beanName); if (singleton ! null) { return singleton; } // 2. 二级缓存命中说明Bean已实例化但尚未完整初始化返回早期对象 singleton earlySingletonObjects.get(beanName); if (singleton ! null) { return singleton; } // 3. 三级缓存中有ObjectFactory执行后得到早期对象并提升到二级缓存 ObjectFactory? factory singletonFactories.get(beanName); if (factory ! null) { singleton factory.getObject(); earlySingletonObjects.put(beanName, singleton); singletonFactories.remove(beanName); return singleton; } // 4. 缓存都没有则创建Bean return createBean(beanName); } private Object createBean(String beanName) { Class? clazz beanDefinitionMap.get(beanName).getClazz(); // 实例化 Object instance reflectCreate(clazz); // 提前暴露放入三级缓存解决循环依赖 singletonFactories.put(beanName, () - getEarlyBeanReference(instance)); // 填充属性 populateProperties(instance); // 初始化 initializeBean(instance); // 完成AoP织入后放入一级缓存 singletonObjects.put(beanName, instance); return instance; }注意这段代码里三级缓存用的是lambda表达式也就是ObjectFactory。getEarlyBeanReference这个方法在无代理场景下直接返回原始对象在需要代理的场景下会提前返回代理引用。这就是Spring三级缓存机制最精髓的地方。实际Spring源码比这复杂得多比如Bean作用域、懒加载、泛型依赖、Qualifier限定符匹配但主干逻辑就是这一套。通过这个手写过程你会深刻理解“spring 获取对象原理”到底是什么它就是先查缓存、再创建、创建过程中暴露工厂、最终返回完整对象的调度过程。getBean是所有获取对象请求的统一入口不管你是在Autowired字段注入、在XML引用另一个Bean还是在代码里主动调用ApplicationContext.getBean最终都会落到这条链路上。5. 高频问题排查与避坑指南最后一个大章节我想把实际工作中会踩的一些高频坑集中整理出来。这些坑在官方文档里都写得比较含蓄但真正遇到的时候能卡你一两天。每一条都是我或我身边的同事真金白银试出来的经验。5.1 常见问题速查表报错现象根因分析解决建议NoSuchBeanDefinitionExceptionBean没有被扫描到或类型不匹配检查ComponentScan路径、类上是否有Component系列注解、是否存在多个同类型Bean需要Qualifier限定UnsatisfiedDependencyException依赖没有找到最常见是循环依赖构造器注入改成Setter或字段注入或加Lazy打破循环数据库事务不生效事务方法被同类内部调用或方法是private保证事务方法通过代理调用注入自身或拆分到另一个Service用public且外部入口调用静态资源404资源放在了不会被扫描的目录或拦截器拦截了请求确认静态资源在static目录下并在配置里显式放行Mapper接口无法注入Mapper扫描路径没配或类上没有MapperMyBatis自动配置没生效启动类加MapperScan或每个Mapper接口加Mapper代理失效切面不执行目标方法被final修饰或者CGLIB无法继承或者通过this调用自身方法去掉final把切面逻辑放到外置调用链上用AopContext.currentProxy或注入自身这些算是Spring项目里最经典的几类问题。我见过太多项目在排查这些基础问题上耗掉大量时间其实就是对容器的Bean创建原理不熟。你能把第一章和第二章的内容理解了这张表里的绝大多数问题都能自己推出答案。5.2 事务、循环依赖与代理的三联动问题前面提到过同类调用事务失效我再展开讲一个我踩得最深的一次。一个订单服务里方法A调用了同类的方法BB上有Transactional。按道理B应该开事务结果数据没提交成功异常也没被事务捕获。查了半天才发现this调用的B根本没有经过Spring的代理对象所以Transactional注解完全失效。解决办法很常规把B方法所在的逻辑拆到另一个Service类里或者用AopContext.currentProxy()获取代理对象再调用。这个问题的本质是“代理只在容器返回对象时生效内部this调用不走代理”。循环依赖和代理叠加在一起时更隐蔽。一个场景是A依赖BB依赖AB在创建时通过早期引用拿到了A但如果A的AOP代理在后续阶段生成早期引用和最终代理不是同一个对象就会导致B持有的A引用不具备切面能力。Spring用三级缓存里的ObjectFactory延迟生成解决了这个问题但如果你手写容器时没有照顾到这一点就会复现这种诡异表现。排查时最直接的方法是启用启动日志输出Bean创建顺序对比哪个Bean先触发getEarlyBeanReference。5.3 安全与性能排查经验Spring Security相关的问题我遇到最多的有三类一是自定义过滤器没生效排查思路是确认过滤器是否注册到了FilterRegistrationBean中以及顺序值是否冲突二是接口一直401或403用日志把过滤器链执行情况打印出来很快能定位到是哪一环拦截的三是登录接口本身就被安全拦截了需要在SecurityConfig的permitAll里放行登录和其他公开端点。总的原则是先放行再收口先把全链路跑通再逐步加权限规则。另外热词里出现“模拟spring framework存在目录遍历漏洞(cve-2024-38819)”安全上还是多留意一下。Spring官方披露过一些版本存在的漏洞应对方式说得很清楚升级补丁版本或者按官方建议处理特殊路径。不要忽略安全公告这类信息也不要手动去绕过安全机制在自己代码里做特殊编码处理很容易引入新问题。开发规范上我建议强制使用最新稳定的Spring Boot版本并定期跟踪官方安全公告。性能方面Spring Boot Actuator加Micrometer是观察问题的据点。线上接口变慢先看P99耗时和GC表现IoC容器自身很少成为瓶颈常见的问题是Bean创建逻辑里混入了重量级初始化。我见过有团队在PostConstruct里做远程调用导致启动时间翻倍后来改成懒加载才缓解。记住一个原则容器启动阶段只做轻量初始化重量级资源延迟到真正使用时再初始化。5.4 关于目录、热部署与多环境配置的补充最后补充几个日常开发小细节虽然不复杂但能显著提升开发体验。热部署方面spring-boot-devtools在IDEA里有时不生效问题多半是配置没开“Build project automatically”或者项目不是以Spring Boot的main方法启动的。实测下来2025年的IDEA版本配合devtools基本都能正常工作如果某个类不热更新先看编译是否成功再看是否用了远程调试模式。多环境配置上用application-{profile}.yml拆分开发、测试、生产环境配合bootstrap.yml或Nacos配置中心做集中管理。不要把数据库地址、密码这类敏感信息写在代码仓库里应该通过环境变量或云上的配置中心注入。配置出错时Spring Boot会给出非常详细的报错日志从“Failed to bind properties”这类关键字就能快速定位是哪个配置项出了问题。目录规范上再强调一次Controller只做协议转换不要写业务逻辑Service里的事务边界一定要清晰不要在一个方法里同时做订单创建、扣库存、发消息三件事再套一个大事务性能会很差。规范的意义不在于好看而在于出了问题能快速定位新人接手不会一脸懵。写到这里基本的IoC原理、工程规范、手写容器思路和排坑经验都覆盖了。我在实际项目中感受最深的一点是Spring框架的能力几乎都是围绕“容器管理对象”这个核心展开的。你把对象是怎么创建、怎么注入、怎么代理、怎么销毁这一条完整链路吃透了再用Spring Boot、Spring Cloud、Spring AI这些上层生态时会觉得非常顺因为它们的内核并没有变。后面如果你们团队正在做Agent框架、AI服务编排或者微服务治理建议先把Spring容器这一层基础夯实再做上层封装会少走很多弯路。