你用Spring Boot寫(xiě)接口第一件事不該是打開(kāi)IDE敲代碼而是先想清楚一個(gè)問(wèn)題你寫(xiě)的是接口不是Java類(lèi)。很多新手甚至干了三五年的開(kāi)發(fā)把Controller當(dāng)成業(yè)務(wù)邏輯的收容所把Service當(dāng)成萬(wàn)能的數(shù)據(jù)庫(kù)操作層最后接口越寫(xiě)越臃腫排錯(cuò)越來(lái)越痛苦。根源在于他們對(duì)依賴和注解的理解停留在“能用就行”的層面從未深究這些工具在你和機(jī)器之間到底立下了什么規(guī)矩。先說(shuō)依賴。Spring Boot最迷人的地方不是“自動(dòng)配置”而是它幫你把“選擇”的權(quán)力提前剝奪了。你引入spring-boot-starter-web它自動(dòng)帶進(jìn)Tomcat、Jackson、Spring MVC你引入spring-boot-starter-validation它連Hibernate Validator都給你備好。這套組合拳看似方便但如果你不了解每個(gè)starter背后掛了哪些傳遞依賴遲早會(huì)在某個(gè)深夜被NoClassDefFoundError逼瘋。記住一個(gè)原則依賴不是越多越好而是越精確越好。你寫(xiě)一個(gè)純粹返回JSON的接口就沒(méi)必要拖一個(gè)spring-boot-starter-thymeleaf進(jìn)來(lái)你只做簡(jiǎn)單的參數(shù)校驗(yàn)也別沖動(dòng)地引入整套spring-boot-starter-security。每多一個(gè)依賴就意味著多一層被黑、被拖慢、被埋雷的可能性。先拆解starter-web這根骨頭spring-boot-starter-web是所有HTTP接口的基石。它替你解決了三個(gè)核心問(wèn)題接收請(qǐng)求、轉(zhuǎn)換參數(shù)、返回響應(yīng)。但注意它默認(rèn)攜帶的嵌入式容器是Tomcat這個(gè)選擇不是神圣不可侵犯的。如果你追求極致的啟動(dòng)速度或內(nèi)存占用完全可以用spring-boot-starter-webflux走響應(yīng)式路線或者把Tomcat換成Undertow、Jetty。換容器不是炫技而是對(duì)資源利用率的尊重。一個(gè)簡(jiǎn)單的做法在pom.xml里排除掉spring-boot-starter-tomcat再手動(dòng)添加spring-boot-starter-undertow。別小看這個(gè)動(dòng)作在高并發(fā)場(chǎng)景下Undertow對(duì)內(nèi)存的吝嗇會(huì)讓Tomcat相形見(jiàn)絀。然后是Jackson。這個(gè)JSON神器默認(rèn)參與所有序列化和反序列化但它不是萬(wàn)能的。你寫(xiě)一個(gè)LocalDateTime字段直接返回給前端Jackson會(huì)拋異?！悄闩渲昧薐avaTimeModule。Spring Boot已經(jīng)自動(dòng)幫你注冊(cè)了這個(gè)模塊但默認(rèn)的日期格式是ISO格式前端不一定認(rèn)。你必須在application.yml里顯式指定spring.jackson.date-format或者用JsonFormat注解做局部覆蓋。這不是麻煩而是你對(duì)契約的敬畏。接口不是給你自己看的是給那些可能用Python、Go、甚至Excel調(diào)用你的人看的。字段叫userName還是user_name日期是yyyy-MM-dd HH:mm:ss還是時(shí)間戳這都得在類(lèi)的設(shè)計(jì)階段就定死。注解的核心是定位而非裝飾很多人把注解當(dāng)魔法其實(shí)注解就是標(biāo)記和元數(shù)據(jù)。RestController告訴Spring這個(gè)類(lèi)直接處理HTTP請(qǐng)求并且返回的對(duì)象會(huì)被序列化為JSON。它的兄弟Controller則返回視圖名配合ResponseBody才等價(jià)于RestController。用RestController是態(tài)度用Controller是情懷混著用是給自己挖坑。一個(gè)Controller里不要既有返回JSON的接口又有返回視圖的接口職責(zé)混亂會(huì)讓測(cè)試和維護(hù)都變成噩夢(mèng)。RequestMapping是家族GetMapping、PostMapping、PutMapping、DeleteMapping是它的具體化表達(dá)。請(qǐng)務(wù)必使用后四個(gè)不要用寬泛的RequestMapping。為什么因?yàn)镚etMapping不僅限定URL還強(qiáng)制限定HTTP方法你的接口意圖一目了然。如果你用RequestMapping默認(rèn)支持所有方法別人GET也能進(jìn)、POST也能進(jìn)這不是開(kāi)放是失控。接口的語(yǔ)義化是優(yōu)雅的第一步。真正的深度陷阱在參數(shù)綁定上。RequestParam用于獲取查詢參數(shù)PathVariable用于路徑變量RequestBody用于JSON報(bào)文這三個(gè)必須分清。有人圖省事把所有參數(shù)都塞進(jìn)一個(gè)Map接收這等于放棄了類(lèi)型安全。寫(xiě)接口不寫(xiě)DTO就跟不系安全帶開(kāi)車(chē)一樣遲早出事故。一個(gè)規(guī)規(guī)矩矩的RequestBody應(yīng)當(dāng)對(duì)應(yīng)一個(gè)經(jīng)過(guò)驗(yàn)證的DTO類(lèi)類(lèi)里每個(gè)字段都有明確的類(lèi)型、命名和驗(yàn)證注解。別用Map偷懶你偷的每一次懶都是未來(lái)線上故障的伏筆。校驗(yàn)注解是接口的安檢門(mén)既然引入spring-boot-starter-validation就別讓它吃灰。Valid或Validated加在參數(shù)前面然后配合NotNull、NotBlank、Size、Pattern等注解你的接口就擁有了第一道防線。校驗(yàn)注解不是可有可無(wú)的裝飾而是你對(duì)調(diào)用方最冷酷的溫柔。試想一個(gè)POST /api/user接口如果不去校驗(yàn)email字段的格式數(shù)據(jù)庫(kù)里就會(huì)混入一堆垃圾數(shù)據(jù)后續(xù)清洗成本遠(yuǎn)高于你寫(xiě)一行Email的成本。這里有個(gè)容易被忽視的坑Validated在Controller層只能做基礎(chǔ)校驗(yàn)如果你要在Service層做跨字段的復(fù)雜邏輯校驗(yàn)就需要把Validated加到Service實(shí)現(xiàn)類(lèi)上并在方法參數(shù)前用Valid。分層校驗(yàn)不是重復(fù)勞動(dòng)而是職責(zé)分離的體現(xiàn)。Controller只管報(bào)文協(xié)議的正確性Service管業(yè)務(wù)規(guī)則的正確性兩者互不越界。很多人喜歡在Controller里寫(xiě)一大堆if判斷然后拋異常這種做法不是不行但它把業(yè)務(wù)代碼和接口代碼揉在一起讓Controller變成一個(gè)臟亂差的加工廠。更好的做法是定義自己的業(yè)務(wù)異常類(lèi)配合RestControllerAdvice做全局異常處理。這樣你的接口代碼里不會(huì)出現(xiàn)任何try-catch錯(cuò)誤邏輯被收斂到一個(gè)地方清爽得讓人感動(dòng)。依賴注入的三種姿勢(shì)你選哪種Spring的依賴注入有字段注入、構(gòu)造器注入、Setter注入三種方式。如果你還在用Autowired直接在字段上加注解請(qǐng)捫心自問(wèn)你的類(lèi)真的需要被外部替換實(shí)現(xiàn)嗎字段注入導(dǎo)致類(lèi)與容器緊密耦合單元測(cè)試時(shí)無(wú)法輕易地替換依賴而構(gòu)造器注入則天然支持不可變性依賴在對(duì)象創(chuàng)建時(shí)就固定下來(lái)這種確定性讓人安心。所以新寫(xiě)代碼一律用構(gòu)造器注入用RequiredArgsConstructorLombok生成構(gòu)造器既能減少樣板代碼又能保證依賴不可變。這不僅是習(xí)慣更是對(duì)SOLID原則的尊重。接下來(lái)是Component、Service、Repository、Controller這四個(gè)注解的區(qū)別。它們本質(zhì)都是Component的衍生但語(yǔ)義不同Controller管HTTP層Service管業(yè)務(wù)邏輯Repository管數(shù)據(jù)訪問(wèn)。別用Component一股腦地標(biāo)注所有類(lèi)那是把螺絲刀當(dāng)成錘子用。Repository還額外提供持久化異常轉(zhuǎn)換這對(duì)Spring Data JPA來(lái)說(shuō)尤為重要——你沒(méi)寫(xiě)RepositorySQL異常就不會(huì)被轉(zhuǎn)換成Spring的DataAccessException你辛辛苦苦catch到的異?？赡苁且粭l讓人摸不著頭腦的SQLIntegrityConstraintViolationException而不是一個(gè)友好的業(yè)務(wù)錯(cuò)誤提示。Autowired的歧義和解決之道當(dāng)你有一個(gè)接口UserService和兩個(gè)實(shí)現(xiàn)類(lèi)UserServiceImpl和AdminUserServiceImpl時(shí)Autowired靠什么選定答案是Primary或Qualifier。Primary定義默認(rèn)優(yōu)先Qualifier定義精確指定。但更好的做法是在構(gòu)造器參數(shù)上直接用Qualifier或者干脆不要用接口注入直接注入具體實(shí)現(xiàn)類(lèi)。很多人覺(jué)得面向接口編程就必須用接口注入那是走火入魔。接口的意義在于抽象但如果你的項(xiàng)目里這個(gè)接口只有一個(gè)實(shí)現(xiàn)接口注入只是徒增復(fù)雜度。不要為未來(lái)可能發(fā)生的擴(kuò)展而犧牲當(dāng)下的簡(jiǎn)單等真正有兩個(gè)實(shí)現(xiàn)時(shí)再引入接口注入也不遲。你還得認(rèn)識(shí)ConfigurationProperties。這個(gè)注解用于綁定配置文件中的自定義屬性比如app.token.expire-time。相比Value一個(gè)個(gè)字段注入ConfigurationProperties可以把一組相關(guān)配置封裝成一個(gè)POJO同時(shí)支持類(lèi)型安全校驗(yàn)和復(fù)雜嵌套結(jié)構(gòu)。如果你有超過(guò)三個(gè)配置項(xiàng)需要讀取就別再用Value零散地往類(lèi)里塞了那是對(duì)你自己的不負(fù)責(zé)任。一個(gè)ConfigurationProperties類(lèi)配上Component或EnableConfigurationProperties再啟用spring-boot-configuration-processorIDE里還能自動(dòng)提示配置項(xiàng)這體驗(yàn)甩Value幾條街。Bean的生命周期與條件裝配PostConstruct和PreDestroy是管理Bean初始化和銷(xiāo)毀的鉤子。有些初始化邏輯比如加載緩存、連接外部服務(wù)可以放在PostConstruct里。但注意這個(gè)時(shí)機(jī)是在依賴注入完成之后構(gòu)造方法執(zhí)行之后但尚未對(duì)外提供服務(wù)。如果你在構(gòu)造方法里直接去連數(shù)據(jù)庫(kù)很可能依賴還沒(méi)注入完畢會(huì)得到空指針。所以初始化邏輯務(wù)必放在PostConstruct或者InitializingBean接口里銷(xiāo)毀資源用PreDestroy。條件裝配的幾個(gè)注解也值得深究ConditionalOnProperty、ConditionalOnBean、ConditionalOnMissingBean。它們讓Spring Boot的自動(dòng)配置成為可能。你自己寫(xiě)組件時(shí)用ConditionalOnMissingBean來(lái)讓用戶能覆蓋你的默認(rèn)配置這是一種開(kāi)放姿態(tài)用ConditionalOnProperty根據(jù)配置項(xiàng)的值來(lái)決定是否啟用某個(gè)Bean這能讓你的組件靈活適配不同環(huán)境。這些注解的價(jià)值在于它們讓“配置即代碼”這一理念落地。當(dāng)你看到ConditionalOnMissingBean時(shí)你該明白Spring官方在給你機(jī)會(huì)——它不強(qiáng)行占坑它把主動(dòng)權(quán)交到你手上。終極主題當(dāng)你從零開(kāi)始寫(xiě)一個(gè)接口依賴和注解的選擇應(yīng)當(dāng)是一氣呵成的。先確定你需不需要響應(yīng)式再去選spring-boot-starter-web還是webflux接著定義你的DTO和返回結(jié)構(gòu)想清楚錯(cuò)誤碼體系再動(dòng)手寫(xiě)Controller。Controller層的注解就那么幾個(gè)但組合方式千變?nèi)f化而每個(gè)組合都對(duì)應(yīng)一種協(xié)議。RestControllerPostMappingValidRequestBody這是一套完整的寫(xiě)JSON接口的標(biāo)準(zhǔn)姿勢(shì)RestControllerGetMappingRequestParamMin又是另一套查詢接口的經(jīng)典做法。沒(méi)有哪種注解組合是絕對(duì)的真理但有亂用注解的后果是絕對(duì)清晰——你的代碼會(huì)變得難以閱讀更難以測(cè)試。依賴的數(shù)量不代表項(xiàng)目的強(qiáng)大注解的堆砌也不說(shuō)明代碼的優(yōu)雅。每一次引入依賴都是一次信任投票每一個(gè)注解都是一條契約聲明。你寫(xiě)接口時(shí)其實(shí)是你和未來(lái)的維護(hù)者、調(diào)用者、甚至網(wǎng)絡(luò)另一端某個(gè)陌生技術(shù)棧的人之間的對(duì)話。這場(chǎng)對(duì)話的語(yǔ)法就是這些依賴和注解。你用得越精準(zhǔn)這場(chǎng)對(duì)話就越順暢。最后送你一個(gè)自查清單寫(xiě)接口前問(wèn)問(wèn)自己這個(gè)接口是否依賴了不必要的starter是否每個(gè)注解都在表達(dá)確定的語(yǔ)義是否用DTO代替了散裝參數(shù)校驗(yàn)是否覆蓋了所有必填項(xiàng)異常處理是否統(tǒng)一如果答案都是肯定的那你已經(jīng)領(lǐng)悟了Spring Boot接口開(kāi)發(fā)的精髓——不是把所有功能都塞進(jìn)來(lái)而是在最小必要依賴中用精確的注解刻畫(huà)出清晰的邊界。這才是專業(yè)與業(yè)余的分水嶺。