很多人第一次接觸 Spring其實都是從Spring 是什么這樣一個看似簡單的問題開始的。但真要把這個問題講明白往往又不知道該從哪說起——因為Spring這三個字今天已經(jīng)不只是那個 2004 年發(fā)布的輕量級框架了它是一整片生態(tài)Spring Framework、Spring Boot、Spring Cloud、Spring Security、Spring AI……面試的時候問一句講講你對 Spring 的理解能把人說懵。這篇文章我想換個角度不鋪開講 API而是從Spring 到底解決了什么問題出發(fā)結(jié)合我自己這些年用它的真實體感把這片生態(tài)的全貌串一遍順便把大家搜得最多的一些點——三層緩存、手寫 Spring、微服務(wù)集成、Spring AI——都放進(jìn)對應(yīng)的場景里講清楚。適合所有剛?cè)腴T Java 后端、準(zhǔn)備面試、或者用了 Spring Boot 但一直沒搞懂底層邏輯的讀者。1. Spring 到底是個什么東西從它誕生的那天說起聊 Spring 之前得先知道它出生的背景。2002 年前后Java 企業(yè)級開發(fā)的主流方案還是 EJBEnterprise JavaBeans那玩意兒出了名的重寫一個簡單的業(yè)務(wù)邏輯要配一堆 XML、要部署到專門的應(yīng)用服務(wù)器、要繼承各種接口本地接口、遠(yuǎn)程接口、Home 接口層層套。Rod Johnson 在《Expert One-on-One J2EE Design and Development》那本書里提了一個觀點——輕量級容器的思路可以替代 EJB 的復(fù)雜度重點放在對象管理和依賴管理上而不是重量級的中間件。后來這本書的代碼演化成了 Spring Framework 1.02004 年正式發(fā)布。所以你要記住第一件事Spring 最開始不是奔著微服務(wù)去的它要解決的是Java EE 開發(fā)的過度復(fù)雜。它的兩個最核心的武器一直沒變過——控制反轉(zhuǎn)IoC和面向切面編程AOP。到今天Spring Boot、Spring Cloud 管得再寬地基還是這兩個東西?，F(xiàn)在你搜Spring搜出來的其實是一個五層生態(tài)Spring Framework地基包含 IoC 容器、AOP、事務(wù)管理、Web MVC、JDBC 封裝等核心模塊。Spring Boot基于 Framework 的自動配置層把大量樣板配置干掉讓你能一個 main 方法啟動項目。Spring Cloud微服務(wù)治理套件集成了服務(wù)發(fā)現(xiàn)、配置中心、網(wǎng)關(guān)、熔斷器這些分布式組件。Spring Data / Spring Security / Spring Batch分別解決數(shù)據(jù)訪問、認(rèn)證授權(quán)、批處理等特定領(lǐng)域問題。Spring AI2023 年之后的新方向把 LLM大語言模型、向量數(shù)據(jù)庫、Agent 這些 AI 能力接入 Spring 生態(tài)。所以當(dāng)面試官問Spring 是什么最好的回答不是背概念而是說清楚Spring 是一個以 IoC 容器為核心、通過 AOP 提供橫切能力、并逐步擴(kuò)展出完整企業(yè)級解決方案的 Java 應(yīng)用框架生態(tài)。這個定位是從第一天到現(xiàn)在都沒變過的。2. 控制反轉(zhuǎn)與依賴注入Spring 真正的立身之本2.1 IoC 容器到底反轉(zhuǎn)了什么控制反轉(zhuǎn)Inversion of Control這名字太抽象我換個說法。以前寫代碼A 類要用 B 類你得自己在 A 里面new B()這是正轉(zhuǎn)——對象之間的依賴關(guān)系由對象自己控制。IoC 干的事是把創(chuàng)建對象和組裝依賴的控制權(quán)從業(yè)務(wù)代碼里拿出來交給容器統(tǒng)一管理。你只需要告訴容器我需要一個 B 類型的對象容器就會在合適的時機(jī)把 B 實例化好、注入到 A 里面去。這個反轉(zhuǎn)帶來的優(yōu)勢平時體會不深一旦要寫單元測試就非常明顯。比如 A 依賴了一個外部支付接口 P如果你在 A 里new P()測試的時候根本 mock 不掉但如果 P 是通過構(gòu)造器注入進(jìn)來的測試時傳一個 mock 實現(xiàn)就行。這就是依賴注入Dependency InjectionDI對可測試性的意義。Spring 的 IoC 容器默認(rèn)是DefaultListableBeanFactory它在啟動時做三件事掃描根據(jù)配置或注解找到所有需要管理的類BeanDefinition。實例化按照依賴關(guān)系依次創(chuàng)建 Bean 實例。注入把依賴的對象通過構(gòu)造器、Setter 或字段注入到目標(biāo) Bean 中。依賴注入有三種常見方式我個人的建議很明確注入方式寫法優(yōu)點缺點我的建議構(gòu)造器注入public A(B b)不可變、必填依賴明確、便于測試依賴多時構(gòu)造器參數(shù)膨脹首選Setter 注入Autowired void setB(B b)可選依賴靈活依賴可能未初始化、可被修改可選依賴用字段注入Autowired private B b;代碼最簡潔難測試、隱藏依賴、違反不可變不推薦在業(yè)務(wù)代碼用注意很多老項目大量使用字段注入能跑不代表好Spring 官方文檔明確推薦構(gòu)造器注入原因是它能讓依賴關(guān)系在編譯期就明確下來而不是運行到一半才發(fā)現(xiàn) NPE。2.2 三級緩存為什么循環(huán)依賴非要搞三層這個話題在熱搜里排得很靠前我單獨拿出來講。Spring 解決單例 Bean 的循環(huán)依賴靠的是三級緩存也就是三個 Map一級緩存singletonObjects存放創(chuàng)建完成、可以正常使用的成品 Bean。二級緩存earlySingletonObjects存放提前暴露的早期 Bean還沒完成屬性填充但對象已經(jīng) new 出來了。三級緩存singletonFactories存放ObjectFactory工廠用于生成早期 Bean 的代理對象。正常流程是這樣的A 依賴 BB 依賴 A。容器先創(chuàng)建 A發(fā)現(xiàn) A 需要 B于是去創(chuàng)建 BB 創(chuàng)建過程中發(fā)現(xiàn)自己需要 A這時 A 還沒創(chuàng)建完但 Spring 會提前把 A 的ObjectFactory放到三級緩存里。B 拿到這個工廠通過它拿到 A 的早期引用完成自己的創(chuàng)建B 創(chuàng)建完后再回來把 A 填滿。你可能會問二級緩存明明已經(jīng)能拿到對象了為什么還要三級緩存關(guān)鍵區(qū)別在于——AOP 代理的時機(jī)。如果 A 需要被代理比如有Transactional或Aspect那 B 依賴的 A 應(yīng)該是代理對象而不是原始對象。三級緩存里存的是ObjectFactory這個工廠知道要不要生成代理等真正有人來取 A 的時候才通過工廠決定返回原生對象還是代理對象。如果只有二級緩存存的就是一個已經(jīng)確定好的普通對象代理就來不及了。我面試的時候經(jīng)常用一句話總結(jié)三級緩存存在的意義是讓 Bean 在未完成初始化時就能被提前引用并且保證引用到的是最終形態(tài)含代理。這是一個很典型的為了正確性犧牲一點簡單性的設(shè)計。2.3 手寫一個迷你 Spring 能給你帶來什么熱搜里有手寫 spring這個詞我非常推薦每個 Java 后端都試一次。不是為了造輪子而是當(dāng)你親手用 HashMap 反射實現(xiàn)一遍掃描類、解析注解、創(chuàng)建對象、注入依賴你會真正理解 Spring 的 IoC 容器就是一個高級一點的 Map 管理工具——只是它加了擴(kuò)展點、生命周期回調(diào)、代理機(jī)制而已。手寫初期建議只做三件事掃描指定包下的所有類找出帶Component注解的類。對每個類用反射找到構(gòu)造器和字段上的依賴遞歸實例化并注入。維護(hù)一個applicationContext的 Map作為一級緩存。做完這三步再去看 Spring 源碼里的BeanFactory、ApplicationContext、BeanPostProcessor你會豁然開朗——原來框架的高明之處不是魔法而是每一步都有清晰的邊界和擴(kuò)展點。3. AOP 與動態(tài)代理ProxyFactory 源碼里藏著的設(shè)計精華3.1 AOP 是怎么把橫切邏輯切進(jìn)去的AOPAspect Oriented Programming面向切面編程解決的是橫切關(guān)注點的問題。什么是橫切日志、事務(wù)、權(quán)限校驗、性能監(jiān)控——這些邏輯不屬于任何單一業(yè)務(wù)模塊卻要插入大量業(yè)務(wù)方法里。如果每個方法里手動寫一遍日志代碼改一個日志格式得全局搜替換維護(hù)成本極高。Spring AOP 的思路是定義切面Aspect通過切點Pointcut匹配哪些方法需要增強(qiáng)通過通知Advice定義增強(qiáng)邏輯前置、后置、環(huán)繞、異常等然后由 Spring 在運行時生成一個代理對象替代原始 Bean 放入容器。業(yè)務(wù)代碼拿到的是代理調(diào)用方法時先走增強(qiáng)邏輯再進(jìn)業(yè)務(wù)方法。3.2 JDK 動態(tài)代理 vs CGLIB到底怎么選Spring AOP 的底層代理有兩種方式JDK 動態(tài)代理基于接口java.lang.reflect.ProxyInvocationHandler。要求目標(biāo)類實現(xiàn)接口生成的是接口的實現(xiàn)類代理。CGLIB 代理基于繼承通過字節(jié)碼生成目標(biāo)類的子類作為代理。不需要接口但要求目標(biāo)類不能被final修飾。Spring Boot 2.x 之后的默認(rèn)策略是如果目標(biāo)類有接口就用 JDK 代理沒有接口用 CGLIB。但 Spring Boot 官方其實更建議強(qiáng)制使用 CGLIBspring.aop.proxy-target-classtrue因為 JDK 代理在類沒有實現(xiàn)接口時會直接失效而且 CGLIB 在性能上通常更穩(wěn)定。這里有個高頻坑Transactional注解為什么有時候不生效一個非常常見的原因是事務(wù)方法被同類內(nèi)部的另一個方法通過this調(diào)用。因為 Spring AOP 基于代理this調(diào)用的是原始對象而不是代理對象事務(wù)邏輯根本沒有進(jìn)入。解決辦法是把需要事務(wù)的方法拆到另一個 Bean 里或者用AopContext.currentProxy()獲取當(dāng)前代理對象再調(diào)用。3.3 從 ProxyFactory 源碼學(xué)到的設(shè)計模式如果你去看org.springframework.aop.framework.ProxyFactory的源碼會發(fā)現(xiàn)它就是一個典型的策略模式 工廠模式——根據(jù)配置決定用 JDK 還是 CGLIB然后把Advisor切點通知的封裝解析成攔截器鏈最后生成代理。值得琢磨的是DefaultAopProxyFactory.createAopProxy()里的判斷邏輯config.isOptimize() || config.isProxyTargetClass() || hasNoUserSuppliedProxyInterfaces。翻譯成大白話就是只要明確要求代理目標(biāo)類或者沒提供任何可代理的接口就直接走 CGLIB。這段邏輯我建議每個面試者都去讀一遍因為它是理解Spring 為什么這么選擇代理方式的最直接入口。從工程角度講ProxyFactory 給我們最大的啟發(fā)是一個復(fù)雜的系統(tǒng)可以被拆成策略的集合。代理的生成方式、攔截器鏈的組裝方式、是否暴露代理對象——全都是可配置的策略點核心框架只負(fù)責(zé)把這些策略串起來。4. Spring Boot把復(fù)雜度留給自己把簡單留給開發(fā)4.1 自動配置是怎么變魔術(shù)的Spring Boot 最偉大的一點在我看來不是它發(fā)明了什么新技術(shù)而是它把 Spring Framework 的配置復(fù)雜度給藏起來了。想當(dāng)年用 Spring MVC 搭一個項目要寫 web.xml、spring-config.xml、配置 ViewResolver、配事務(wù)管理器、配數(shù)據(jù)源——沒一天搞不定。到了 Spring Boot你只要加一個spring-boot-starter-web依賴寫一個帶SpringBootApplication注解的 main 方法世界清凈了。它的核心機(jī)制叫自動配置Auto-Configuration。SpringBootApplication組合了EnableAutoConfiguration后者會通過spring.factoriesSpring Boot 3 之后是AutoConfiguration.imports加載一大批XxxAutoConfiguration類每個類上用ConditionalOnClass、ConditionalOnMissingBean、ConditionalOnProperty等條件注解控制什么時候生效。比如DataSourceAutoConfiguration會在 classpath 里有DataSource類且你沒有自定義DataSourceBean 時才生效。所以自動配置不是魔法它是根據(jù)條件自動填充配置同時給你留好后門。想改配置一個是改application.yml里的spring.*屬性另一個是定義自己的 Bean 覆蓋自動配置的默認(rèn) Bean。4.2 IDEA 社區(qū)版開發(fā) Spring Boot 的姿勢熱搜里有intellij idea 社區(qū)版怎么用 spring boot這個問題我在很多新手群里見過。IDEA 社區(qū)版是免費的但不內(nèi)置 Spring Initializr所以新建 Spring Boot 項目最方便的辦法是去 start.spring.io 網(wǎng)站上把項目壓縮包下載下來然后在 IDEA 里直接File - Open打開。注意幾個細(xì)節(jié)打開項目后IDEA 社區(qū)版需要等 Maven 或 Gradle 把依賴下載完第一次會很久屬正?，F(xiàn)象。沒有 Spring 插件不影響寫代碼只是沒有對application.yml的自動補(bǔ)全和 bean 跳轉(zhuǎn)功能上不影響。運行方式可以直接 main 方法右鍵 Run也可以命令行mvn spring-boot:run。如果要在社區(qū)版里建多模塊項目Maven 的父工程方式完全可以替代 IDE 的向?qū)А?.3 WebSocket 集成一個典型的 yml 配置實戰(zhàn)Spring Boot 集成 WebSocket看起來要寫不少代碼其實核心就三塊配置類、處理器Handler、握手?jǐn)r截器可選。yml 里 Skilliges 的東西不多但不少人卡在這里我放一個我實際項目里驗證過的完整配置片段。先看application.yml里關(guān)于 WebSocket 的部分server: port: 8080 spring: websocket: # Spring Boot 原生不要求額外配置以下僅為示例 # 如果使用嵌入式容器默認(rèn)路徑參數(shù)都不需要改 endpoint: /ws allowed-origins: *說實話原生 Spring Boot 的 WebSocket 的 yml 配置項非常少核心配置基本靠 Java 代碼。很多網(wǎng)上教程寫的 yml 配置其實是第三方庫比如netty或t-io或者 Spring Cloud Gateway 的 WebSocket 路由配置別被誤導(dǎo)了。真正關(guān)鍵的 Java 配置是這樣的Configuration EnableWebSocket public class WebSocketConfig implements WebSocketConfigurer { Override public void registerWebSocketHandlers(WebSocketHandlerRegistry registry) { registry.addHandler(myWebSocketHandler(), /ws) .addInterceptors(new HttpSessionHandshakeInterceptor()) .setAllowedOrigins(*); } }我踩過的坑主要是這類setAllowedOrigins(*)在 Spring 6 / Boot 3 里如果你用的是allowedOriginPatterns而不是setAllowedOrigins通配符一定要用allowedOriginPatterns(*)才行否則跨域請求被攔。這個細(xì)節(jié)如果你不跑一次前端聯(lián)調(diào)根本發(fā)現(xiàn)不了。4.4 監(jiān)控到底怎么做Actuator 到 PrometheusSpring Boot 實現(xiàn)監(jiān)控都有哪些需求和功能也是熱門搜索話題。監(jiān)控的需求其實就五類健康檢查、指標(biāo)采集、日志查看、鏈路追蹤、告警通知。Spring Boot 自帶的spring-boot-starter-actuator解決了前三類的大部分。開啟方式很簡單加依賴然后配置暴露端點management: endpoints: web: exposure: include: health,info,metrics,prometheus endpoint: health: show-details: always/actuator/health會返回應(yīng)用是否存活/actuator/metrics會返回 JVM 內(nèi)存、線程、GC 等基礎(chǔ)指標(biāo)如果你再引入micrometer-registry-prometheus就能把指標(biāo)暴露成 Prometheus 格式配合 Grafana 做可視化面板。我實際項目的經(jīng)驗是監(jiān)控光有指標(biāo)還不夠必須有告警。最省事的方案是 Prometheus Alertmanager對某個指標(biāo)比如 5 分鐘內(nèi)錯誤率超過閾值觸發(fā)告警發(fā)到釘釘/企微。這類需求 90% 的項目都用得上屬于性價比極高的基礎(chǔ)設(shè)施。5. Spring Cloud 與微服務(wù)生態(tài)從單體到分布式的那道坎5.1 微服務(wù)到底解決了什么問題單體應(yīng)用不是洪水猛獸很多項目單體才是最合適的。但當(dāng)你的團(tuán)隊規(guī)模變大、模塊邊界模糊、部署頻率互相拖累就需要拆微服務(wù)。拆完之后會冒出一批新的問題服務(wù)怎么互相發(fā)現(xiàn)配置怎么統(tǒng)一管理流量怎么入口控制故障怎么隔離熔斷怎么做鏈路怎么追蹤Spring Cloud 就是這套分布式問題的解決方案集合。Spring Cloud 的幾個核心組件我按職責(zé)列一下服務(wù)注冊與發(fā)現(xiàn)Nacos / Eureka / Consul服務(wù)啟動時把自己注冊上去調(diào)用方從注冊中心拿地址。配置中心Nacos Config / Spring Cloud Config配置不再放在本地而是統(tǒng)一管理、動態(tài)刷新。網(wǎng)關(guān)Spring Cloud Gateway所有請求的入口做路由、鑒權(quán)、限流。熔斷降級Resilience4j / Sentinel防止一個服務(wù)故障拖垮整個鏈路。鏈路追蹤Micrometer Tracing Zipkin看清一次請求經(jīng)過了哪些服務(wù)、耗時多少。5.2 Spring Cloud Alibaba 的組件選型心得現(xiàn)在國內(nèi)做微服務(wù)基本繞不開 Spring Cloud Alibaba。它的核心組件選型我直接給結(jié)論場景推薦組件替代方案我的理由注冊中心/配置中心NacosConsul, EurekaNacos 同時支持注冊和配置運維成本最低熔斷限流SentinelResilience4j, HystrixSentinel 控制臺可視化規(guī)則動態(tài)下發(fā)做得好分布式事務(wù)Seata本地消息表, OutboxSeata AT 模式對業(yè)務(wù)侵入最小但性能有代價網(wǎng)關(guān)Spring Cloud GatewayZuul, ShenYu官方組件響應(yīng)式生態(tài)兼容最好用 Nacos 的時候有一個我在生產(chǎn)環(huán)境踩過的坑Nacos 的配置刷新是基于RefreshScope的不是所有 Bean 都會自動刷新。比如你改了application.yml里某個自定義配置項如果承載它的 Bean 沒有加RefreshScopeNacos 那邊顯示發(fā)布成功但應(yīng)用里值還是舊的。排查這類問題花了我半天最后是給配置類補(bǔ)了RefreshScope才解決。5.3 Python 應(yīng)用怎么融入 Spring Cloud Alibaba 體系熱搜里有python應(yīng)用融入spring cloud alibaba微服務(wù)體系這個問題很有意思——很多團(tuán)隊是 Java 為主、Python 為輔算法服務(wù)、數(shù)據(jù)處理、爬蟲但 Java 微服務(wù)體系的組件 Python 直接用不了。我的實踐經(jīng)驗是分場景處理服務(wù)注冊發(fā)現(xiàn)Python 服務(wù)用nacos-sdk-python直接注冊到 NacosJava 側(cè)通過 Nacos 拿到 Python 服務(wù)的實例地址用 HTTP 或 gRPC 調(diào)用。這是最輕量的融入方式。配置管理Python 服務(wù)用同樣的 SDK 監(jiān)聽 Nacos 配置實現(xiàn)配置熱更新和 Java 服務(wù)保持一致的配置來源。鏈路追蹤Python 側(cè)用 OpenTelemetry 的 Python SDK把 trace 數(shù)據(jù)推到和 Java 服務(wù)相同的 Collector這樣跨語言的調(diào)用鏈可以串起來。網(wǎng)關(guān)接入Spring Cloud Gateway 本身就可以根據(jù)Path路由到 Python 服務(wù)上Java 服務(wù)看不到對方是什么語言只看到一個 HTTP endpoint。這套方案的收益是你可以保留 Python 在數(shù)據(jù)/AI 領(lǐng)域的優(yōu)勢同時復(fù)用 Nacos 的服務(wù)治理、配置中心、網(wǎng)關(guān)入口而不是在 Python 側(cè)另起一套注冊中心、兩套治理體系互相打架。5.4 一個普遍糾結(jié)的問題給第三方提供的接口放哪Spring Boot 對外提供的接口給第三方應(yīng)該放在哪里是單獨的服務(wù)還是放在對應(yīng)的服務(wù)里——這個問題我在知乎上看到過很多次我的結(jié)論是基于團(tuán)隊規(guī)模和接口穩(wěn)定性來定的接口與內(nèi)部接口耦合度低、且調(diào)用方來自外部建議拆成獨立的對外 API 服務(wù)。理由很簡單外部接口的穩(wěn)定性要求、安全要求、限流策略和內(nèi)部系統(tǒng)完全不同混在一起會導(dǎo)致內(nèi)部發(fā)版時不得不考慮外部兼容性非常痛苦。接口與業(yè)務(wù)強(qiáng)相關(guān)、且團(tuán)隊規(guī)模小可以放在同一個服務(wù)里但必須單獨分模塊、單獨配鑒權(quán)和限流、單獨走一套版本號比如/open/v1/...。千萬別和內(nèi)部接口混在同一 Controller 里沒有隔離。接口涉及多團(tuán)隊數(shù)據(jù)聚合強(qiáng)烈建議做一個聚合層BFF對外只暴露一個統(tǒng)一 API 網(wǎng)關(guān)內(nèi)部服務(wù)的變化不會直接影響外部調(diào)用方。一句話總結(jié)是否拆服務(wù)不取決于是不是第三方而取決于外部變更頻率和業(yè)務(wù)數(shù)據(jù)耦合度。6. Spring AIJava 生態(tài)接入大模型時代的新入口6.1 Spring AI 解決了什么問題2025 年的 Spring 生態(tài)里最讓人興奮的新成員就是 Spring AI。它的目標(biāo)非常明確為 Java 開發(fā)者提供一套統(tǒng)一的 API對接各種大語言模型LLM、向量數(shù)據(jù)庫、Embedding 模型和 Agent 框架。以前你想在 Java 項目里接入 OpenAI、通義千問、文心一言得給每個廠商寫一套 HTTP 調(diào)用代碼Spring AI 把這些抽象成了ChatClient、EmbeddingModel、VectorStore這些統(tǒng)一接口換模型廠商只需要換依賴和配置。它的核心抽象可以總結(jié)成一張表Spring AI 接口對應(yīng)能力常見實現(xiàn)ChatClient對話生成OpenAI, Qwen, DeepSeek 等EmbeddingModel向量化文本OpenAI Embedding, Qwen EmbeddingVectorStore向量數(shù)據(jù)庫存儲與檢索Redis, PGVector, MilvusChatMemory多輪對話記憶MessageWindowChatMemoryToolCalling函數(shù)調(diào)用/工具調(diào)用自定義Tool方法6.2 連接百煉 Qwen一次完整的集成過程熱搜里有spring ai 2.0 連接百煉 qwen3.7。得益于 Spring AI 的抽象接阿里云百煉平臺的大模型流程非常清爽。我以 Spring AI 當(dāng)前版本為例三步就能跑起來。第一步引入依賴以 Maven 為例dependency groupIdorg.springframework.ai/groupId artifactIdspring-ai-starter-model-tongyi/artifactId version1.0.0/version /dependency第二步配置密鑰spring: ai: tongyi: api-key: ${DASHSCOPE_API_KEY} chat: options: model: qwen-plus temperature: 0.7第三步注入ChatClient并調(diào)用Service public class QwenService { private final ChatClient chatClient; public QwenService(ChatClient.Builder builder) { this.chatClient builder.build(); } public String chat(String prompt) { return chatClient.call(prompt); } }從這幾十行代碼能看出來Spring AI 最大的價值是把模型接入變成了換配置的事。你今天用 Qwen明天想換 DeepSeek只需要換依賴、換 api-key、換 model 名業(yè)務(wù)代碼一行不用改。6.3 Spring AI Agent從對話到自主完成任務(wù)的跨越Spring AI 里目前最受關(guān)注的是 Agent智能體能力。Spring AI 實現(xiàn) Agent 的方式不是像 LangChain 那樣引入復(fù)雜的編排框架而是基于它自己的ToolCalling 機(jī)制模型在生成文本的過程中發(fā)現(xiàn)需要外部信息就輸出一個函數(shù)調(diào)用請求Spring AI 的框架負(fù)責(zé)執(zhí)行對應(yīng)的方法把結(jié)果回傳給模型模型再基于結(jié)果繼續(xù)生成。我給你展示一個我實際做過的工具定義——讓 AI 能自己查 MySQL 里的訂單數(shù)據(jù)Service public class OrderTools { private final JdbcTemplate jdbcTemplate; public OrderTools(JdbcTemplate jdbcTemplate) { this.jdbcTemplate jdbcTemplate; } Tool(description 根據(jù)用戶ID查詢最近訂單列表) public ListOrder getOrdersByUserId(ToolParam(description 用戶ID) Long userId) { return jdbcTemplate.query( select * from orders where user_id ? limit 10, new BeanPropertyRowMapper(Order.class), userId ); } }只要把這個OrderTools傳給ChatClient用戶說幫我查一下 ID 為 1001 的用戶最近的訂單模型會自動決定調(diào)用getOrdersByUserId這個方法并拿到真實數(shù)據(jù)組織成自然語言回答。我想強(qiáng)調(diào)一點Spring AI 做 Agent 的體驗對這種熟悉 Java 生態(tài)、不想引入第二套技術(shù)棧的團(tuán)隊尤其友好。你現(xiàn)有的 Spring 服務(wù)就是天然的 Tool 庫一個Tool注解就能把一個已有服務(wù)能力暴露給 LLM。6.4 Dify 工作流與 Spring AI Java 代碼的聯(lián)動熱搜里有dify工作流轉(zhuǎn)成spring ai java代碼github。Dify 是一個很流行的 LLM 應(yīng)用開發(fā)平臺可視化編排工作流。很多團(tuán)隊先在 Dify 里搭好 prompt、知識庫、工具調(diào)用驗證業(yè)務(wù)邏輯沒問題然后面臨一個現(xiàn)實問題生產(chǎn)環(huán)境要落到 Java 代碼里維護(hù)怎么辦。我的理解是Dify 的工作流本身很難一鍵翻譯成 Spring AI 代碼因為 Dify 是平臺級的編排引擎Spring AI 是代碼級的開發(fā)框架兩者抽象層級不同。但你可以做一件事把 Dify 里驗證好的工作流邏輯拆解成節(jié)點每個節(jié)點在 Spring AI 里用一個組件實現(xiàn)。例如 RAG 節(jié)點對應(yīng)VectorStoreEmbeddingModel工具節(jié)點對應(yīng)Tool方法LLM 節(jié)點對應(yīng)ChatClient。這種先在低代碼平臺驗證、再在代碼框架固化的做法是我目前見到最務(wù)實的落地路徑。6.5 A2A Spring 是什么a2a spring這個熱詞我猜是 Agent-to-AgentA2A相關(guān)的新東西可能是阿里在 AI 智能體通信協(xié)議上的某個 Spring 實現(xiàn)思路。這個方向目前還比較早期我沒有太多一手經(jīng)驗可以分享建議保持關(guān)注就行——它大概率會像當(dāng)年的 Spring Cloud 一樣把智能體之間的互相對話和任務(wù)協(xié)作做成一整套標(biāo)準(zhǔn)化組件。核心思路一定會圍繞協(xié)議標(biāo)準(zhǔn)化、任務(wù)路由、安全認(rèn)證幾個維度展開等生態(tài)成熟了我再單獨寫一篇。7. 學(xué)習(xí)路線與面試高頻考點給新人的一張實用地圖7.1 我推薦的學(xué)習(xí)順序很多人學(xué) Spring 喜歡一上來就看源碼被AbstractApplicationContext.refresh()那一大坨直接勸退。我比較推薦下面這個順序每一步都配一個實操目標(biāo)先學(xué)會用一個 Spring Boot 項目建工程、寫 Controller、連接數(shù)據(jù)庫、寫一個增刪改查接口。目標(biāo)是建立框架幫我干活的感覺。再理解 Spring 核心機(jī)制看 IoC 容器、Bean 生命周期、AOP 的用法。目標(biāo)是理解 Bean 是怎么被管理的、AOP 是怎么生效的。然后動手讀關(guān)鍵源碼讀BeanFactory、DefaultSingletonBeanRegistry的三級緩存實現(xiàn)、ProxyFactory。目標(biāo)是從會用到知道為什么。自己手寫一個迷你版 Spring不需要完整實現(xiàn)只要把掃描 實例化 注入跑通就算成功。這一步對理解 IoC 的提升非常大。最后擴(kuò)展到生態(tài)Spring Boot 自動配置 → Spring MVC 工作原理 → Spring Cloud 組件 → Spring AI。每一步都基于前一步的地基。7.2 面試中那些高級題到底在考什么結(jié)合熱搜里的spring面試題spring高級面試題我挑幾個高頻題目說說過關(guān)思路Spring 是如何解決循環(huán)依賴的別只背三級緩存。要講清楚每個緩存的作用、為什么需要三級、代理對象怎么處理、以及構(gòu)造器注入為什么無法解決循環(huán)依賴。Spring Bean 的生命周期從BeanDefinition解析開始到實例化、屬性填充、BeanNameAware、BeanPostProcessor前置處理、InitializingBean、init-method、BeanPostProcessor后置處理、使用、銷毀。每一步能說清觸發(fā)條件和實際場景。Transactional為什么失效常見原因方法非 public、同類this調(diào)用、異常被 catch 吞掉、數(shù)據(jù)庫引擎不支持事務(wù)、傳播行為設(shè)置不對。這個題考察的是對代理機(jī)制的理解。Spring Boot 的自動配置是怎么實現(xiàn)的講到ConditionalOnClass等條件注解、AutoConfiguration.imports、EnableAutoConfiguration就足夠。Spring Cloud 和 Dubbo 的區(qū)別重點說清楚Spring Cloud 是全家桶、基于 HTTP/REST、適合異構(gòu)系統(tǒng)Dubbo 是 RPC 框架、基于 TCP、性能更高、適合 Java 對內(nèi)服務(wù)。7.3 關(guān)于 Spring Framework 版本下載的小提示熱搜里還有spring framework 5.3.41 下載。Spring Framework 的源碼和 jar 包都在 GitHub Releases 和 Maven Central 上不用單獨去官網(wǎng)找。如果你想看源碼最方便的方式是去 GitHub 上下載對應(yīng) tag 的源碼壓縮包然后用 IDEA 打開如果你只是想在自己的項目里用某個版本直接改 Maven 依賴版本就可以。5.3.x 是目前仍然被廣泛使用的一個穩(wěn)定分支它是最后一個還默認(rèn)支持 JDK 8 的官方維護(hù)分支很多老項目升級到 Boot 2.7 時還會用到它。不過新項目我建議直接走 Spring Boot 3.x 配 JDK 17生態(tài)和安全性都更省心。7.4 一個真實項目的經(jīng)驗從框架使用者到理解者我早期在項目里用 Spring Boot說實話就是照著模板寫代碼對原理的理解停留在面試題層面。真正讓我產(chǎn)生質(zhì)變的是一次線上事故排查——某天系統(tǒng)響應(yīng)突然變慢所有接口都卡查日志發(fā)現(xiàn)是一個Scheduled定時任務(wù)里調(diào)用了外部接口那個接口超時長達(dá) 60 秒而定時任務(wù)默認(rèn)單線程把整個線程池卡死了。那天我翻源碼找到了Scheduled默認(rèn)的ThreadPoolTaskScheduler線程數(shù)只有 1才真正意識到框架替你做的選擇不一定是適合你業(yè)務(wù)的理解框架能讓你改得動它。這種先踩坑再翻源碼的經(jīng)歷比任何教程都讓人成長得快。所以我一直建議后端開發(fā)者遇到奇怪問題不要急著搜博客先打開 Spring 源碼跟著調(diào)用棧看一遍很多疑問會在代碼里自然解開。Spring 這片生態(tài)入門容易精通難但它最吸引人的地方在于——每一個設(shè)計決策背后都有真實的工程問題。把這些問題想透了你看到的不再是一堆注解和配置而是一套應(yīng)對企業(yè)級復(fù)雜度的方法論。希望這篇寫得足夠接地氣能幫你在 Spring 這條路上走得更順一點。