1. 為什么你需要一個(gè)SpringUtil先說(shuō)個(gè)我經(jīng)常遇到的場(chǎng)景。代碼里封裝了一個(gè)工具類比如Excel導(dǎo)出、脫敏處理、異步日志上報(bào)這些類往往沒有被Spring托管方法都是靜態(tài)的。某天產(chǎn)品要求在這個(gè)工具類里調(diào)用某個(gè)Mapper或者Service查數(shù)據(jù)你第一反應(yīng)是Autowired塞進(jìn)去結(jié)果發(fā)現(xiàn)工具類不是Spring Bean注入操作直接被無(wú)視字段為null運(yùn)行時(shí)報(bào)空指針。我早期踩過(guò)這個(gè)坑后來(lái)老老實(shí)實(shí)寫了SpringUtil把Spring容器上下文存到一個(gè)靜態(tài)字段里以后無(wú)論哪個(gè)類無(wú)論是不是Bean只要想拿容器里的對(duì)象一行代碼搞定。本質(zhì)上SpringUtil做的是“從容器外訪問(wèn)容器內(nèi)對(duì)象”的橋接底層依賴ApplicationContextAware接口或靜態(tài)注入ApplicationContext核心就一個(gè)方法getBean(ClassT clazz)。這套寫法在中小型項(xiàng)目里極其常見尤其適合以下人群寫通用組件的開發(fā)、做框架封裝的老手、以及剛接觸Spring不久但需要處理“非Bean類里拿Bean”問(wèn)題的初學(xué)者。你只要理解了Spring容器的基本概念就能直接抄作業(yè)。順帶解釋一下熱詞里反復(fù)出現(xiàn)的“Spring容器”“對(duì)象”這幾個(gè)概念的對(duì)應(yīng)關(guān)系。Spring容器本質(zhì)上是一個(gè)Map結(jié)構(gòu)beanName對(duì)應(yīng)bean實(shí)例容器啟動(dòng)時(shí)根據(jù)配置或注解完成對(duì)象的創(chuàng)建和依賴注入。SpringUtil干的事就是拿到這個(gè)Map的管理入口也就是ApplicationContext的引用從而在任意位置按名或按類型取出對(duì)象。理解了這個(gè)底層邏輯之后再看到各種封裝變體都能一眼看穿。2. 核心實(shí)現(xiàn)從ApplicationContextAware到靜態(tài)緩存2.1 經(jīng)典寫法實(shí)現(xiàn)ApplicationContextAware接口最主流、文檔里最常見的方式是讓工具類實(shí)現(xiàn)ApplicationContextAware接口。Spring在容器啟動(dòng)時(shí)會(huì)把ApplicationContext本身作為參數(shù)回調(diào)到setApplicationContext方法里你只需要把它存到靜態(tài)變量中就完成了整個(gè)橋接。下面是我項(xiàng)目中一直在用的完整代碼注釋也寫得比較詳細(xì)可以直接復(fù)制修改。package com.example.common.util; import org.springframework.beans.BeansException; import org.springframework.context.ApplicationContext; import org.springframework.context.ApplicationContextAware; import org.springframework.stereotype.Component; Component public class SpringUtil implements ApplicationContextAware { private static ApplicationContext applicationContext; Override public void setApplicationContext(ApplicationContext applicationContext) throws BeansException { SpringUtil.applicationContext applicationContext; } public static ApplicationContext getApplicationContext() { return applicationContext; } /** * 按名稱獲取Bean */ SuppressWarnings(unchecked) public static T T getBean(String name) { if (applicationContext null) { throw new IllegalStateException(Spring容器尚未初始化無(wú)法獲取Bean); } return (T) applicationContext.getBean(name); } /** * 按類型獲取Bean */ public static T T getBean(ClassT clazz) { if (applicationContext null) { throw new IllegalStateException(Spring容器尚未初始化無(wú)法獲取Bean); } return applicationContext.getBean(clazz); } /** * 按名稱類型獲取Bean避免類型轉(zhuǎn)換隱患 */ public static T T getBean(String name, ClassT clazz) { if (applicationContext null) { throw new IllegalStateException(Spring容器尚未初始化無(wú)法獲取Bean); } return applicationContext.getBean(name, clazz); } }有幾個(gè)細(xì)節(jié)值得展開講。第一Component注解不能省。因?yàn)锳pplicationContextAware的回調(diào)發(fā)生在Bean初始化階段如果SpringUtil本身不被注冊(cè)成BeanSpring根本沒有機(jī)會(huì)調(diào)用setApplicationContext。很多人把這個(gè)類寫完之后忘記加注解導(dǎo)致靜態(tài)字段一直是null排查半天。第二靜態(tài)字段不能加final。有人習(xí)慣寫private static final ApplicationContext applicationContext然后發(fā)現(xiàn)編譯報(bào)錯(cuò)或者賦值無(wú)效因?yàn)閒inal字段在構(gòu)造器里完成初始化而setApplicationContext是在Bean屬性填充階段被回調(diào)的這倆時(shí)機(jī)對(duì)不上。第三這里我加了判空保護(hù)。當(dāng)工具類在容器啟動(dòng)早期被調(diào)用時(shí)applicationContext可能還是null如果直接getBean會(huì)拋NullPointerException。顯式拋出IllegalStateException并附上中文提示能讓你在排查問(wèn)題時(shí)第一時(shí)間知道是容器沒初始化而不是堆棧里一行莫名其妙的空指針。2.2 靜態(tài)注入模式不用實(shí)現(xiàn)接口的方案另一種常見寫法是利用ApplicationContext的靜態(tài)注入本質(zhì)和ApplicationContextAware沒有區(qū)別只是把回調(diào)入口換成了構(gòu)造器注入。這里展示一個(gè)變體。Component public class SpringUtil { private static ApplicationContext applicationContext; Autowired public SpringUtil(ApplicationContext applicationContext) { SpringUtil.applicationContext applicationContext; } public static T T getBean(ClassT clazz) { return applicationContext.getBean(clazz); } }這段代碼的核心邏輯是Spring在創(chuàng)建SpringUtil這個(gè)Bean時(shí)發(fā)現(xiàn)構(gòu)造器需要一個(gè)ApplicationContext類型的參數(shù)于是自動(dòng)把容器本身傳進(jìn)來(lái)再通過(guò)構(gòu)造器賦值給靜態(tài)字段。兩種方案我都用過(guò)實(shí)際體驗(yàn)差異不大。ApplicationContextAware更“正統(tǒng)”因?yàn)樗旧砭褪菫榱俗孊ean感知容器而設(shè)計(jì)的接口語(yǔ)義清晰構(gòu)造器注入的方式更簡(jiǎn)潔少寫一個(gè)接口方法。但如果你的項(xiàng)目里已經(jīng)大量使用構(gòu)造器注入保持一致也未嘗不可。需要特別注意的是無(wú)論用哪種方式都必須保證SpringUtil被Spring管理否則靜態(tài)字段永遠(yuǎn)是空的。另外提一句有些老項(xiàng)目里能看到PostConstruct配合Resource的寫法也就是在初始化方法里手動(dòng)賦值。這種方案也能跑通但多一個(gè)方法可讀性沒有前兩種好我一般不推薦新手用。2.3 獲取Bean的三個(gè)方法各有什么講究很多人認(rèn)為getBean就是一行代碼的事沒什么可說(shuō)的。實(shí)際上三個(gè)重載方法的適用場(chǎng)景完全不同選錯(cuò)了會(huì)埋坑。getBean(String name)是純按名稱獲取返回值是Object通常需要強(qiáng)轉(zhuǎn)。這個(gè)方法的隱患在于如果同類型存在多個(gè)Bean按類型獲取會(huì)失敗但按名稱獲取不會(huì)反之如果名稱拼錯(cuò)了運(yùn)行時(shí)直接拋NoSuchBeanDefinitionException。所以當(dāng)你明確知道beanName且不糾結(jié)類型安全時(shí)用它最直接。getBean(ClassT clazz)是純按類型獲取。這是我用得最多的方式因?yàn)轭愋桶踩幾g器能幫你檢查大部分錯(cuò)誤。前提是容器里該類型只能有一個(gè)Bean否則會(huì)拋NoUniqueBeanDefinitionException。遇到多個(gè)實(shí)現(xiàn)類的場(chǎng)景可以用Primary標(biāo)記主Bean或者按名稱獲取。getBean(String name, ClassT clazz)是前兩者的結(jié)合體既校驗(yàn)名稱又校驗(yàn)類型嚴(yán)格程度最高。如果你在寫框架代碼不確定調(diào)用方會(huì)塞什么參數(shù)過(guò)來(lái)建議使用這個(gè)重載。我個(gè)人建議在業(yè)務(wù)代碼里默認(rèn)用getBean(ClassT)把類型檢查的工作交給容器最簡(jiǎn)單也最不容易出錯(cuò)。3. 實(shí)際應(yīng)用在非Spring環(huán)境中安全獲取Bean3.1 典型場(chǎng)景工具類、定時(shí)任務(wù)、監(jiān)聽器、線程池寫SpringUtil的目的就是為了在“容器管不到的地方”使用容器對(duì)象。我實(shí)際項(xiàng)目中遇到頻率最高的場(chǎng)景有四種。第一種是自定義工具類。比如DateUtils、RegexUtils、JsonUtils這些都是靜態(tài)方法類本身沒有被Spring托管。當(dāng)某個(gè)靜態(tài)方法內(nèi)部需要調(diào)用Service時(shí)注入行不通直接SpringUtil.getBean(XxxService.class)最省事。第二種是定時(shí)任務(wù)框架。你的項(xiàng)目可能用了QuartzJob類由Quartz實(shí)例化Spring不參與管理。Job內(nèi)部要操作數(shù)據(jù)庫(kù)通常的做法是在Job執(zhí)行方法里調(diào)用SpringUtil.getBean(XxxMapper.class)。第三種是監(jiān)聽器和過(guò)濾器。尤其是OncePerRequestFilter它由Web容器管理不在Spring容器內(nèi)但你又需要拿到Spring的Service。雖然可以通過(guò)WebApplicationContextUtils.getWebApplicationContext間接獲取但代碼不如SpringUtil簡(jiǎn)潔。第四種是多線程場(chǎng)景。在Thread子類或Runnable實(shí)現(xiàn)里成員變量不會(huì)被Spring注入。我一般在線程run方法里直接SpringUtil.getBean來(lái)獲取依賴比如異步通知、異步寫日志、數(shù)據(jù)補(bǔ)償任務(wù)。public class OrderTimeoutTask implements Runnable { private Long orderId; public OrderTimeoutTask(Long orderId) { this.orderId orderId; } Override public void run() { // Spring容器外的線程里無(wú)法通過(guò)注入獲取依賴 OrderService orderService SpringUtil.getBean(OrderService.class); orderService.cancelTimeoutOrder(orderId); } }這里有一個(gè)注意點(diǎn)線程內(nèi)部獲取Bean時(shí)容器早已完成初始化所以不用擔(dān)心applicationContext為空的“啟動(dòng)期問(wèn)題”。但是線程池一旦緩存了長(zhǎng)期存活的線程Bean的獲取也是穩(wěn)定可靠的前提是你沒有在項(xiàng)目里搞動(dòng)態(tài)銷毀Bean這類操作。3.2 通過(guò)SpringUtil讀取配置和環(huán)境信息除了獲取Bean持有ApplicationContext引用后你還能順手獲取配置信息、環(huán)境Profile、發(fā)布事件等。很多人把SpringUtil局限在getBean上其實(shí)它的擴(kuò)展能力被低估了。讀取配置是最實(shí)用的擴(kuò)展。有時(shí)候代碼里需要讀取配置中心的某個(gè)Key但當(dāng)前類又不是配置屬性類。用Value注入雖然可以但靜態(tài)方法里用不了Value。此時(shí)可以通過(guò)Environment對(duì)象讀取public static String getProperty(String key) { return applicationContext.getEnvironment().getProperty(key); } public static String getProperty(String key, String defaultValue) { return applicationContext.getEnvironment().getProperty(key, defaultValue); }判斷當(dāng)前環(huán)境也常用public static boolean isDev() { Environment environment applicationContext.getEnvironment(); return environment.acceptsProfiles(Profiles.of(dev)); }換一個(gè)角度看只要持有ApplicationContext你就等于擁有了Spring容器的“遙控器”。用得好可以在不破壞Spring管理規(guī)則的前提下大幅提升編碼效率用不好容易寫出Servlet容器加載時(shí)直接NPE的代碼。核心原則是只在容器啟動(dòng)完成后使用避免在ApplicationContext初始化階段強(qiáng)行調(diào)用。3.3 用ApplicationContext發(fā)布事件實(shí)現(xiàn)模塊解耦Spring自帶的ApplicationEvent機(jī)制非常適合做模塊解耦而且通過(guò)SpringUtil可以隨時(shí)發(fā)布事件不需要注入ApplicationEventPublisher。定義一個(gè)事件類public class OrderCreatedEvent extends ApplicationEvent { private Long orderId; public OrderCreatedEvent(Object source, Long orderId) { super(source); this.orderId orderId; } public Long getOrderId() { return orderId; } }在業(yè)務(wù)代碼中哪怕當(dāng)前類不是Service也不是Controller也能直接發(fā)布事件SpringUtil.getApplicationContext().publishEvent(new OrderCreatedEvent(this, orderId));監(jiān)聽端就是一個(gè)普通的EventListener方法。這樣做的好處是訂單創(chuàng)建的核心流程不用關(guān)心后續(xù)要通知誰(shuí)、要扣多少庫(kù)存、要發(fā)什么短信這些全部由監(jiān)聽器異步處理。用Async配合線程池還能實(shí)現(xiàn)異步化。這個(gè)玩法放在SpringUtil的能力矩陣?yán)锸俏艺J(rèn)為被大多數(shù)人忽略但價(jià)值極高的一個(gè)點(diǎn)。如果你正在設(shè)計(jì)一個(gè)中大型項(xiàng)目的骨架可以在SpringUtil里封裝一個(gè)publishEvent靜態(tài)方法讓所有非Bean類都能參與到事件驅(qū)動(dòng)架構(gòu)里。4. 常見問(wèn)題與排查技巧實(shí)錄4.1 啟動(dòng)階段調(diào)用getBean返回null或拋空指針這個(gè)問(wèn)題幾乎人人都會(huì)遇到。項(xiàng)目啟動(dòng)時(shí)某些ApplicationRunner、PostConstruct注解的方法、配置類中的初始化邏輯在容器還沒完全初始化時(shí)就調(diào)用了SpringUtil此時(shí)applicationContext尚未賦值。我習(xí)慣的排查套路分三步。第一步確認(rèn)SpringUtil本身有沒有被掃描到。檢查啟動(dòng)類所在包路徑是否覆蓋SpringUtil所在的包如果覆蓋不到Component就白寫了。第二步確認(rèn)調(diào)用時(shí)機(jī)。Spring的ApplicationContextAware#setApplicationContext是在Bean初始化階段回調(diào)的但其他Bean的PostConstruct方法可能在它之前執(zhí)行。如果兩個(gè)類都在PostConstruct里干活另一個(gè)類的初始化順序排在SpringUtil之前就可能拿到null。第三步根據(jù)項(xiàng)目啟動(dòng)日志確認(rèn)當(dāng)前執(zhí)行到哪一步。Spring啟動(dòng)日志里能看到Root WebApplicationContext相關(guān)的初始化信息如果自己代碼的執(zhí)行點(diǎn)早于BeanFactory完成預(yù)實(shí)例化很可能就是時(shí)機(jī)問(wèn)題。最簡(jiǎn)單的規(guī)避方式是把必須在啟動(dòng)階段執(zhí)行的邏輯放到ApplicationReadyEvent監(jiān)聽器里此時(shí)容器已經(jīng)全部就緒。例如Component public class StartupRunner { EventListener(ApplicationReadyEvent.class) public void onReady() { // 此時(shí) SpringUtil 一定可用 XxxService service SpringUtil.getBean(XxxService.class); service.init(); } }如果你不想改代碼也可以在SpringUtil里加一個(gè)“延遲初始化”的保護(hù)邏輯第一次調(diào)用getBean時(shí)如果發(fā)現(xiàn)容器還沒就緒就拋出一個(gè)語(yǔ)義明確的異常而不是讓NPE掩蓋真實(shí)問(wèn)題。4.2 多上下文環(huán)境導(dǎo)致拿錯(cuò)了BeanSpring MVC項(xiàng)目里存在父子容器結(jié)構(gòu)DispatcherServlet創(chuàng)建子容器ContextLoaderListener創(chuàng)建父容器。如果你的SpringUtil被父容器掃描到但它持有的ApplicationContext是父容器而Controller里的Service在子容器中g(shù)etBean查不到就報(bào)NoSuchBeanDefinitionException。典型表現(xiàn)非Web層的類調(diào)用SpringUtil.getBean一切正常Controller層調(diào)用卻拿不到Bean或者反過(guò)來(lái)兩個(gè)地方拿到的同一類型Bean實(shí)例不是同一個(gè)。解決思路有兩個(gè)。第一個(gè)通過(guò)ContextLoader.getCurrentWebApplicationContext()獲取線程綁定的WebApplicationContext。第二個(gè)在SpringBoot項(xiàng)目中盡量保證所有Bean都在同一個(gè)容器中不要手動(dòng)創(chuàng)建子容器也不要在DispatcherServlet里單獨(dú)配置掃描路徑。其實(shí)SpringBoot默認(rèn)已經(jīng)避開了父子容器問(wèn)題如果你還在用傳統(tǒng)的SSM架構(gòu)這里要多留一個(gè)心眼。4.3 靜態(tài)工具類導(dǎo)致循環(huán)依賴或初始化順序混亂有一種誤用模式是這樣的某個(gè)Service通過(guò)SpringUtil.getBean獲取了另一個(gè)Service而另一個(gè)Service又反過(guò)來(lái)通過(guò)SpringUtil.getBean獲取第一個(gè)Service。由于是運(yùn)行時(shí)強(qiáng)取這種循環(huán)依賴不會(huì)被Spring的循環(huán)依賴檢測(cè)機(jī)制捕獲但可能造成邏輯上的死循環(huán)或數(shù)據(jù)不一致。另一個(gè)容易出問(wèn)題的地方是構(gòu)造器中調(diào)用SpringUtil.getBean。Spring創(chuàng)建Bean時(shí)會(huì)先執(zhí)行構(gòu)造器如果構(gòu)造器里需要依賴另一個(gè)Bean而這個(gè)Bean又還在創(chuàng)建中就可能拿到一個(gè)未初始化完成的對(duì)象。我的經(jīng)驗(yàn)是不要在構(gòu)造器中調(diào)用SpringUtil。如果Bean初始化時(shí)需要依賴其他Bean直接用正常的注入方式Spring會(huì)自動(dòng)處理依賴順序。4.4 方法速查表常見報(bào)錯(cuò)信息原因解決方案IllegalStateException: Spring容器尚未初始化啟動(dòng)早期調(diào)用SpringUtil改用ApplicationReadyEvent觸發(fā)初始化邏輯NullPointerException靜態(tài)字段未賦值SpringUtil未被掃描檢查Component注解與包掃描路徑NoSuchBeanDefinitionException按名稱/類型查不到Bean確認(rèn)beanName拼寫、類型是否為接口、是否在子容器NoUniqueBeanDefinitionException同類型存在多個(gè)實(shí)現(xiàn)使用Primary或按名稱指定BeanBeanNotOfRequiredTypeException按名稱獲取的Bean類型與預(yù)期不符使用getBean(String, ClassT)重載方法這些坑我基本都踩過(guò)一遍整理出來(lái)就是一張速查表。遇到問(wèn)題先對(duì)號(hào)入座能省下不少排查時(shí)間。5. 進(jìn)階玩法與優(yōu)化思路5.1 泛型方法與延遲獲取讓工具類更好用上面的基礎(chǔ)工具類已經(jīng)能覆蓋大多數(shù)場(chǎng)景但如果你要把它做成公司內(nèi)部的通用組件還可以再加一層封裝。getBean返回后通常要強(qiáng)轉(zhuǎn)或直接接收但有些業(yè)務(wù)場(chǎng)景需要延遲獲取Bean。比如一個(gè)事件監(jiān)聽器里你希望每次執(zhí)行時(shí)才拿到最新的Bean實(shí)例而不是在監(jiān)聽器創(chuàng)建時(shí)就固化引用。此時(shí)可以用ObjectProviderpublic static T ObjectProviderT getBeanProvider(ClassT clazz) { return applicationContext.getBeanProvider(clazz); }調(diào)用方可以getIfAvailable()獲取Bean如果容器中沒有該類型就返回null不會(huì)拋異常。這個(gè)特性在可選依賴場(chǎng)景下非常有用比如某個(gè)模塊存在就調(diào)用它的邏輯不存在就跳過(guò)。泛型方面我看到過(guò)有人封裝getBeanOfType內(nèi)部用ResolvableType實(shí)現(xiàn)支持獲取ListXxx、MapString, Xxx這類集合類型。但說(shuō)實(shí)話多數(shù)項(xiàng)目用不到真正需要時(shí)直接注入ListXxx更優(yōu)雅。不建議把SpringUtil做得太重保持單一職責(zé)獲取對(duì)象就只負(fù)責(zé)獲取對(duì)象。5.2 靜態(tài)字段注入的替代方案手動(dòng)注冊(cè)Bean如果你連Component都不想寫也可以直接在配置類里手動(dòng)注冊(cè)SpringUtil本質(zhì)一樣Configuration public class SpringUtilConfig { Bean public SpringUtil springUtil() { return new SpringUtil(); } }這種做法的適用場(chǎng)景是SpringUtil所在的jar包不在主應(yīng)用掃描路徑內(nèi)而你又不希望讓掃描路徑無(wú)限擴(kuò)大通過(guò)Import或Bean顯式注冊(cè)就很有必要。另外還有一個(gè)細(xì)節(jié)有些人在多模塊項(xiàng)目里把SpringUtil放在一個(gè)公共模塊業(yè)務(wù)模塊引用之后發(fā)現(xiàn)applicationContext還是null。大概率是公共模塊里的ComponentScan沒有覆蓋到或者公共模塊的類被框架過(guò)濾了。此時(shí)用Import(SpringUtil.class)或者采用上面這種Bean顯式注冊(cè)問(wèn)題立刻解決。5.3 ThreadLocal與RequestContextHolder的補(bǔ)充既然聊到容器對(duì)象我順便提一下Spring里另一個(gè)非常容易和SpringUtil一起使用的工具RequestContextHolder。當(dāng)你在非Spring管理的類中需要拿到當(dāng)前請(qǐng)求的HttpServletRequest時(shí)可以直接HttpServletRequest request ((ServletRequestAttributes) RequestContextHolder.getRequestAttributes()).getRequest();這個(gè)工具同樣是從容器上下文中解耦的對(duì)象獲取方式配合SpringUtil一起使用時(shí)很多框架層的代碼可以寫得非常干凈。但它依賴線程上下文如果在異步線程里使用會(huì)失效需要手動(dòng)把請(qǐng)求屬性傳遞進(jìn)去這是一個(gè)隱藏的坑值得留意。6. 一些使用心得和收尾前面寫了實(shí)現(xiàn)、應(yīng)用、排坑和進(jìn)階最后分享幾條比較個(gè)人的心得。在實(shí)際項(xiàng)目中我不太建議把SpringUtil當(dāng)成“萬(wàn)能鑰匙”到處getBean。正常情況下所有Bean應(yīng)該通過(guò)Spring依賴注入來(lái)協(xié)作SpringUtil只是為了處理“容器外”的場(chǎng)景。如果一個(gè)Service里到處是SpringUtil.getBean(Xxx.class)說(shuō)明依賴關(guān)系設(shè)計(jì)可能出了問(wèn)題應(yīng)該調(diào)整思路讓被依賴的對(duì)象通過(guò)構(gòu)造器注入進(jìn)來(lái)。我自己的使用邊界很明確工具類內(nèi)部偶爾調(diào)用第三方框架的Job、Listener中調(diào)用以及組件封裝時(shí)為了避免注入鏈過(guò)長(zhǎng)而調(diào)用。業(yè)務(wù)Service之間的依賴一律走注入。還有一點(diǎn)SpringUtil的靜態(tài)字段會(huì)隨著Spring容器的重新加載而更新在單元測(cè)試中反復(fù)啟動(dòng)容器時(shí)要確保上一次的容器已經(jīng)關(guān)閉否則可能拿到舊容器的引用。測(cè)試?yán)镂乙话銜?huì)加一個(gè)DirtiesContext或者在AfterEach里清空靜態(tài)字段避免上下文串了。如果你準(zhǔn)備在公司的項(xiàng)目中推廣SpringUtil建議在編碼規(guī)范里明確標(biāo)注它的使用場(chǎng)景和禁止使用場(chǎng)景這樣后來(lái)的人不會(huì)誤用。給工具類加上清晰的javadoc說(shuō)明“為什么存在”和“什么時(shí)候別用”比寫十行注釋講參數(shù)更重要。這個(gè)方向還能繼續(xù)擴(kuò)展比如把getBean包裝成帶緩存的形式、增加可觀測(cè)性日志等但我建議保持工具輕盈避免把一個(gè)靜態(tài)工具類做成“服務(wù)定位器”反模式。最后再分享一個(gè)小技巧如果你用的是Spring Boot可以在啟動(dòng)日志里加一行輸出確認(rèn)SpringUtil是否成功持有的ApplicationContext。比如在setApplicationContext里打一行INFO日志“SpringUtil context initialized”。以后排查問(wèn)題一看日志就知道這個(gè)組件有沒有被正確裝配。這個(gè)不起眼的細(xì)節(jié)在聯(lián)調(diào)環(huán)境里救過(guò)我很多次。