先講個我前兩天真實遇到的事。團隊里來了個新人我讓他接一個模塊改動他很快把代碼擼完了類上貼了一堆Service、Autowired。我隨口問他“你這段依賴是Spring怎么給你送進去的如果我有兩個實現(xiàn)你想注入哪一個A依賴BB又依賴ASpring為什么還能正常啟動”他愣了一下說“框架不是都處理好了嗎”。這就是典型的Spring IoCDI只停留在“會用”層面的表現(xiàn)。說實話面試也好做Java EE企業(yè)級應用也好Spring IoC和DI都是躲不掉的硬骨頭。它不像某個工具類記住了API就能用它是一整套設計思想決定了你的項目結構、代碼耦合度、測試方式甚至是排查問題時的思路方向。這篇文章我打算結合自己多年的項目實踐把 IocDI 的核心概念、實戰(zhàn)用法、底層原理和各類面試考點揉碎了講一遍盡量用大白話和能直接上手的示例讓看完的你能從“會用注解”升級到“真懂容器”。1. 先把IoCDI的概念掰開揉碎很多人在IoC上栽跟頭不是智商不夠而是教科書寫得太繞。什么“反轉控制”“讓容器管理對象”聽著跟玄學似的。我用最直白的方式給你講清楚。1.1 控制反轉到底反了什么在沒有Spring的年代我們寫Java Web大多是下面這種玩法public class OrderService { private OrderDao orderDao new OrderDaoImpl(); public void createOrder(Order order) { orderDao.insert(order); } }看起來沒啥問題但OrderService和OrderDaoImpl死死綁在一起。今天你想換一個OrderDao的Redis緩存實現(xiàn)得改OrderService的代碼明天你想給OrderService寫單元測試還得跟著new一個真實Dao出來Dao又依賴數(shù)據源測試成本直接翻倍。控制反轉干的事就是把這段代碼里的“new”權力收走。對象不是由使用方自己創(chuàng)建而是交給一個容器統(tǒng)一創(chuàng)建和裝配使用方只需要聲明“我需要一個OrderDao”容器就把合適的實例送過來。主動權從調用者手里反轉給了容器這就是“控制反轉”。我用生活里的事打個比方。以前你招待朋友從買菜、洗菜、炒菜、端盤全是你自己干這是傳統(tǒng)開發(fā)?，F(xiàn)在你打電話給餐廳訂餐只說“我要一個宮保雞丁”后廚怎么選食材、怎么調味、用什么盤子端上來你完全不關心這是IoC。餐廳就是Spring容器菜單就是你的依賴聲明。1.2 依賴注入的三種姿勢依賴注入是IoC落地的手段沒有DIIoC就是空中樓閣。Spring里常用的注入方式有三種構造器注入Service public class OrderService { private final OrderDao orderDao; public OrderService(OrderDao orderDao) { this.orderDao orderDao; } }我個人非常推薦這種方式。好處是依賴在對象創(chuàng)建那一刻就固定下來字段能用final修飾整個對象要么完整創(chuàng)建成功要么創(chuàng)建失敗不存在“注入一半”的中間狀態(tài)。測試的時候直接new一個真實或Mock的OrderDao傳進去就行不用借助Spring容器。Setter注入Service public class OrderService { private OrderDao orderDao; Autowired public void setOrderDao(OrderDao orderDao) { this.orderDao orderDao; } }這種方式適合可選依賴或者依賴需要運行時替換的場景。缺點是你無法確保對象在使用前一定被賦值如果忘了調用setter運行時容易空指針。字段注入Service public class OrderService { Autowired private OrderDao orderDao; }寫起來最省事我見過大量項目整片整片都是這種寫法。但它是把雙刃劍依賴關系被隱藏了你看到的只有字段單元測試時不能只new一個對象完成注入必須配合Spring Test或者反射工具非常麻煩。而且字段被private包住IDE檢查不友好容易出現(xiàn)“類能跑起來但依賴混亂”的壞味道。1.3 為什么Spring要這么設計理解IoC的意義不能只看“不需要new”這種表面好處。真正的原因有三個。第一是解耦。上層依賴抽象接口不依賴具體實現(xiàn)。接口不變底層實現(xiàn)隨便換這就是后面Spring能衍生出AOP、事務管理、緩存抽象這些東西的地基。你想想一個多商戶商城項目訂單、支付、庫存、物流、用戶各個模塊互相牽扯如果沒有IoC做解耦整個系統(tǒng)改一處牽一發(fā)動全身。第二是可測試性。依賴由外部注入測試時往構造器里塞一個Mock對象不需要啟動數(shù)據庫、不需要走網絡單測速度飛快。我接手老項目時最痛苦的就是大量類內部new出了各種依賴連個最簡單的邏輯都沒法單測。第三是生命周期管理。容器統(tǒng)一負責創(chuàng)建對象、做初始化、掛代理、執(zhí)行銷毀單例池、線程安全、事務攔截全部可以在對象創(chuàng)建過程中無縫織入。沒有IoC容器這些橫切邏輯根本無處安放。2. 從零到一IoCDI的實戰(zhàn)用法概念講再多不落地都是空談。這一節(jié)我?guī)阕咭槐檎鎸嶍椖坷锏难b配方式從最基礎的注解掃描到Java Config再到外部化配置環(huán)環(huán)相扣。2.1 工程準備與第一行裝配代碼實踐時我通常用Spring Boot搭骨架因為Boot的自動配置把最繁瑣的那部分容器配置藏了起來你只需要聚焦業(yè)務。用IDEA新建一個Spring Boot項目引入Web依賴dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency然后寫一個最簡單的接口和實現(xiàn)public interface UserDao { String findUserNameById(Long id); } Repository public class UserDaoImpl implements UserDao { Override public String findUserNameById(Long id) { return 用戶 id; } } Service public class UserService { private final UserDao userDao; public UserService(UserDao userDao) { this.userDao userDao; } public String getUserName(Long id) { return userDao.findUserNameById(id); } } RestController public class UserController { private final UserService userService; public UserController(UserService userService) { this.userService userService; } GetMapping(/user/{id}) public String getUser(PathVariable Long id) { return userService.getUserName(id); } }啟動應用訪問/user/1你能看到容器把UserDaoImpl裝配進UserService再把UserService裝配進Controller。注意Controller里的構造器不是自己手動調的是Spring在啟動階段掃描到RestController發(fā)現(xiàn)構造器需要UserService就從容器里找到UserService的實例傳進去。順嘴提一個新手典型的坑IDEA創(chuàng)建Spring Boot項目失敗或啟動類找不到八成是JDK版本和Maven配置不匹配。建議JDK 8對應Spring Boot 2.xJDK 17對應Spring Boot 3.xMaven鏡像源換成國內源啟動速度會穩(wěn)定很多。2.2 注解裝配最常見也最容易用錯Spring的IoC注解體系分兩塊注冊Bean的注解和注入依賴的注解。注冊Bean的注解有Component、Service、Repository、Controller。它們在功能上沒有任何區(qū)別Spring掃描到它們都會把對應類注冊為Bean。把它們分成四個名字純粹是為了語義化Service告訴閱讀者這是業(yè)務層Repository是數(shù)據層Controller是Web層。你去翻Spring源碼會發(fā)現(xiàn)這四個注解本身都標注了Component。注入依賴的注解則是Autowired和Resource的重災區(qū)很多人分不清。Autowired是Spring自己的注解默認按類型注入。如果同類型有多個Bean就結合Qualifier指定名字。Service public class OrderService { private final PaymentService paymentService; public OrderService(Qualifier(wechatPayService) PaymentService paymentService) { this.paymentService paymentService; } }Resource是Java EE時代留下的標準注解默認按名稱注入名稱找不到再按類型。如果你的項目從Java EE遷移到Spring或者有跨框架的訴求可以考慮它。但從純Spring項目角度我一般建議統(tǒng)用Autowired語義更貼合Spring體系。再來看Value它用于注入外部配置Service public class AliPayService implements PaymentService { Value(${pay.alipay.app-id}) private String appId; }這里的${pay.alipay.app-id}會在容器啟動時從application.properties或application.yml里讀取。配置文件里寫pay.alipay.app-idwx123456這個Bean的屬性就會被自動賦值。順便說一句很多初學者改端口號都去代碼里找其實只要在配置里加server.port8081重啟即可。2.3 Java Config把選擇權握在自己手里注解注入雖然方便但也有力所不及的時候。比如引入第三方Jar包里的類你沒法給它加Component。這時就需要Java Config登場。Configuration public class OssConfig { Bean public OssClient ossClient() { return new OssClient(endpoint, accessKey, secretKey); } }Configuration標記這是一個配置類Bean標注的方法會返回一個對象Spring會把方法返回值注冊為容器中的Bean方法名就是Bean的名字也可以通過Bean(name)指定。后面任何地方需要OssClient直接注入即可。相比早期Spring的XML配置Java Config最大的優(yōu)勢是編譯期檢查。XML里的class屬性寫錯只有啟動時才報錯Java Config里方法返回類型、參數(shù)類型都是強類型的寫錯了IDE立刻標紅?？芍貥嬓砸矎婎惛拿鸄ltEnter一按全局跟著變XML里你還得手動改字符串。我維護遺留項目時最怕看到動輒幾百行的XML配置。建議的落地策略是業(yè)務自己的類用注解自動掃描第三方依賴和需要定制構造參數(shù)的類用Java Config。兩者可以混用以ComponentScan的掃描路徑為界。2.4 復雜場景下的裝配策略真實項目不會像教程那么清爽我挑幾個高頻復雜場景說說。同類型多Bean怎么選。一個系統(tǒng)不只一個支付渠道微信、支付寶、銀聯(lián)都實現(xiàn)PaymentService。這時候容器里有三個Bean直接Autowired會報NoUniqueBeanDefinitionException。正確的做法是給每個實現(xiàn)加明確的Bean名字注入處用Qualifier指定。還可以用Primary標出默認實現(xiàn)這樣不想指定名字的注入點也能拿到主實現(xiàn)。用Import組織配置。當配置類多起來可以在一個入口配置上通過Import引入其他配置類讓容器啟動時的掃描入口保持整潔Configuration Import({OssConfig.class, DataSourceConfig.class}) public class AppConfig { }配置類里帶條件裝配。Spring Boot的自動配置大量用了條件裝配比如ConditionalOnMissingBean表示“容器里沒有這個Bean時才創(chuàng)建”。理解了這個你就明白為什么Boot能那么智能地按需裝配各種組件。自己寫通用模塊時這套條件注解是控制裝配時機的利器。3. 進階必懂Bean生命周期與三級緩存如果說注解用法是IoC的外功那Bean生命周期和三級緩存就是內功。面試能不能鎮(zhèn)住場子基本看這一塊的深度。先聲明一下Spring Boot 2.6之后默認關閉了循環(huán)依賴支持但源碼里三級緩存機制依然存在下面講的原理依然有效。3.1 Bean的一生從定義到銷毀一個Bean從被容器感知到最終銷毀大概走下面這些關卡解析Bean定義。Spring把帶有注解的類或Bean方法解析成BeanDefinition里面記錄了類的全限定名、作用域、初始化方法、屬性值等。實例化前處理。InstantiationAwareBeanPostProcessor.postProcessBeforeInstantiation有機會在Bean真正創(chuàng)建前做手腳。AOP的Configuration類代理就與這個階段有關。實例化。Spring通過反射調用構造器創(chuàng)建原始對象。此時對象還是一張白紙。屬性填充。如果這個Bean依賴了其他BeanSpring會在這里完成依賴注入。構造器注入發(fā)生在實例化階段字段和Setter注入發(fā)生在屬性填充階段。這個順序差異正是后面循環(huán)依賴問題的根源。初始化前處理。BeanPostProcessor.postProcessBeforeInitialization執(zhí)行比如PostConstruct標注的方法在這個階段被調用。初始化。實現(xiàn)InitializingBean接口則調用afterPropertiesSet或者在XML/Java Config里指定initMethod。初始化后處理。BeanPostProcessor.postProcessAfterInitialization執(zhí)行。Spring AOP的代理對象很多是在這個階段生成的這也是三級緩存機制能兜住AOP場景的關鍵。使用。Bean進入單例池供整個容器使用。銷毀。容器關閉時執(zhí)行PreDestroy標注方法或調用DisposableBean.destroy方法。每次看這個清單我都要感嘆Spring往一個對象的創(chuàng)建過程里塞進了太多擴展點。只要掌握了BeanPostProcessor你幾乎能在Bean創(chuàng)建的任何環(huán)節(jié)插入邏輯MyBatis的Mapper代理、Feign的動態(tài)代理、事務的增強實現(xiàn)全是這么織入的。3.2 循環(huán)依賴與Spring三級緩存循環(huán)依賴是面試里繞不開的深水區(qū)。什么是循環(huán)依賴就是A的創(chuàng)建需要BB的創(chuàng)建又需要A。如果Spring不做任何處理A等B、B等A程序直接卡死。Spring用三張Map解決了這個問題一級緩存singletonObjects存放創(chuàng)建完成的完整單例Bean二級緩存earlySingletonObjects存放已經實例化但還沒完成屬性填充的早期Bean三級緩存singletonFactories存放ObjectFactory用來生成Bean的早期引用我畫個場景推演A先開始創(chuàng)建實例化得到原始A對象。Spring把A的ObjectFactory放進三級緩存然后開始給A填充屬性發(fā)現(xiàn)A需要B。容器繼續(xù)創(chuàng)建B實例化得到原始B對象把B的工廠放進三級緩存接著給B填充屬性發(fā)現(xiàn)B需要A。這時B去拿A一級緩存沒有二級緩存也沒有但在三級緩存里找到了A的工廠。工廠執(zhí)行后返回一個A的引用這個引用被放入二級緩存B拿到A的引用完成自身創(chuàng)建并把自己放入一級緩存。A繼續(xù)走B已經完整創(chuàng)建了A拿到B的引用完成自己的屬性填充、初始化和代理增強最終放入一級緩存。這里就能看出問題A在屬性填充階段拿到的其實是自己的“提前暴露”版本不是最終完成代理增強后的對象。而A后面的整個初始化流程是在給自己補全最終一級緩存里存的后創(chuàng)建完成的A才是全量版本。這里面的引用關系Spring通過代理對象的提前引用做了處理細節(jié)比較多但核心思路就是你給我一個半成品先用著等我補全了你再補充后續(xù)的初始化。為什么一定要三級緩存而不是二級。這是高頻追問。二級緩存也能解決字段循環(huán)依賴但沒有三級緩存Spring無法優(yōu)雅處理AOP代理?？紤]A需要在創(chuàng)建完成后被代理如果B拿到的A是原始A對象那A后續(xù)創(chuàng)建的代理對象就和B持有的引用不一致業(yè)務邏輯就錯亂了。三級緩存里存的是ObjectFactory它能在GetObject時延遲判斷A需不需要代理如果不需要就返回原始引用如果需要就生成代理對象還能保證同一Bean只代理一次。正是這個“延遲決策”能力讓Spring既保住循環(huán)依賴又保住AOP的正確性。哪些循環(huán)依賴救不了。一個是構造器注入的循環(huán)依賴因為構造器注入發(fā)生在實例化階段A還沒進三級緩存呢B創(chuàng)建時根本找不到A的半成品。另一個是prototype作用域的循環(huán)依賴原型Bean每次獲取都是新實例Spring不緩存它們自然無從提前暴露。還有Async這類導致代理提前生成的場景處理起來更容易翻車最好的辦法是從設計上消除循環(huán)依賴。我自己寫代碼的原則是字段循環(huán)依賴能用三級緩存兜底但絕不意味著你可以理直氣壯地在項目里寫出A依賴B、B又依賴A的爛代碼。依賴關系應當是清晰向下的環(huán)狀依賴本身就是設計的壞味道。3.3 作用域與后置處理器擴展Bean的作用域決定了容器的管理粒度。默認是單例singleton整個容器只有一份省內存適合無狀態(tài)的Service、DAO等。prototype每次獲取都新建適合有狀態(tài)的任務類。Web環(huán)境下還有request、session、application三種作用域分別對應一次請求、一個會話、整個應用上下文。作用域使用最經典的坑是在單例Bean里注入原型Bean。單例Bean在容器啟動時就創(chuàng)建一次注入的原型Bean也只有一份后續(xù)獲取的永遠是同一個和預期完全不符。解決辦法是Scope配合ProxyMode或者用ObjectProvider延遲獲取。Component public class SingletonBean { Autowired private ObjectProviderPrototypeBean prototypeBeanProvider; public PrototypeBean getPrototypeBean() { return prototypeBeanProvider.getIfAvailable(); } }ObjectProvider的好處是你不直接注入原型Bean實例而是注入一個“獲取器”每次調用就觸發(fā)一次容器的Bean查找從而拿到全新的原型實例。這個技巧在日常開發(fā)里能救很多次命。再聊聊BeanPostProcessor這是Spring的天花板擴展點。它能在Bean初始化的前后插入自定義邏輯。很多框架集成都靠它MyBatis的MapperScannerConfigurer掃描Mapper接口并生成動態(tài)代理注冊成BeanSpring Security的MethodSecurityInterceptor通過后置處理器給Bean掛上安全切面。Component public class MyBeanPostProcessor implements BeanPostProcessor { Override public Object postProcessAfterInitialization(Object bean, String beanName) throws BeansException { if (bean instanceof MyService) { System.out.println(MyService 初始化完成); } return bean; } }理解了這個機制你就明白Spring為什么叫“生態(tài)”而不是“框架”。所有能力都建立在IoC容器之上通過擴展點無限延展。4. 面試考點拆解從背誦到碾壓這部分獻給準備面試的朋友。面試官問IoC很少只問定義他更愛連環(huán)追問。我把高頻問題整理成了鏈式問答方便你順著思路組織答案。4.1 高頻連環(huán)問題與回答思路問說一下你對Spring IoC的理解。常規(guī)回答“IoC就是控制反轉把對象的創(chuàng)建和依賴交給容器管理。”這種回答及格但不出彩。我建議的回答是先提本質——對象創(chuàng)建權從調用者手中轉移給容器DI是其實現(xiàn)手段再舉業(yè)務場景——Service不依賴DaoImpl的具體類型只依賴抽象接口容器按聲明注入最后補一句設計意義——解耦、可測試、統(tǒng)一生命周期管理。這樣既體現(xiàn)理解又體現(xiàn)實戰(zhàn)。問IoC和DI是一回事嗎不是。IoC是設計思想DI是實現(xiàn)思想的方式之一。Spring用DI這套機制實現(xiàn)了IoC的效果。打個比方IoC是“客人不自己做飯”DI是“客人通過菜單告訴服務員自己想吃什么后廚做好端上來”。不用DI也能實現(xiàn)IoC比如用Service Locator模式但Spring選擇了DI。問Spring里的Bean默認是單例的為什么這么設計因為大部分Service、Dao這類對象是無狀態(tài)的它們內部沒有可變字段同一時間可以被多個線程并發(fā)復用單例能極大減少對象創(chuàng)建的開銷。Spring容器作為企業(yè)級應用的基礎設施啟動時就要掃描、解析、注入大量Bean要是每個Bean每次獲取都新建一個性能和內存都撐不住。同時Spring通過ThreadLocal、方法參數(shù)等機制保證無狀態(tài)Bean的并發(fā)安全。問Autowired和Resource有什么區(qū)別我會從幾個維度回答Autowired是Spring的注解Resource是Java EE的標準注解Autowired優(yōu)先按類型裝配多個同類型時靠Qualifier按名字補充Resource優(yōu)先按名字裝配名字找不到再按類型Autowired默認要求依賴必須存在可以通過requiredfalse放寬Resource沒有這個屬性。最后補一句項目建議建議Spring項目統(tǒng)一用Autowired跨框架則考慮Resource。問Spring如何解決循環(huán)依賴把三級緩存的流程講清楚重點回答“為什么是三級不是二級”參考第3.2節(jié)。加分項是主動說出哪些情況下循環(huán)依賴解決不了構造器注入、原型作用域、以及新版本Spring Boot默認禁止循環(huán)依賴的事實。再補一句個人實踐經驗靠緩存兜底不如靠設計消滅循環(huán)依賴。問容器啟動時IoC和AOP的執(zhí)行順序是什么這是區(qū)分“背過答案”和“真正理解”的經典題。Spring容器啟動時先解析Bean定義創(chuàng)建Bean屬性填充并完成初始化然后BeanPostProcessor在初始化后階段生成AOP代理。換言之IoC負責把Bean創(chuàng)建好AOP在Bean準備就緒后對方法做增強兩者通過后置處理器銜接。事務管理、MyBatis的Mapper代理都是這么織進去的。4.2 手寫一個迷你IoC容器編程面試現(xiàn)在越來越喜歡讓候選人手寫一個微型IoC。你不需要真把Spring寫一遍但核心骨架要能自洽。我的實現(xiàn)思路分四步第一步掃描包下的所有類篩出帶Component的類第二步用反射實例化存入一個Mapkey是Bean名字value是實例第三步遍歷所有Bean解析字段上的Autowired從Map里找依賴并遞歸注入第四步提供getBean方法暴露對象。下面是我壓縮后的核心代碼Component public class OrderService { // 模擬需要注入的依賴 } public class MiniApplicationContext { private final MapString, Object singletonObjects new ConcurrentHashMap(); public void scan(String basePackage) throws Exception { String path basePackage.replace(., /); EnumerationURL urls Thread.currentThread().getContextClassLoader() .getResources(path); while (urls.hasMoreElements()) { URL url urls.nextElement(); File dir new File(url.toURI()); for (File file : dir.listFiles(f - f.getName().endsWith(.class))) { String className basePackage . file.getName().replace(.class, ); Class? clazz Class.forName(className); if (clazz.isAnnotationPresent(Component.class)) { String beanName clazz.getSimpleName(); Object instance clazz.getDeclaredConstructor().newInstance(); singletonObjects.put(beanName, instance); } } } injectDependencies(); } private void injectDependencies() throws IllegalAccessException { for (Object bean : singletonObjects.values()) { for (Field field : bean.getClass().getDeclaredFields()) { if (field.isAnnotationPresent(Autowired.class)) { field.setAccessible(true); Object dependency singletonObjects.get(field.getType().getSimpleName()); field.set(bean, dependency); } } } } public T T getBean(ClassT clazz) { return (T) singletonObjects.get(clazz.getSimpleName()); } }這段代碼沒有處理循環(huán)依賴也沒有AOP但已經具備IoC容器的三要素統(tǒng)一創(chuàng)建、集中存儲、按需注入。面試時能寫出這個骨架再補一句“完整的Spring容器在此基礎上增加了BeanDefinition解析、多級緩存、后置處理器和復雜依賴注入”會顯得特別扎實。4.3 面試回答的避雷與加分第一個雷背定義而不懂設計。答IoC時只拋出“控制反轉”四個字面試官一聽就知道你不理解為什么。第二個雷把Autowired和Resource混為一談。我建議你不僅要知道區(qū)別最好能說出Resource屬于javax.annotation和jakarta.annotation的時代變遷這能體現(xiàn)你的Java EE背景寬度。第三個雷說Spring三級緩存是為了解決性能問題。三級緩存和性能沒有直接關聯(lián)它的本質是解決創(chuàng)建期依賴查詢和AOP代理延遲生成問題。答錯方向前面的印象分全丟。加分方式主動指出Spring Boot 2.6后默認禁止循環(huán)依賴。這傳遞一個信號你不光看了Spring的舊機制還關注了最新版本的行為變化。接著補一句“我在項目里用構造器注入消除循環(huán)依賴”面試官基本點頭。5. 實務中的坑與排查經驗這部分是純經驗分享。IoC用得好項目清爽用得糙排查問題能讓你懷疑人生。5.1 常見問題速查表現(xiàn)象原因解決辦法注入的Bean為null類沒被Spring掃描到檢查ComponentScan的包路徑確保類所在包被覆蓋NoSuchBeanDefinitionException容器里根本沒有對應類型檢查類是否加了注冊注解或Bean方法是否執(zhí)行NoUniqueBeanDefinitionException同類型存在多個Bean用Qualifier指定名稱或Primary設置主實現(xiàn)UnsatisfiedDependencyException構造器需要某個依賴但找不到查看異常鏈路中具體缺哪個Bean補配置或補注解循環(huán)依賴啟動失敗構造器注入導致死鎖改成Setter/字段注入或重新梳理依賴關系單例Bean里的原型Bean不生效注入的是固定實例用ObjectProvider或Scope(proxyMode ScopedProxyMode.TARGET_CLASS)5.2 排查思路與實用工具遇到IoC相關的詭異問題我有個固定的排查順序。第一步看啟動日志。把日志級別調到DEBUGlogging: level: org.springframework.beans.factory: DEBUG org.springframework.context: DEBUG啟動時會打印“Creating shared instance of singleton bean xxx”“Autowired annotation processor”等詳細信息能看到每個Bean是在哪個階段出的問題。這個辦法解決了我至少一半的定位難題。第二步使用IDEA的Spring輔助窗口。IDE左側會出現(xiàn)Spring標簽頁里面能看到啟動時掃描到的所有Bean、它們之間的依賴關系圖。Bean被注入了沒有、注入的是哪個實現(xiàn)一目了然。我經常在排查NoUniqueBeanDefinitionException時直接把Bean選中右鍵轉到聲明處效率極高。第三步看堆棧往里鉆三層。很多依賴注入的異常信息很繞比如BeanCreationException包了好幾層核心錯誤在后面。你看到Caused by那一行才是真正的根因別在前面打轉。5.3 寫了這么多年Spring我的幾條心得第一能用構造器注入就不要用字段注入。我前幾年帶的項目里老代碼全是字段注入結果Bean和Bean之間的依賴關系像蜘蛛網一樣理不清。后來強制推行構造器注入每個類的依賴清單一目了然代碼評審時掃一眼構造器就能看出這個類干了多少事。第二被Spring的“便利”迷惑不等于正確。自動掃描、自動裝配省事了但也把依賴關系隱藏在暗處。我見過一個團隊在Service里注入了幾十個字段整個類臃腫得像上帝對象。IoC只是負責給你送東西不負責約束你該要多少。該按職責拆分時還是要拆分。第三循環(huán)依賴是設計警鐘而非功能開關。三級緩存的存在讓Spring看起來無所不能但你的架構里如果頻繁出現(xiàn)環(huán)狀依賴第一步該想的不是怎么配置讓它跑通而是這里的依賴設計是不是出了問題。把公共邏輯抽出去讓依賴方向變清晰比任何配置技巧都值錢。第四善用ObjectProvider解決可選依賴。當你需要某個Bean但它可能在容器里不存在時直接Autowired(required false)是一種解法但每次判空麻煩。用ObjectProvider優(yōu)雅得多既能判斷是否存在又能延遲獲取配合默認值實現(xiàn)代碼干凈不少。寫在最后講完這一圈我對Spring IoCDI的印象可以用一句話總結它不是讓你偷懶不用new而是逼你把代碼結構想清楚。很多人在IoC上栽跟頭其實不是學不會而是沒搞懂它解決的到底是哪一類工程問題。如果你能把文章里那個迷你容器親手寫一遍把三級緩存那張緩存表在紙上推演一遍再回去看看自己項目里的Service和Dao是怎么糾纏在一起的你會突然發(fā)現(xiàn)眼前那些注解都變成了看得見摸得著的機制。這也是我寫這篇文章的初衷Spring再花哨底層還是那些樸素的道理。把這層窗戶紙捅破后面學AOP、學事務傳播、學Spring Boot自動配置都會順暢很多。