很多Java开发者手头都有过这种感觉Spring框架用了好几年Controller、Service、Repository写得很溜但别人一问你“三级缓存到底是怎么回事”“Transactional为什么有时候会失效”心里就发虚。Spring从二十年前的轻量级容器一步步长成了今天覆盖Spring Boot、Spring Cloud、Spring Security、Spring AI的庞大家族它早就不只是一个框架而是Java后端这整片生态的地基。这篇文章我想用这些年实际开发踩坑攒下来的经验把Spring的控制反转、依赖注入、AOP代理、三级缓存、事务失效这些核心机制讲明白再把Spring Boot的WebSocket配置、监控、接口拆分、微服务跨语言接入、Spring AI集成大模型这些实战场景串起来。不论你是刚学Java的萌新还是写了几年业务想补底层原理的工程师这篇内容应该都能帮你把脑子里那些零散知识点拼成一张完整的图。1. 先搞清楚Spring的本质控制反转到底反转了什么控制反转IOCSpring面试必问但很多人理解停留在“不用new对象了”这个层面。其实IOC反转的是依赖关系的管理权在没有Spring的时候A类要用B类得自己在构造方法里new B或者在方法里new B这种主动去查找依赖的行为叫正向控制。责任全部压在编写A的开发者身上改B的构造方法时所有new过B的代码全要跟着改。Spring做的东西很简单把对象的创建、装配、生命周期管理全收归容器开发者只在配置里或注解里声明“我需要什么”容器在合适的时机把现成对象送过来。1.1 容器和Bean的世界观只要用过Spring就一定写过ApplicationContext context new AnnotationConfigApplicationContext(AppConfig.class)拿到context之后再getBean出来用。ApplicationContext就是那个容器容器里面装的是一个个Bean。Bean这个词听着玄实际上就是一个被Spring接管生命周期的普通Java对象。容器启动时干的事是扫描类、解析BeanDefinition、实例化、属性填充、执行初始化方法最后把成品放进单例池。用生活里的场景理解容器像一个招聘平台Bean是求职者。调用方公司不亲自去人才市场扫人而是把岗位需求依赖声明发给平台平台按需求匹配好简历元数据把人培训好初始化然后直接交付给公司。公司不知道候选人是谁招的、怎么培训的只知道自己拿到一个满足条件的员工。这个“不知道、不关心、不干预”的状态就是控制被反转了。1.2 依赖注入的三种姿势哪种最靠谱注入方式有三种构造器注入、Setter注入、字段注入。构造器注入是Spring官方最推荐的方式把依赖作为构造参数传入用final修饰依赖一旦注入就不可变对象创建时必须把所有依赖备齐不存在半成品状态。项目里我基本推荐这种写法配合Lombok的RequiredArgsConstructor代码很干净。Setter注入适合那种可选依赖比如一个组件的日志对象、缓存客户端没有也能跑。字段注入也就是在属性上用Autowired最省事但在我自己项目里反而比较警惕。字段注入的问题是依赖隐藏看接口签名根本不知道这个类需要哪些协作对象而且单元测试时没法直接new对象传依赖得借助Spring容器跑测试慢且重。顺便说一句为什么Autowired写在字段上也能生效因为Spring有一个BeanPostProcessor叫AutowiredAnnotationBeanPostProcessor在Bean初始化阶段扫描字段上的注解通过反射把依赖塞进去这个机制也是理解Spring一堆“神秘注入”的关键。1.3 Bean的生命周期面试官常问的完整链路一个单例Bean从容器里出生到销毁完整链路大概是实例化构造方法→ 属性填充依赖注入→ Aware回调BeanNameAware、ApplicationContextAware这类→ BeanPostProcessor的postProcessBeforeInitialization → 初始化方法PostConstruct、InitializingBean、自定义initMethod→ BeanPostProcessor的postProcessAfterInitialization → 放入单例池供使用 → 上下文关闭时走销毁方法。注意两个重要节点属性填充阶段做的是注入如果这个Bean启用了AOP代理真正生成代理对象的时机是在postProcessAfterInitialization阶段也就是初始化完成之后容器把Bean放进单例池之前。这一点和后面要讲的三级缓存强相关。很多开发者以为AOP是在实例化时套上去的其实不是AOP代理的生成是对原始Bean的“后处理”先有原始Bean对象再通过代理包装它最后对外暴露的是代理。2. 三级缓存与循环依赖Spring最被低估的机制Spring的三级缓存是面试高频中的高频也是整个容器设计里最有味道的一个细节。三级缓存严格来说是三个Map存的是不同的Bean状态一级缓存存完整成品二级缓存存已经实例化但还没属性填充完的半成品三级缓存存的是生产早期引用的工厂。很多人背了“三级缓存”这四个字却说不清三级为什么是三级下面把它拆开讲。2.1 循环依赖是怎么产生的循环依赖就是A依赖BB又依赖A。比如一个订单服务要调用户服务查用户信息用户服务某个场景又反过来要查订单信息两个Bean互相引用。如果完全不处理容器创建A时发现缺B去创建BB又发现缺A再回来找AA还没创建完于是死锁。这里要区分注入方式。构造器注入的循环依赖基本是救不了的因为构造器注入在实例化阶段就把依赖“焊死”了A构造时需要B实例B构造时需要A实例两边都处于实例化中谁都没法先给出完整对象。处理循环依赖的其实是Setter注入或字段注入实例化A时就算依赖B还没准备好也可以先把A的“壳”创建出来后面再填B的属性这就给了容器操作空间。2.2 三级缓存到底在工作时经历了什么假设A和B互相引用且都用Setter或字段注入Spring的处理流程是这样的创建A调用构造方法A对象在内存里被new出来了此时属性都还是空的。把A封装成一个ObjectFactory放进三级缓存相当于“A的半成品在这里谁需要谁来取”。开始给A填充属性发现要注入B于是转向创建B。创建B同样实例化出B对象放入三级缓存开始填B的属性发现要注入A。B去三级缓存找A发现A的ObjectFactory存在调用工厂取出A的早期引用此时可能是原始A也可能是代理对象把这个引用注入给B。B的属性填充完成B走完初始化流程作为一个完整Bean放入一级缓存。回到A的创建流程A从缓存的引用里获取到B此刻B已经是完整的把B注入A。A走完初始化流程放入一级缓存循环依赖就此破解。关键在第五步B拿到的不是最终状态的A而是提前暴露的早期引用。这恰恰是缓存设计的核心。一级缓存不能提前放半成品否则并发场景下别的线程拿到未初始化完的Bean直接引发空指针二级缓存放的是已经实例化但未初始化的半成品有总比没有好三级缓存存的是工厂工厂的意义在于延迟决定“到底返回原始对象还是代理对象”。2.3 为什么需要三级而不是两级以及哪些循环依赖救不了如果去掉三级缓存只有一级和二级能不能解决循环依赖非AOP场景下其实也能解决B需要A时直接把早期的原始A放进二级缓存给B就行。真正的问题是AOP假如A这个Bean需要被代理代理时机在Bean初始化完成之后。如果只有二级缓存A在被B引用时还没有生成代理对象B拿到的就是原A后续A虽然生成了代理放入一级缓存但B里持有的A还是原始对象AOP增强在B内部完全失效。这显然不能接受。三级缓存里放的是ObjectFactory工厂会在“被拿去注入”的那一刻才执行在工厂逻辑里可以判断如果Bean需要代理就返回代理引用如果不需要代理就返回原始对象。这样B拿到的一定是最终的、正确的对象形态。所以说三级缓存本质上是把代理的生成时机处理延后到了“被循环依赖引用的瞬间”保证无论是否被提前引用最终暴露的对象都是同一个完整形态——代理或原始Bean保持一致。有三个场景循环依赖是救不了的构造器注入的循环依赖仍是死局prototype作用域的Bean因为不缓存无法提前暴露还有Spring Boot 2.6之后默认把spring.main.allow-circular-references设成false直接拒绝循环依赖。所以别把三级缓存当成业务代码里写循环依赖的借口这个机制是Spring在极端场景下的自保手段不是推荐方案。3. AOP底层与动态代理ProxyFactory在偷偷做什么AOP全称面向切面编程说白了就是在不修改业务代码的前提下给某个方法前后织入额外逻辑。Spring里最常见的用法是Transactional、Async、Cacheable这些注解能“凭空生效”靠的就是AOP。但AOP不是魔法它是动态代理Spring创建一个代理对象拦截目标方法调用在执行真实方法前先处理增强逻辑再把调用转发给原始对象。3.1 JDK代理还是CGLIBSpring怎么选JDK动态代理要求目标类实现至少一个接口代理对象基于接口生成只能拦截接口里声明的方法。CGLIB的原理则是生成目标类的子类通过继承和字节码增强来覆写方法不要求实现接口但目标类和方法不能是final的。这俩方式各有边界Spring在纯Framework环境下会遵循一个默认逻辑目标类有接口就JDK代理无接口用CGLIB。Spring Boot从2.x开始把spring.aop.proxy-target-class默认设为true所以很多开发者实际跑起来看到的代理对象其实是CGLIB的。这一点的实际影响是什么如果你用JDK代理注入的是一个具体实现类运行时会报BeanNotOfRequiredTypeException因为容器里Bean类型是代理接口。这也是Spring官方建议“依赖注入优先面向接口编程”的原因之一接口存在代理才能透明地替换实现代码才能真正解耦。3.2 ProxyFactory背后的职责链Spring AOP里有两个容易搞混的概念Advice是增强逻辑本身比如“方法执行前打印日志”“方法异常后发送告警”Pointcut是切入点描述“哪些类的哪些方法要被增强”Advisor把两者绑在一起——一个Advisor就是“在哪个地方执行什么增强”。ProxyFactory是AOP代理的枢纽它根据Advisor信息判断用JDK还是CGLIB创建代理并把Advice织入代理的方法调用流程遇到匹配Pointcut的方法就执行增强链不匹配就直接放行。生产环境里常用Aspect声明切面切面里的Before、AfterReturning、Around最终都会被Spring转换成Advice并包装成Advisor整个过程由EnableAspectJAutoProxy引入的AnnotationAwareAspectJAutoProxyCreator触发。这个Creator本身是一个BeanPostProcessor在1.3节说的postProcessAfterInitialization阶段发现Bean匹配切面时就会返回代理对象而不是原始对象这也是AOP为什么能“无侵入”的原因。3.3 手写一个简化版Spring容器理解才有快感“手写Spring”是很多人的进阶学习法我自己也带着团队做过一个mini版核心流程非常清晰而且对理解IOC和AOP极有帮助。整体就四步扫包、注册BeanDefinition、反射实例化、依赖注入。下面这段代码展示的是最核心的扫包注入部分真实Spring在此基础上加了几十倍细节但骨架完全一致。public class MiniSpringContext { private MapString, Object singletonObjects new ConcurrentHashMap(); public MiniSpringContext(String basePackage) throws Exception { // 1. 扫描包下所有类过滤出带有 MiniComponent 注解的类 SetClass? classes doScan(basePackage); // 2. 实例化所有组件按类名首字母小写作为BeanName放入Map for (Class? clazz : classes) { String beanName lowerFirst(clazz.getSimpleName()); Object instance clazz.getDeclaredConstructor().newInstance(); singletonObjects.put(beanName, instance); } // 3. 遍历所有Bean对标注 MiniInject 的字段执行注入 for (Object bean : singletonObjects.values()) { for (Field field : bean.getClass().getDeclaredFields()) { if (field.isAnnotationPresent(MiniInject.class)) { field.setAccessible(true); String dependName lowerFirst(field.getType().getSimpleName()); field.set(bean, singletonObjects.get(dependName)); } } } } public T T getBean(ClassT clazz) { return (T) singletonObjects.get(lowerFirst(clazz.getSimpleName())); } }实际Spring的doCreateBean远没有这么简单中间有BeanDefinition解析、构造器选择、属性类型转换、各种PostProcessor回调、代理判断但核心思想就是这几步。我强烈建议有时间的读者照着这个骨架自己写一遍写完之后你再看refresh()方法源码障碍会小很多。4. Spring Boot实战边界WebSocket、监控、对外接口Spring Boot把Spring框架的复杂配置变成了约定大于默认但这不代表不用懂配置。实践中有一批场景特别容易踩坑比如WebSocket的集成方式、Actuator监控到底开哪些端点、对外接口应该放哪个服务。这几个问题在社区里天天被问统一聊一聊。4.1 WebSocket集成与yml配置的正确姿势Spring Boot接WebSocket有两条路线。一条是JSR-356标准风格的ServerEndpoint需要先注册ServerEndpointExporter否则注解不会被扫描这个导出器要在配置类里显式声明Bean另一条是Spring封装的WebSocketHandler注册方式通过实现WebSocketHandler接口并注册到WebSocketHandlerRegistry类似拦截器的握手处理器HandshakeInterceptor可以用来做身份校验、传递参数。很多文章在yml里写一堆spring.websocket配置其实Spring Boot对WebSocket的原生配置并不多真正在yml里调整的通常是内嵌服务器端口和WebSocket相关的buffer上限。例如server: port: 8080 tomcat: websocket: max-text-message-size: 10240这点很容易被忽略如果你的服务器是Tomcat并且用的是ServerEndpoint这套标准API那么消息大小限制改的是server.tomcat.websocket.max-text-message-size把它理解成“Tomcat作为WebSocket服务器的参数”就对了。另一个常见问题是同源校验和跨域生产环境一般建议在握手拦截器里做token校验顺手把来源Origin校验做掉。4.2 用Actuator把监控指标暴露出来Spring Boot应用想被监控第一步是引入spring-boot-starter-actuator然后决定暴露哪些端点。默认情况下只有health是暴露的metrics、info、loggers这些都是关闭的。配置很直白management: endpoints: web: exposure: include: health,info,metrics,loggers endpoint: health: show-details: always监控不是看个health就完事实际生产里更常用的是把/metrics接入Prometheus加一个micrometer-registry-prometheus依赖然后暴露prometheus端点Prometheus服务就能定期抓取JVM内存、线程、GC等指标。如果业务需要自定义监控指标比如统计某个核心接口的调用量可以用MeterRegistry注册一个CounterRestController public class OrderController { private final Counter orderCreateCounter; public OrderController(MeterRegistry registry) { this.orderCreateCounter Counter.builder(order.create.total) .description(订单创建总量) .register(registry); } PostMapping(/order) public void createOrder() { orderCreateCounter.increment(); // 业务逻辑 } }这个Counter上报到Prometheus之后配合Grafana面板就能看到实时曲线。很多团队把监控做成“上线之后再补”我的建议是写业务接口时顺手把关键埋点加上等线上出问题再想指标就晚了。4.3 对外接口究竟放哪独立服务还是业务模块要不要为第三方单独拆一个服务这是架构评审经常吵起来的问题。我的判断标准很简单看调用方是谁、接口是否承担开放平台的职责。如果是给企业外部第三方调用的OpenAPI——有独立鉴权、有调用频率控制、有版本演进需求、要对接口单独做文档和SLA承诺——那拆独立服务或者至少拆成独立模块是必要的。因为开放接口的生命周期和内部接口完全不一样外部调用方不可能跟着你内部重构同步升级接口版本要兼容很久独立的服务边界能把这些复杂度隔离掉。如果只是内部服务间调用比如订单服务要调用户服务的查询用户接口那就老老实实放在用户服务这个业务模块里用OpenFeign或者DegRibbon这类服务间调用组件去访问没必要为这种内部接口单独部署一套服务。还有一种融合方案内部接口照旧放在各业务服务额外加一层API网关所有对外请求都经过网关做鉴权、限流、协议转换转发到内部服务。这种方式既不用为每一个第三方接口单独起服务又保持了对外形象的统一可控。所以我一般不推荐拍脑袋说“一律拆服务”或“一律放模块”而是按调用方和生命周期来判断。4.4 IDEA社区版 Spring Boot的开发方案网上总有新人问IDEA社区版能不能做Spring Boot我的答案是不仅能做日常开发完全够用。社区版和旗舰版最直观的差距在于没有Spring Initializr快速建项目也没有Spring Assistant这种代码提示插件。解决方式很简单打开https://start.spring.io选好Spring Boot版本、Java版本、需要的依赖生成压缩包解压后在IDEA里用File - Open把项目导入社区版照样识别Maven工程依赖照拉、代码照写、运行照跑。唯一要适应的就是新建类、配置类等模板不会那么智能但写起来没差的。Spring Framework 5.3.41这类具体版本的jar也无需手工从官网下载在pom.xml里让spring-boot-parent管理版本写上version5.3.41/version告诉Maven强制使用这个框架版本即可依赖传递时会自动拖下来对应jar。这也算是我特别想强调的一点现代Java开发里任何jar都走Maven或Gradle依赖管理直接在本地手工拷jar的行为在稍微正规一点的团队里都是不被接受的。5. Spring Cloud微服务体系Python应用怎么融入微服务体系发展到今天已经很少是纯Java的独角戏了很多团队都有Python做的算法服务、数据服务甚至Node.js写的BFF层。如何把这些异构应用平滑融入以Spring Cloud Alibaba为底座的技术体系是真实的架构问题。5.1 Spring Cloud Alibaba的组件版图先说清楚Spring Cloud Alibaba里面到底有哪些核心组件分别解决什么问题。Nacos承担两个角色服务注册发现和配置中心服务启动后把自己的IP端口注册到Nacos调用方通过服务名去找实例配置中心则管理各个环境的配置文件。OpenFeign是声明式HTTP客户端在Java侧把远程接口定义成一个interface加注解就能像调用本地方法一样调远程服务。Spring Cloud Gateway是API网关负责外部流量接入、路由转发、统一鉴权。Sentinel做限流和熔断保护核心服务不被突发流量打垮。Seata解决分布式事务跨服务的数据一致性由它协调。对应到Python应用关键点在于Nacos、Gateway、Sentinel这些基础设施都不是Java内部物它们是独立运行的中间件通过HTTP或SDK对外提供服务Python应用完全可以直接利用它们。5.2 跨语言接入的三种务实方案第一种方案是Python服务作为独立应用不直接参与Java服务发现只对外提供REST APIJava侧通过OpenFeign或RestTemplate按HTTP地址调用。这个方案工作量最小适合那些调用量不大、数据边界清晰的算法服务。缺点是没有自动服务发现和负载均衡如果Python侧扩容多个实例Java侧需要手动维护地址列表。第二种方案是让Python服务注册到Nacos参与统一服务发现。Nacos提供了OpenAPI也有Python SDKPython服务启动时调用注册接口把自己的地址上报并发送心跳续约。Java侧Feign仍然用服务名去调用负载均衡交给Feign或LoadBalancer处理。这套方案在调用方视角和纯Java服务没有差别但对Python服务的容错、健康检查、优雅下线有要求属于工程上“更重但更正规”的做法。第三种方案是彻底解耦通过消息队列中转。Java和Python服务不直接互相调接口而是把需要协作的数据以事件的形式投递到RocketMQ或Kafka各自消费各自关心的事件。这种异步解耦模式牺牲了一部分实时性换来了极大的弹性某一方挂了消息在队列里堆积恢复后还能继续消费某一方要升级也不用考虑对方是否同步修改接口。如果业务链路本身具备异步特征我强烈建议优先考虑这种方案。实际选型取决于团队边界和业务确定性算法团队能力弱一点的先走HTTP方案职业化程度高、流量大的走Nacos注册上下游有明确事件化场景的直接上MQ。5.3 一个企业办公用品管理系统的服务划分顺便把“基于Spring Boot的企业办公用品管理系统”这种常见的业务项目展开讲一下。这类系统的本质是“采购-库存-领用-审批-统计”的闭环核心模块大概有用户与部门管理、角色权限、办公用品分类和SKU管理、采购入库流程、申请单和审批流、出库记录、库存预警、以及报表统计。如果做成单体单Spring Boot应用里按模块分包就可以没必要一上来就上微服务如果是团队协同开发、需要独立部署和扩展可以按“认证服务、库存服务、审批服务、报表服务”来切。报表服务是单独拆出来的典型例子因为报表查询普遍慢、吃内存和线上交易库放在一起容易互相拖累。审批服务适合依赖工作流引擎比如Flowable或Activiti这也是为什么很多类似项目把审批单独做成一个服务。至于库存和采购业务上强绑定拆开反而增加分布式事务复杂度合并放在同一个服务里更合理。这也是我一直说的拆不拆服务不取决于“为了微服务而微服务”而是看团队的交付节奏和运维成本。6. Spring Security认证授权不是堆FilterSpring Security在Spring Boot生态里基本上是安全方案的默认选项但很多人对它敬而远之觉得过滤器配起来绕。它的原理其实并不复杂Spring Security本质上是一组Filter组成的链路在请求到达Controller之前把认证和授权处理完。6.1 过滤器链的请求旅程一个典型请求进来后会依次经过SecurityContextHolderFilter或旧版的SecurityContextPersistenceFilter、CsrfFilter、UsernamePasswordAuthenticationFilter、ExceptionTranslationFilter、AuthorizationFilter最后才放行到业务Controller。UsernamePasswordAuthenticationFilter负责从登录请求里取出用户名密码交给AuthenticationManager做校验成功后把Authentication对象放进SecurityContextHolderAuthorizationFilter则拿当前用户拥有的权限和请求要求的权限做比对不匹配就直接抛出AccessDeniedException。ExceptionTranslationFilter的角色很特殊它不参与业务判断专门把安全异常转成403或401响应。新版本Spring Security 6里不少类名和过滤链顺序有调整但链路思维是完全一致的。我自己排查安全相关问题时的第一动作永远是打印当前安全过滤链的装配结果看看自定义过滤器到底插在哪个位置。过滤器的顺序错位是绝大多数“配置看着对但就是不生效”的根源。6.2 JWT无状态认证落地要点单体Session模式里服务端存会话客户端拿JSESSIONID每次请求由SessionRepository还原登录态。JWT方案则是把用户信息签名后发给客户端服务端不再存任何会话状态只要验签通过就认为用户合法。Spring Security整合JWT的经典做法写一个OncePerRequestFilter在请求进来时取Header里的Authorization解析并验签JWT解析出用户信息和权限后封装成Authentication放进SecurityContextHolder最后放行。注意这个自定义Filter要加在UsernamePasswordAuthenticationFilter之前这样后续授权过滤器才能从SecurityContextHolder里读到当前用户。Component public class JwtAuthenticationFilter extends OncePerRequestFilter { private final JwtTokenUtil jwtTokenUtil; public JwtAuthenticationFilter(JwtTokenUtil jwtTokenUtil) { this.jwtTokenUtil jwtTokenUtil; } Override protected void doFilterInternal(HttpServletRequest request, HttpServletResponse response, FilterChain chain) throws ServletException, IOException { String token resolveToken(request); if (token ! null jwtTokenUtil.validateToken(token)) { Authentication auth jwtTokenUtil.getAuthentication(token); SecurityContextHolder.getContext().setAuthentication(auth); } chain.doFilter(request, response); } private String resolveToken(HttpServletRequest request) { String bearer request.getHeader(Authorization); if (bearer ! null bearer.startsWith(Bearer )) { return bearer.substring(7); } return null; } }JWT的无状态特性带来一个副作用无法主动让token失效。一旦用户的JWT泄露只能等它过期。所以生产环境一般会把过期时间设短一些比如半小时再加一个refresh token机制来续期。我看过不少项目直接把token有效期设成7天等于把一个长生命周期的钥匙交到客户端手里风险很大。6.3 常见的安全配置坑第一个坑是把Spring Security的过滤器链配置成对所有请求都放行结果等于没安全。正确做法是定义好哪些是公开端点比如登录、注册、健康检查其余一律走authenticated。第二个坑是CSRF的取舍。如果没有浏览器端会话Cookie场景可以关掉CSRF但如果你的系统需要兼容浏览器表单提交关闭CSRF等于把CSRF攻击的窗户打开。第三个坑是CORS配置和Security配置的顺序问题如果CORS过滤器没有排在认证过滤器前面预检请求会被安全链路拦住。第四个坑是方法级安全忘了开PreAuthorize这类注解需要EnableMethodSecurity开启才生效Spring Boot默认是不开的。还有一个非常隐蔽的问题自定义过滤器里用ThreadLocal存了用户信息但没有在请求结束时清理线程池复用线程时下一个请求就“继承了”上一个用户的身份。SecurityContextHolder默认就是ThreadLocal所以一定要养成立即设置、请求结束清空的好习惯否则线上会出现用户串号这种灾难。7. Spring AIJava开发者的大模型集成新选择Spring AI是这几年Spring生态里最让人兴奋的新成员。它把大语言模型的接入抽象成了一组统一的API开发者不需要关心是OpenAI、QWen还是Claude只需要针对ChatModel编程就像以前针对DataSource写SQL一样。7.1 Spring AI与LangChain的对比LangChain在Python生态里很火是一个专门为构建LLM应用而生的框架提供Prompt模板、链式调用、Agent工具、向量检索等能力。Spring AI很多人叫它“Java版的LangChain”但我觉得它和LangChain有一个本质区别Spring AI不是一个孤立的AI框架它长在Spring Boot的自动配置、依赖注入、配置管理、可观测性之上。你用它接大模型不用额外搭一套配置中心不用自己处理连接池不用改造成本去适配监控体系原来那套Spring工程化经验全部可以平移过来。Spring AI也把RAG的核心元件抽象成了VectorStore、EmbeddingModel、DocumentReader等接口和Spring生态无缝衔接。7.2 接入QWen的实操配置接入通义千问的百炼平台非常简单关键是用DashScope的OpenAI兼容端点。Spring AI支持把OpenAI的base-url指到DashScope上这样不用换底层调用逻辑。配置长这样spring: ai: openai: base-url: https://dashscope.aliyuncs.com/api/v1 api-key: ${DASHSCOPE_API_KEY} chat: options: model: qwen-plus代码里注入ChatModel直接调用即可Service public class QwenService { private final ChatModel chatModel; public QwenService(ChatModel chatModel) { this.chatModel chatModel; } public String chat(String message) { return chatModel.call(message); } }注意Spring AI版本迭代比较快2.0之后API有过调整有的事务方法也从ChatClient.Builder变化到了别处。我自己的经验是不要凭旧版本写法套新版本直接看当前锁定版本的官方文档或参考测试用例Spring系列的测试代码永远是最权威的用法示范。模型名称也要以百炼控制台实际开通的白名单模型为准你搜到的资料说qwen-plus实际你的账号里可能叫qwen-max或者更新一代的模型名。7.3 从Dify工作流到Spring AI Agent化不少团队先用Dify这类LowCode平台快速搭出了AI应用原型跑通之后又想把核心链路迁回Java服务内部减少对第三方平台的依赖这条迁移路线在GitHub上也已经有一些案例和技术方案了。从技术上讲Dify里的一条工作流是由多个节点组成的比如大模型节点、知识检索节点、条件分支节点、工具调用节点它们之间用连线表示数据流转。迁移到Spring AI时映射关系非常直观大模型节点对应ChatModel或ChatClient的调用知识检索节点对应VectorStore查询加内容组装工具调用节点用Spring AI的Tool注解声明Java方法即可。Dify里的条件分支在Java里通常变成一个路由方法根据模型返回结果或者业务字段决定走哪个Handler。如果工作流里有Agent节点对应的是Spring AI里基于模型Function Calling的Agent循环模型决定要调用哪个工具、传入什么参数Java框架帮我们执行并回传结果模型再根据结果继续推理直到任务完成。我自己实践下来的建议是Dify适合做POC验证和产品学习线上要求高时把核心链路由Dify迁到代码里换来的不只是性能和可控性还有便于测试、便于版本化、便于自定义逻辑这几点实打实的工程优势。8. 面试题与进阶路线别再背题理解它Spring相关的面试题见过太多人拿“八股文”去背但面试官追问两句就露馅。我个人觉得比较好的学习方式是把面试题当成线索每道题背后都对应一个底层机制理解了机制题目怎么变你都能接住。8.1 高频面试题的底层逻辑整理几个最常见的题和它们对应的底层原理这些都是真实面试里反复出现的常见面试问题底层机制Spring Bean的作用域有哪些默认是什么singleton、prototype、request、session默认singleton三级缓存解决什么问题单例Bean循环依赖时的早期引用暴露Transactional在什么场景下失效自调用不走代理、非public方法、异常被catch、方法内部try-catch吞异常、传播行为配置错误Spring AOP和AspectJ区别是什么Spring AOP基于动态代理运行期织入AspectJ是编译期/加载期织入Spring容器启动流程大概是什么refresh()方法配置解析、BeanFactory准备、BeanDefinition注册、实例化单例BeanFactory和ApplicationContext有什么区别ApplicationContext是增强版BeanFactory加了事件、资源、国际化、自动注册PostProcessor等能力我见过最可惜的面试场景是候选人对“事务失效”背得滚瓜烂熟但问他“为什么自调用会导致事务失效”时卡住了。原因其实很简单Transactional是通过AOP代理生效的自调用时方法内部走的是this的方法没有经过代理对象增强逻辑自然没执行。这个例子也生动地说明Spring里很多现象都和“代理”这个核心概念有关理解了代理一大片问题都通了。8.2 源码阅读路线如果想读源码我不建议从第一行开始往后啃。推荐的路线是抓住主线先找AnnotationConfigApplicationContext的refresh()方法这个方法就是整个容器启动的骨架读它会自然看到invokeBeanFactoryPostProcessors、registerBeanPostProcessors、finishBeanFactoryInitialization这些关键节点然后顺着finishBeanFactoryInitialization走到finishBeanFactoryInitialization里的getBean再走到doCreateBean三级缓存的核心逻辑就在getSingleton和doCreateBean的循环依赖处理里。读完容器创建之后再读AOP代理的部分重点看AbstractAutoProxyCreator这个类Spring的AOP就是通过这个BeanPostProcessor在后置处理阶段创建代理的之前说的三级缓存里的代理逻辑也在这里面呼应。最后读Spring事务事务是AOP在运行时最经典的应用核心类就是TransactionInterceptor。读源码的时候有个小技巧先读测试用例。Spring仓库里每个模块都有大量测试测试用例里展示的用法就是设计者期望的标准用法从测试用例进入源码比从网上搜零散博客高效得多。8.3 我的几个实践建议与避坑心得最后聊几条日常实践里真正有价值的建议。第一写新代码时优先用构造器注入依赖关系一目了然也别为了省事在实现类内部new协作对象那等于把控制权又拿回去了。第二遇到Transactional不生效的问题第一反应是检查调用链是不是同类里的自调用是不是方法不是public是不是异常被吞了。这几条检查完大部分事务问题都能定位。第三升级Spring Boot版本时不要一下跳太多版本比如2.x直接跳3.x会面临javax到jakarta命名空间的全量迁移低版本配置文件里的参数在更高版本可能被废弃升级成本往往比想象中高。第四Spring AI相关的项目版本变化快锁定版本后一定要以该版本对应的文档为准别只看网上教程。我早些年看Spring源码时一度很焦虑觉得类太多记不住后来才明白Spring的核心套路就是那么几个容器管Bean代理做增强过滤器链做安全自动配置做Boot。把这条主线抓住剩下的能力都是在这个骨架上生长出来的。遇到问题先回源码里找调用栈再对着文档确认用法这种习惯比刷一百道面试题都管用。希望这篇内容能帮你把自己的Spring知识串成网而不是继续停留在会写接口但是心里没底的阶段。