Spring这套东西我从2008年前后开始用那时候还在配XML一个applicationContext.xml动辄几百行Bean多了人都是懵的。到今天Spring Boot 3.x满天飞Spring AI都出2.0了回过头看这个生态的演进确实有很多值得掰扯的东西。这篇文章我不想写成官方文档的复读机就从一个实际做项目的角度聊聊Spring的版本演进、核心设计思想还有这几年在微服务和AI集成交叉场景里的一些架构实践。这篇文章适合谁看准备系统性学习Spring的初学者写过一段时间Spring但没深究过原理的开发者以及正在做微服务改造、想接AI能力进Spring体系的技术负责人。我会把看着玄乎的三级缓存、控制反转、AOP原理这些概念用大白话加实操案例讲清楚也会分享一些生产环境里踩过的坑。1. 版本演进从SSH时代到Spring AI 2.0这条路上有几个关键拐点1.1 第一代XML配置与Spring 2.x/3.x的统治期很多老程序员都经历过SSHSpring Struts Hibernate时代。那时候Spring的核心价值是工厂——通过ApplicationContext读取XML配置替你创建对象、管理依赖关系。bean iduserService classcom.example.UserService property nameuserDao refuserDao/ /bean bean iduserDao classcom.example.UserDao property namedataSource refdataSource/ /bean这段配置现在看着挺原始但它的价值在当年是革命性的。以前写Java Web对象都是自己在Servlet里new出来的一改依赖就得改代码重新编译。Spring把对象创建和业务逻辑解耦了你只需要告诉容器我要什么类型的Bean容器就给你装配好。Spring 3.0开始引入Java Config这是第一个拐点。Configuration加Bean注解把配置从XML搬进了代码里IDE能提示、编译期能检查比字符串拼Bean id舒服太多了。不过说实话真正让Java Config普及开来的不是Spring 3.0本身而是Spring Boot把它变成了默认方式。1.2 第二代Spring Boot的约定大于配置变革Spring Boot 1.0发布的时候我最大的感受是终于不用再写那一堆繁琐的web.xml、spring-mvc.xml了。它带来的核心变化有三个第一是自动配置Auto Configuration。你引入一个spring-boot-starter-web它根据classpath里有什么jar包自动帮你把DispatcherServlet、Json解析器、嵌入式Tomcat全配好。第二是独立运行的jar包java -jar app.jar直接启动不用再往Tomcat里塞war包了。第三是application.properties/yml的统一配置入口。Spring Boot 2.x进一步跟进Spring 5的响应式编程模型引入WebFlux并且把默认Servlet容器升级到Tomcat 9JDK最低要求到8。这里有个容易被忽略的细节Spring Boot 2.0开始把Spring Cloud的版本适配拆成了独立的spring-cloud-dependenciesBOM这俩的关系开始变得微妙。1.3 第三代模块化与JDK版本强绑定Spring Framework 6.0和Spring Boot 3.0的发布是另一个大节点。要求JDK 17起步还引入了GraalVM Native Image支持——这玩意让Spring应用真正能做到毫秒级启动但对反射、动态代理做了大量限制。Spring 6的另一个重点是AOTAhead-of-Time编译。原来的Spring启动流程是启动JVM - 加载class - 扫描注解 - 反射创建Bean - 应用跑起来。AOT把扫描注解、生成Bean定义这一步挪到了编译期所以Native Image能瞬间起来。代价是什么很多运行时才能确定的东西比如Value注入配置、动态代理都得提前告知编译器否则就报错。这里我插一句个人的判断Spring Boot 3.x的Native Image目前仍然更适合对启动速度有极致要求的场景Serverless、边缘节点普通微服务用JVM模式就足够了没必要为了高科技感给自己找一堆AOT兼容性的麻烦。1.4 为什么会有人问Spring Cloud Alibaba是不是停更了每年都有人问这个问题老实说我也查过好几轮。实际情况是Spring Cloud Alibaba在2023年确实经历了一段相对沉寂的时期因为Spring Cloud本身版本大升级从Hoxton到2021.0.x再到2022.0.xAlibaba这边需要重写适配层。但它并没有真正停止维护2023年下半年之后陆续发布了适配Spring Boot 3.x的版本如2023.0.x系列。我现在的选型建议很简单如果你的系统已经有Spring Cloud Alibaba的Nacos、Sentinel在跑不必恐慌性迁移按官方支持列表做小版本升级即可如果是从零开始选型先评估业务到底需不需要Nacos的服务发现和配置中心能力不要人云亦云地上个微服务。2. 设计思想控制反转、AOP和三级缓存到底在解决什么问题2.1 控制反转IoC的本质不是不用new而是控制权上移很多讲IoC的文章喜欢说不用手动new对象了这只是表象。控制反转真正的含义是对象生命的控制权从调用方转移到了容器。谁创建你、谁注入你、你何时被销毁都由容器说了算。最直观的例子是JUnit和Spring的配合SpringBootTest class OrderServiceTest { Autowired private OrderService orderService; Test void testCreateOrder() { orderService.create(); } }OrderService是被测试的但你不需要在测试类里负责创建它——Spring容器在测试上下文启动时就创建好了你只管注入使用。测试框架和业务代码完全解耦这就是控制反转的收益你不用管理依赖只需要声明依赖。依赖注入DI是IoC的一种实现方式。Spring支持构造器注入、Setter注入和字段注入。我个人的实践原则是优先构造器注入。原因很简单——构造器注入的依赖是强制的不可能出现Object is null的尴尬情况字段注入对测试不友好必须靠Spring容器才能注入对编译期检查也不友好Setter注入适合可选依赖但容易让人忽略依赖关系。说实话我看到很多项目里Autowired满天飞其实坑都在后面。2.2 AOP代理模式在Spring里的一次华丽转身Spring AOP是我自己从会用到理解转变最大的一个点。最初看文档只知道Transactional滚回滚、Around能切日志后来手写了一次ProxyFactory才明白它的本质Spring AOP就是动态代理代理对象在目标对象外面套了一层拦截器链。Component Aspect public class LogAspect { Around(execution(* com.example.service.*.*(..))) public Object logAround(ProceedingJoinPoint pjp) throws Throwable { long start System.currentTimeMillis(); Object result pjp.proceed(); System.out.println(耗时: (System.currentTimeMillis() - start) ms); return result; } }这里有个容易懵的概念Spring AOP基于动态代理支持两种方式——JDK动态代理接口代理和CGLIB子类代理。从Spring 3.2开始CGLIB作为默认Spring Boot在spring.aop.proxy-target-classtrue环境下全部用CGLIB。这就导致一个经典面试坑如果你把Bean声明成接口类型CGLIB代理还能正常工作如果直接用类类型且方法不是public或不是final代理会失效。是的private方法上的Transactional永远不会生效因为CGLIB生成的是子类父类的private方法压根不可见。AOP解决的核心问题是横切逻辑的复用。日志、权限、事务、性能监控这些逻辑散落在每个业务方法里就很痛苦用AOP把它们抽出来业务代码只关心业务切面只关心横切关注点。2.3 三级缓存Spring循环依赖的缓冲垫Spring三级缓存是面试题常客也是很多人背完答案也不知道为什么要设计成三级。先记住核心结论三级缓存是为了解决构造器注入之外的循环依赖问题为的是让代理对象和原始对象保持同一个。// DefaultSingletonBeanRegistry 里三个Map的核心语义 一级缓存: singletonObjects // 完整创建好的单例Bean 二级缓存: earlySingletonObjects // 提前暴露的早期Bean可能还没填充属性 三级缓存: singletonFactories // 生成早期Bean的工厂为什么不能只有两级网上有个经典解释因为AOP代理。假设A依赖B、B依赖A创建A时发现A需要BSpring先创建出A的早期引用一个半成品放进二级缓存然后去创建BB里需要A此时从二级缓存拿到A的早期引用注入B创建完后回填给A让A完成后续初始化。问题在于如果A需要AOP代理代理是在Bean初始化完成后的postProcessAfterInitialization阶段生成的。如果二级缓存里存的是原始对象而最终A返回的是代理对象那么B里注入的A和容器里最终持有的A就是两个不同的对象。三级缓存的作用就是在早期引用阶段就生成代理工厂保证提前暴露的引用和最终Bean是同一个对象。我建议所有学Spring的开发者都去读一下DefaultSingletonBeanRegistry.getSingleton方法这段代码不到100行但把提前暴露、中途填充、最终返回的逻辑演得很清楚。读一遍源码比背十遍八股文有用。2.4 从创建到销毁Spring中Bean的一生Bean的生命周期我习惯用一条线串起来讲扫描 - BeanDefinition合并 - 推断构造器 - 实例化 - 属性填充 - 初始化InitializingBean/PostConstruct/init-method - 使用中 - 销毁DisposableBean/PreDestroy/destroy-method其中最容易出问题的有三个阶段第一阶段是推断构造器。Spring默认用无参构造器如果类只有有参构造器它会用这个有参构造器且参数从容器里按类型找。这个阶段出现问题通常报的是NoSuchBeanDefinitionException。第二阶段是属性填充。Autowired、Resource、Value都在这里生效。有个细节Autowired先按类型再按名字Resource先按名字再按类型。这两个注解的行为差异经常让人在业务代码里排查半天。第三阶段是初始化前后处理。BeanPostProcessor在这个阶段会被调用Spring的AOP、事务、异步、缓存等能力的实现90%都挂在这里。比如AbstractAutoProxyCreator会在postProcessAfterInitialization里判断要不要给这个Bean生成代理。生命周期这块我的实操建议是尽量不要在构造器里做耗时操作不要在PostConstruct里访问还没初始化完成的Bean。你控制不了Bean的创建顺序虽然DependsOn能指定但那是后门最好的做法是依赖容器自己按依赖关系去编排你的代码里不要臆想我肯定比谁先初始化。3. 架构实践从单体到微服务再到AI时代的Spring体系3.1 Spring Cloud AlibabaNacos、Sentinel、Seata该怎么组合很多人把Spring Cloud Alibaba理解成一堆组件的集合但它其实更准确的说法是Spring Cloud规范的一套Alibaba实现。核心是Nacos注册中心配置中心、Sentinel流量防护、Seata分布式事务。我基于生产环境经验拆开说一下。Nacos我把配置中心放第一位。在微服务架构里配置不集中管起来改一个配置要发布十几个服务纯属自残。Nacos的dataId组织方式是${spring.application.name}-${spring.profile.active}.${file-extension}比如order-service-prod.yaml。配置实时推送靠的是客户端长轮询改了配置最多一两秒就能感知到。spring: application: name: order-service cloud: nacos: config: server-addr: 192.168.1.10:8848 file-extension: yaml namespace: prod group: DEFAULT_GROUP注意namespace是隔离环境用的不是给你区分业务模块的。我在项目里见过把每个微服务一个namespace的那是错的namespace应该对应环境dev/test/prod微服务之间靠group或者配置内容去区分。Sentinel流量入口的守护者。它比Hystrix强的地方在于——.feign.sentinel.enabledtrue开启Feign的Sentinel支持后跟OpenFeign配合天然适配而且它不像Hystrix一样项目停更后连个替代方案都没有。Sentinel的链路流控、熔断降级、热点参数限流这几个功能我在生产里都用过。Sentinel最常见的坑是控制台是单机版的无法多实例共享规则。你想把规则持久化到Nacos得自己写一个ReadableDataSource。我提供一个已经验证过的思路用NacosDataSource监听Nacos上的规则配置在SentinelConfig注入FlowRuleManager.registerProperty这样规则就能通过Nacos动态下发。纯粹依赖控制台操作重启服务规则就丢了这个教训我踩过。Seata分布式事务方案。AT模式的原理是业务SQL执行前生成undolog事务提交前先查全局锁分支事务提交时异步删除undolog。AT模式对业务侵入极小但在高并发写场景下全局锁会成为瓶颈。我的建议能不用分布式事务就不用优先考虑事务边界划分、消息最终一致性、本地消息表这些方案。Seata应该放在实在没办法避免跨服务强一致的时候再用。3.2 Spring Boot版本升级的兼容性清单升级Spring Boot版本每次都是牵一发动全身。我总结了一份自检清单照着走能少踩很多坑先看spring-boot-dependenciesBOM版本确认它依赖的Spring Framework版本、Jakarta EE版本Spring Boot 2.x - 3.x的升级javax.*包要全部换成jakarta.*这个改动影响所有实体类、注解spring.factories自动配置文件的写法变了Spring Boot 2.7之后的写法是META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports如果用到Spring Cloud必须同步升级Spring Cloud版本否则会出现NoSuchMethodErrorMyBatis、Redis、Dubbo等第三方starter要逐一看它们对Spring Boot 3.x的支持情况很多老版本直接不能用了有一次我升级到Spring Boot 3.1服务起不来控制台报ClassNotFoundException: javax.annotation.Resource——就是没注意Jakarta迁移。这种问题排查本身不难但如果你不知道是版本升级引起的可能会浪费半天时间。3.3 Spring Boot集成WebSocketyml配置最容易翻车的地方WebSocket在Spring Boot里集成本来不难但yml配置是真的容易抄错网上资料又少又乱我直接写一份能用的。spring: websocket: # 这个前缀不是固定的如果你的项目没有自定义配置可以不加 # 关键是自定义Handler和拦截器 serve-endpoint: path: /ws allowed-origins: * # 或者用ServerEndpoint方式时不依赖spring.websocket需要额外配置ServerEndpointExporter不过说实话Spring Boot原生spring.websocket配置项很有限更多时间你是在写配置类Configuration EnableWebSocket public class WebSocketConfig implements WebSocketConfigurer { Override public void registerWebSocketHandlers(WebSocketHandlerRegistry registry) { registry.addHandler(new MyWebSocketHandler(), /ws) .setAllowedOrigins(*) .addInterceptors(new MyHandshakeInterceptor()); } }这里有个特别容易翻车的地方setAllowedOrigins(*)支持跨域但如果你在拦截器的beforeHandshake里通过HttpSession拿用户信息会发现拿不到——因为握手阶段默认不启用Session。需要在registerWebSocketHandlers里加一行.withSockJS()不SockJS是给老浏览器用的现在直接原生WebSocket即可。真正稳妥的做法是在HandshakeInterceptor的beforeHandshake里从request.getParameter(token)拿认证信息再放到WebSocketSession.getAttributes()里业务处理时直接读public class AuthHandshakeInterceptor implements HandshakeInterceptor { Override public boolean beforeHandshake(ServerHttpRequest request, ServerHttpResponse response, WebSocketHandler wsHandler, MapString, Object attributes) { String token ((ServletServerHttpRequest) request).getServletRequest().getParameter(token); // 校验token合法就把用户信息塞进attributes attributes.put(userId, userIdFromToken(token)); return true; } }而且要注意Spring的ServerEndpoint方式和Spring MVC的WebSocketHandler是两条体系两者不能混用。你要么全走注解要么全走接口。混用会出现一个端点连不上、另一个端点莫名404的怪问题。3.4 Spring AIRAG、NL2SQL和人称下一代幻觉解药的Agent框架Spring AI是Spring官方杀入生成式AI领域的尝试从3.x/4.x的陌生到2.0变得成熟我大概经历了它三个版本迭代。很多人拿Spring AI和LangChain现在还有个LangGraph4j比较我一开始也在纠结后来实践下来想清楚了如果团队是Java为主的Spring AI绝对是最佳选择如果团队能接受Python那把AI原生当主语言用LangGraph也不违和。Spring AI的核心抽象是ChatClient。2.0里它的API大幅简化我们公司目前代码长这样RestController public class ChatController { private final ChatClient chatClient; public ChatController(ChatClient.Builder builder) { this.chatClient builder.build(); } PostMapping(/chat) public String chat(RequestBody ChatRequest request) { return chatClient.prompt() .user(request.getMessage()) .call() .content(); } }是不是有点Spring Boot 1.x那种少配置、多干活的感觉了而且ChatClient支持stream()流式响应前端配个EventSource就能实现打字机效果不用自己管理WebSocket推送。**RAG检索增强生成**是我认为Spring AI目前最有实际落地价值的功能之一。核心思路是用户提问前先从向量数据库里检索相关资料把它拼进Prompt里让大模型基于这些内容回答减少幻觉。Spring AI的VectorStore接口默认实现里有SimpleVectorStore、PgVectorStore、RedisVectorStore等。我做过一个企业知识库问答系统流程是文档上传后切分文本用TokenTextSplitter块大小根据模型token上限来定通常500~800字/块文本向量化OpenAiEmbeddingModelembedding模型向量写入Redis的VectorStore用户提问后question也向量化先从Redis里做相似度检索取top5把检索出的文本块和用户问题组装成PromptChatClient调用LLM生成回答这套流程里最难的不是写代码而是切分策略。切太碎了信息缺失切太整了检索不精准需要根据业务文档类型去调。我当时调了几轮才确定按自然段切、每段512个字符、重叠64个字符的方案。NL2SQL自然语言转SQL这个方向非常有价值但也是最容易翻车的大坑。Spring AI Alibaba的NL2SQL解决方案给了Java生态一个入口。本质思路是给模型提供数据库Schema信息表名、字段名、字段注释、样例值让模型生成SQL然后执行返回结果。Component public class SqlAdvisor { private final ChatClient chatClient; private final JdbcTemplate jdbcTemplate; public String ask(String question) { String schemaInfo loadSchemaInfo(user_order); String prompt 你是一个SQL专家。根据以下表结构信息回答用户问题。 表结构%s 用户问题%s 请只输出可执行的SQL不要输出额外解释。 .formatted(schemaInfo, question); String sql chatClient.prompt().user(prompt).call().content(); return jdbcTemplate.queryForList(sql).toString(); } }注意这里面有个大坑让模型直接生成SQL是极端危险的生产环境一定不能凑合。我踩过一次模型把SELECT * FROM user_order直接执行了一次性拉全表数据。正确的做法是加SQL白名单校验。最简单的方式是让模型只生成结果列和过滤条件表名你从Prompt里限定再对SQL做正则检查禁止;、禁止DELETE、禁止DROP。更稳的方式是让模型输出结构化查询条件JSON格式由你用参数化查询来拼SQL压根不给模型直接拼SQL的机会。手写Spring这个热搜词我特别想展开说两句。很多人问有必要手写Spring吗我的看法是学习阶段真正手写一个迷你IoC容器把Component扫描、依赖注入、单例池、AOP代理都实现一遍远比你看十遍源码解析视频有效因为这能逼你把IoC、DI、AOP这些概念从背定义变成动手造。但要在生产项目里手写一个Spring替代品那纯属自找痛苦——除非你的场景有极其特殊的约束比如超低内存IoT设备否则维护一个不完整的框架比复用成熟框架贵得多。3.5 业务架构实战餐饮SaaS里怎么把Spring、AI和微服务体系串起来我前两年做一个餐饮SaaS项目业务是给连锁餐厅提供点餐、会员、库存、数据分析一体化系统。架构从单体慢慢演进到微服务又接入了AI助手。技术栈大概是后端Spring Boot 3.x JDK 21服务治理Spring Cloud AlibabaNacos持久层MyBatis-Plus MySQL RedisAISpring AI 2.0ChatClient RAG前端对接OpenFeign Gateway配置Nacos配置中心 bootstrap.yml引导整个链路是这样餐厅顾客小程序点餐 - 请求到Gateway - 路由到order-serviceorder-service写订单、更新库存通过Feign调用inventory-service库存扣减成功MQ异步通知settlement-service做结算AI助手独立成ai-service接Spring AI回答用户我这个月烧烤类菜品销量怎么样这类问题ai-service通过RAG检索门店历史报表再走NL2SQL生成取数SQL查库后把结果送回对话里这套架构跑下来的实际体感Spring Boot 3.x JDK 21的组合非常稳虚拟线程在IO密集场景下提升明显尤其是我们那个用WebSocket做订单实时推送的模块Nacos做服务发现和配置中心完全够用但要做好命名空间隔离Sentinel在峰值时段的限流效果可以不过规则持久化一定要做否则每次发版都要重置规则那体验太痛了。餐饮行业特有的一个问题是门店创建和菜单发布的事件通知。门店创建后订单、库存、AI知识库都要感知不能硬编码发起十次远程调用。我们用Spring事件监听做解耦Service public class StoreService { Autowired private ApplicationEventPublisher publisher; public void createStore(StoreDTO store) { // 写库 publisher.publishEvent(new StoreCreatedEvent(this, store.getId())); } } Component public class AiKnowledgeBaseListener { EventListener public void onStoreCreated(StoreCreatedEvent event) { // 异步把门店基础信息放入RAG知识库 } }这一手在项目里帮了大忙。新门店上线时AI助手立马能用上它的菜单和门店信息不用等到人工同步——这就是Spring事件机制带来的架构柔韧性。4. 排查实录Spring项目里最常见的8类诡异问题4.1 事务失效Transactional在哪些场景下静默失效事务失效是生产环境最隐蔽的问题因为它不报错只是数据不对。我遇到最典型的几个场景同类内部调用OrderService.saveOrder()里调用同类sendCoupon()sendCoupon标了Transactional但它不会走代理对象所以事务不生效。解决办法是自注入或拆出另一个Service。非public方法CGLIB代理基于继承private方法根本覆盖不到。异常被吞try-catch捕获了异常后没重新抛出事务自然感知不到就不会回滚。数据库引擎不支持MySQL要用InnoDBMyISAM不支持事务这个古老问题现在偶尔还能碰到。传播行为设置REQUIRES_NEW开新事务但外层事务回滚时内层已提交的数据不会回滚这有时是预期行为但如果你没意识到就会觉得很奇怪。排查事务问题我的经验是直接看日志里的事务日志级别Spring Boot里加logging.level.org.springframework.jdbc.datasource.DataSourceTransactionManagerDEBUG就能看到每个事务的开启、提交、回滚过程一眼定位到是哪个路径没有走代理。4.2 Druid连接池removeAbandoned配置究竟是救命还是添乱热搜词里那条spring.datasource.druid.remove-abandonedtrue的配置。这条配置的本意是移除超过removeAbandonedTimeout未关闭的连接防止连接泄漏。spring: datasource: druid: remove-abandoned: true remove-abandoned-timeout: 180 log-abandoned: true但注意这个参数是double-edge sword。如果在正常运行的长事务里某个连接持有超过180秒比如批量导入数据会被Druid误杀导致事务异常中断。我曾经在一个大表导出功能上被坑过——连接被当成泄漏移除事务回滚业务还一脸懵。我的建议先定位真泄漏再启用removeAbandoned。通过log-abandoned: true把被移除连接的产生点打出来它会打印栈日志看看到底是哪段代码拿了连接没归还。如果确认没有泄漏就把它关掉或者把超时时间设得足够大比如600秒以上宁可让它常驻也别误杀。4.3 Caffeine缓存Spring Cache抽象的瑞士军刀Spring Boot集成Caffeine缓存配置很简单但很多人不知道CacheManager和底层缓存之间的绑定关系。Configuration public class CacheConfig { Bean public CacheManager cacheManager() { CaffeineCacheManager cacheManager new CaffeineCacheManager(user, order); cacheManager.setCaffeine(Caffeine.newBuilder() .initialCapacity(100) .maximumSize(5000) .expireAfterWrite(Duration.ofMinutes(10))); return cacheManager; } }实际使用中我最推荐的用法是组合缓存热点数据用Caffeine做一级缓存数据量大的用Redis做二级缓存。Spring Cache的Cacheable注解抽象了这层但要注意缓存穿透和缓存击穿的问题不能完全靠CacheManager解决。穿透要配合Cacheable(sync true)让并发请求只放一个进去查库击穿要为null值也做短期缓存。Caffeine的expireAfterWrite是写入后过期适合不常变的数据expireAfterAccess是访问后过期适合读多但需要活跃性的数据。别选错了否则你会出现明明写了数据却要等10分钟才看到新的这种尴尬。4.4 第一个Spring Boot程序就跑不起来99%的坑都在这里第1关第一个Spring Boot程序这个热搜词我讲过太多次入门课了。新手跑不起来90%的情况是下面几个原因JDK版本和Spring Boot版本不匹配Spring Boot 3.x要求JDK 17你装个JDK 8肯定起不来。用java -version先确认。Maven依赖下载慢没有配置国内镜像源spring-boot-starter-parent下到一半卡住了。配置阿里云镜像或者用腾讯云、华为云的Maven仓库代理几秒钟下完依赖。启动类不在顶层包Spring Boot默认扫描SpringBootApplication所在包及其子包。你把Controller放在启动类同级的controller包下就行别放到别的工程目录里。端口被占用8080端口被占用启动报错是最常见新手的困惑。改成server.port: 9090或换个端口即可。数据库连接没配项目里引入了spring-boot-starter-data-jpa或者POM里有了MyBatis依赖但没有配置spring.datasource.url启动时会尝试连接数据库然后报错。最后一个特别值得说Spring Boot的自动配置是看菜下饭——你classpath里有什么jar包它就把对应的东西给你配置好。所以新手新建项目先只加spring-boot-starter-web把Hello World跑通了再一个个加其他的starter每加一个就启动一次。这个方法能帮你精准定位是哪个配置引起的启动失败排查效率最大。4.5 若依RuoYiSpring Cloud配置文件里的门道若依的Spring Cloud版本是很多中小公司拿来直接做二次开发的基础框架。它的配置文件结构是ruoyi-auth、ruoyi-gateway、ruoyi-system、ruoyi-visual/monitor各自维护自己的配置文件在bootstrap.yml里从Nacos拉取公共配置。spring: application: name: ruoyi-gateway cloud: nacos: config: server-addr: localhost:8848 file-extension: yaml shared-configs: - dataId: ruoyi-common.yaml group: DEFAULT_GROUP refresh: true我拿到若依框架后的第一个动作就是改这套共享配置的拆分方式。默认把所有公共配置放在一个大yaml里看着省事但上线后每个人都往里面加东西变成一个大泥球。我的经验是三个shared-configs分别切分——common-db.yaml放数据源common-redis.yaml放缓存common-security.yaml放安全配置。发布变更时你只需要动对应的文件别的服务不受影响出问题回溯也快。还有一点值得注意若依自带的权限体系是基于Spring Security JWT的网关层的权限校验默认是按路径前缀匹配/auth/**、/system/**这些如果你在二开时加了新的微服务前缀一定要在ruoyi-gateway配置的security.ignore.whites里加白名单不然每一个请求都会被401拦掉排查这个问题的过程是真的酸爽。4.6 手写Mini版Spring对理解体系的帮助有多深我强烈建议学习Spring的人手写一个迷你版容器不用多复杂实现以下功能就行实现ComponentScan扫描指定包下的类实现Autowired注入依赖实现Value读取properties配置实现单例Bean池测试内部调用事务不生效的代理边界这五个功能写完你对Spring最底层的理解就建立了容器本质是一个大Map 反射 代理的组合。这和看源码解析视频的收获完全不一样——你会知道Bean是怎么被扫描到的、代理是何时裹上去的、为什么翻译到配置解析顺序错了会出问题。我在带新人的时候通常不让新人先去翻Spring源码而是先让他们写这个迷你容器一般写完再回头看源码理解速度飞快。5. Spring AI 2.0实战细节从ChatClient到RAG和NL2SQL的连接方式5.1 Spring AI 2.0和LangGraph4j到底选哪个这几天热搜里现在到底用Spring AI还是LangGraph4j这个问题争论很热闹。我真实感受是两者出发点不一样。LangGraph4j是对LangGraph的Java移植核心概念是图编排——节点、边、状态机你可以精细控制Agent的每一步工具调用与推理路径。它的优势是适合复杂Agent任务、多Agent协作场景的流程编排。Spring AI 2.0的理念要轻很多它更强调我就是Spring生态的一部分你用ChatClient打完一个问答还能复用Spring的AOP、缓存、事件机制学习曲线更平滑。如果产品是给企业做知识助手、报表问答流程相对固定Spring AI完全够用如果你要做多Agent自主决策、任务规划的复杂工作流LangGraph4j的多配置梯队可能更合适。我在一个客服工单自动分单项目里同时用过两者最终选了Spring AI——原因是我们的调用链路需要和现有的Nacos配置、SkyWalking链路追踪、Spring事件机制协同跟Spring体系的无缝集成比灵活编排更重要。5.2 Spring AI的流式输出和WebSocket怎么配合前面说WebSocket集成现在说AI的流式输出。ChatClient支持stream()返回FluxString前端如果用SSEServer-Sent Events最方便但部分场景我们后端要先做处理再推给前端就可以直接接WebSocket来推。ServerEndpoint(/ai/chat) Component public class AiChatWebSocket { private final ChatClient chatClient; public AiChatWebSocket(ChatClient chatClient) { this.chatClient chatClient; } OnMessage public void handleMessage(String message, Session session) throws IOException { chatClient.prompt().user(message).stream() .doOnNext(chunk - { try { session.getBasicRemote().sendText(chunk); } catch (IOException e) { throw new RuntimeException(e); } }) .subscribe(); } }这个做法效果不错但有个性能细节要提醒每次WebSocket消息都创建一次ChatClient调用会重复构建Prompt上下文。如果用户连续对话多轮你需要把历史会话摘出来拼进Prompt而不是每次只发最新一句。最简单的做法是把会话窗口存在Redis里消息来时先取最近5轮拼好再发给模型效果会提升一个档次。5.3 NL2SQL的最后一公里从SQL生成到安全执行NL2SQL我前面粗略提了这里把安全执行讲透。生产环境里最实用的防御措施是不直接执行模型生成的SQL改成让模型生成查询条件。比如用户问周末烧烤类卖了多少单你让模型输出JSON{ startTime: 2025-11-29 00:00:00, endTime: 2025-12-01 00:00:00, category: 烧烤, metric: ORDER_COUNT }然后你的代码把这些条件映射成参数化SQLString sql SELECT COUNT(*) FROM order_detail WHERE category ? AND create_time BETWEEN ? AND ? ; jdbcTemplate.queryForObject(sql, Long.class, json.category(), json.startTime(), json.endTime());这样SQL注入的风险就全部消灭了——模型只能输出数据不能输出代码。白名单层面的措施也要做禁止DELETE、DROP、UPDATE、ALTER开头的语句禁止分号拼接。多一层保险总没错。5.4 RAG落地经验企业知识库问答系统的调参记录RAG项目最锻炼人的是调参与排查。我分享两组关键参数是我在真实知识库上反复调试得到的文本切分参数通用文档chunkSize512chunkOverlap64separator(\n\n优先然后是句号)法律合同类句子长度偏长chunkSize可以调到768chunkOverlap调到128代码类文档按代码块边界切避免把一段完整函数切断检索TopK与Prompt初始TopK5召回了但答案不准确时尝试把TopK提到8如果回答出现幻觉编造文档里没有的内容考虑调低到3并且Prompt里强调若资料中未提及请明确回答不知道Prompt里我习惯给每段资料加来源ID方便输出时标注信息来源库存管理制度.docx第3节。这个在知识库产品里是刚需否则用户不敢信你的答案还有一点容易忽视embedding模型对领域词汇的支持。通用embedding模型对生僻词比如医疗术语、法律词汇效果差检索出来的相关度不咋地。这个问题没法靠调参根治要么微调embedding模型要么在切分前做领域词典扩充把专业术语替换成更通用的描述。中小项目前期用BGE、M3E这些中文embedding模型就能跑别一上来就整微调成本太高。6. 写在最后Spring体系的学习路线和几个清醒的建议Spring这套生态太大了学习路径如果不规划很容易陷入半年还在学框架轮子的怪圈。我根据自己的经历给四条个人经验第一先学Spring Boot不急着啃Spring源码。上手就通过Spring Initializr创建工程把Hello World跑起来再用spring-boot-starter-web写几个接口你会对框架帮你做了什么有一个直观体验。看源码是后面的事千万别一开始就扎进Bean生命周期里出不来。第二理解了自动配置你就理解了Spring Boot一半。你完全可以自己定义一个META-INF/spring/...AutoConfiguration.imports写一个ConditionalOnProperty的自动配置类让它根据配置是否加载某个逻辑。这个实验做完你对Spring Boot的认知会从魔法框架变成可控制的工程工具。第三Spring Cloud和Spring AI要学会选型不要求新求全。Spring Cloud Alibaba当前版本稳定就上生产Spring AI适合已Java技术栈的项目接入AI能力。不要在技术选型上用谁新上谁的思路生产环境第一原则是能扛峰值、能快速定位问题。Spring AI 2.0再新如果你的业务根本不需要对话能力上了也是给项目添乱。第四读源码的优先级可以这样排先读AnnotationConfigApplicationContext的refresh方法再读DefaultSingletonBeanRegistry的getSingleton方法然后读AbstractAutoProxyCreator的postProcessAfterInitialization方法最后读TransactionalInterceptor的invoke方法。这四个方法是Spring近一半的精华所在。最后分享一个小技巧——排查Spring问题别只顾着看业务代码从spring.factoriesBoot 2.7之后是AutoConfiguration.imports入手看看当前classpath下到底自动装配了哪些Bean很多莫名行为其实就是某个自动配置类在起作用。你可以在启动时加--debug参数打印Auto Configuration Report里面会告诉你哪些配置生效了、哪些被排除掉了这比瞎猜高效得多。Spring这套体系学了十几年越往后越觉得它最牛的地方不是哪个具体组件而是它总能在正确的时机把新理念沉淀成标准化的基础设施——从IoC到微服务再到AI它始终让Java开发者用同一套心智模型去消化变化。这才是它值得深耕的核心原因。