寫Java這幾年我有個(gè)特別深的感觸代碼寫得好不好不看功能多花哨先看判空寫得干不干凈。前兩天在群里看到一段同事分享的代碼用Optional加方法引用把原本七八行的if嵌套壓縮成了兩行鏈?zhǔn)秸{(diào)用行云流水。底下評(píng)論區(qū)一片“別人家的代碼從不讓人失望”。說(shuō)真的判空這個(gè)動(dòng)作每個(gè)Java開(kāi)發(fā)每天都要寫十幾次但絕大多數(shù)人寫的都是最原始的if (xxx ! null)堆在一起又臭又長(zhǎng)。這篇文章我就想跟你聊聊判空到底該怎么寫才優(yōu)雅優(yōu)雅的背后又是什么邏輯。1. 判空到底在判什么先搞清楚問(wèn)題的本質(zhì)1.1 你以為的判空和真正的判空很多人一提到判空第一反應(yīng)就是“防止空指針異?！?。這話沒(méi)毛病但只說(shuō)對(duì)了一半。判空真正要解決的是一個(gè)值可能不存在時(shí)你的程序該如何優(yōu)雅地繼續(xù)下去。舉個(gè)例子用戶下單時(shí)要讀取用戶的默認(rèn)地址。地址可能為空那此時(shí)是拋異常、用備用地址、還是提示用戶手動(dòng)填寫這三種情況的處理邏輯完全不同。所以判空的本質(zhì)不是“有沒(méi)有值”的二選一判斷而是**“沒(méi)值的時(shí)候怎么辦”的策略選擇**。我見(jiàn)過(guò)太多代碼是這樣的if (user ! null) { Address address user.getAddress(); if (address ! null) { String detail address.getDetail(); if (detail ! null) { System.out.println(detail); } } }這段代碼確實(shí)防御了空指針但它把“沒(méi)值怎么辦”這個(gè)問(wèn)題完全忽略了——沒(méi)值就什么都不做靜默吞掉。這在業(yè)務(wù)上往往是錯(cuò)誤的用戶地址都沒(méi)填你應(yīng)該引導(dǎo)用戶去填寫而不是 silently ignore。所以我把判空拆成三個(gè)層面來(lái)看存在性判空值是不是null有效性判空值存在但有沒(méi)有業(yè)務(wù)意義比如空字符串、空集合、全空白字符策略性判空沒(méi)值了之后是給默認(rèn)值、拋異常、還是跳過(guò)邏輯大部分人的判空只停留在第一層這就是代碼丑陋的根源。1.2 判空混亂的根源JDK 接口設(shè)計(jì)的歷史包袱為什么別的語(yǔ)言判空沒(méi)這么痛苦偏偏 Java 程序員天天跟null搏斗這事得追溯到 JDK 早期的接口設(shè)計(jì)。你看Map.get()方法JDK 文檔只告訴你“返回指定鍵所映射的值”但沒(méi)說(shuō)清楚如果鍵不存在返回 null如果鍵存在但值是 null也返回 null。這兩種語(yǔ)義完全不一樣但對(duì)調(diào)用方來(lái)說(shuō)看到的結(jié)果都是 null。這就導(dǎo)致你沒(méi)法通過(guò)返回值判斷“到底是沒(méi)這個(gè)鍵還是這個(gè)鍵的值就是 null”。再比如SimpleDateFormat.parse()方法解析失敗會(huì)拋ParseException但I(xiàn)nteger.parseInt()解析失敗卻拋NumberFormatException。同樣是“解析”語(yǔ)義異常類型都不統(tǒng)一調(diào)用方被迫分別處理。這種接口設(shè)計(jì)的不一致讓 Java 程序員養(yǎng)成了“凡是外部傳入的對(duì)象一律先判空再說(shuō)”的習(xí)慣。于是判空代碼像牛皮癬一樣貼滿了整個(gè)項(xiàng)目。明白這個(gè)背景你就知道為什么后面要引入Optional和一堆工具類來(lái)“補(bǔ)救”了。2. 從青銅到王者判空寫法的演進(jìn)路線2.1 青銅時(shí)代層層嵌套的 if 判空最原始的判空寫法我稱之為“套娃式判空”。每個(gè)對(duì)象在訪問(wèn)屬性之前都得先來(lái)一道防線防完一層還有一層代碼縮進(jìn)像梯田一樣。public String getFullAddress(User user) { if (user ! null) { Address address user.getAddress(); if (address ! null) { String detail address.getDetail(); if (detail ! null !detail.isEmpty()) { return detail; } } } return 未知地址; }這種寫法的問(wèn)題不只是丑更致命的是漏判。你永遠(yuǎn)記不清哪個(gè)對(duì)象在前面已經(jīng)判過(guò)了哪個(gè)還沒(méi)判。改需求的時(shí)候往里加一個(gè)新的鏈?zhǔn)秸{(diào)用很容易忘了加判空線上直接 NPE。我相信每個(gè) Java 程序員都有過(guò)“代碼跑得好好的換了個(gè)數(shù)據(jù)就空指針”的慘痛經(jīng)歷。另外這種寫法把業(yè)務(wù)邏輯和防御邏輯混在一起。讀代碼的人要在一堆if (xxx ! null)的包圍中尋找真正干活的邏輯心智負(fù)擔(dān)極重。這就是為什么后來(lái)大家開(kāi)始用工具類。2.2 白銀時(shí)代工具類的集中收編到了白銀時(shí)代大家開(kāi)始用 Apache Commons、Guava 這類工具庫(kù)把判空邏輯收編起來(lái)。StringUtils.isBlank()、CollectionUtils.isEmpty()這類方法的好處是把 null 和“空”統(tǒng)一處理你不用再寫str ! null !str.isEmpty()這種又臭又長(zhǎng)的復(fù)合條件。public boolean isValidName(String name) { return StringUtils.isNotBlank(name); } public boolean hasOrders(ListOrder orders) { return !CollectionUtils.isEmpty(orders); }我個(gè)人對(duì)工具類判空的態(tài)度是該用就用但心里得有數(shù)。這些方法本質(zhì)上還是“判斷”只是把判斷條件簡(jiǎn)化了。它解決的是“寫得短”的問(wèn)題沒(méi)有解決“沒(méi)值怎么辦”的問(wèn)題。真正讓判空從“防崩潰”升級(jí)到“表達(dá)業(yè)務(wù)”的是 Optional 的出現(xiàn)。2.3 黃金時(shí)代Optional 帶來(lái)的思維轉(zhuǎn)變Optional是 Java 8 帶來(lái)的禮物。它最厲害的地方不是省了幾行代碼而是把“可能沒(méi)值”這件事顯式地寫進(jìn)了方法的返回類型里。一個(gè)方法返回OptionalString就是在告訴你調(diào)用方你注意了我這個(gè)方法可能給不了你值你自己看著辦。這種“契約顯式化”是判空歷史上最大的進(jìn)步——你不再需要通過(guò)閱讀源碼、猜測(cè)實(shí)現(xiàn)來(lái)推斷返回值是否可能為 null。public OptionalAddress getDefaultAddress(User user) { return Optional.ofNullable(user) .map(User::getAddress) .filter(address - address.isDefault()); }我還特別喜歡 Optional 的orElse系列方法因?yàn)樗选皼](méi)值怎么辦”直接內(nèi)聯(lián)到了取值邏輯里業(yè)務(wù)表達(dá)非常清晰User user userRepository.findById(userId).orElseThrow(() - new UserNotFoundException(userId)); String city user.getAddress().map(Address::getCity).orElse(未知城市);到了這一步判空不再是防御性的“檢查”而是業(yè)務(wù)邏輯的一部分。這就是“優(yōu)雅”的真正含義——不是花哨的語(yǔ)法而是讓代碼自己把意圖講清楚。3. 實(shí)操利器每天都能用的優(yōu)雅判空方案3.1 字符串判空isBlank 與 isEmpty 的天壤之別字符串判空是最常見(jiàn)的場(chǎng)景。很多老代碼還在用str ! null !str.isEmpty()而 Java 11 之后JDK 原生就提供了String.isBlank()方法。這倆差別太大了我單獨(dú)列個(gè)表給你看輸入值isEmpty()isBlank()truetrue 純空格falsetrue\t\n制表符、換行falsetrue a falsefalseisEmpty()只判斷“字符串長(zhǎng)度是否為 0”但用戶輸入經(jīng)常是那種看著像空、實(shí)際塞了一堆空格的情況。比如注冊(cè)表單里的用戶名用戶手滑敲了幾個(gè)空格isEmpty()判斷通過(guò)結(jié)果存進(jìn)數(shù)據(jù)庫(kù)的是 后面做查詢匹配時(shí)怎么都匹配不上。所以我現(xiàn)在的習(xí)慣是凡是用戶輸入、外部傳入的字符串一律用isBlank()判斷直接過(guò)濾掉純空白字符的情況。只有那種對(duì)空字符串語(yǔ)義有特殊要求的場(chǎng)景比如你明確區(qū)分“沒(méi)填”和“填了空格”才會(huì)用isEmpty()。如果你還在用 Java 8沒(méi)法用isBlank()我建議寫一個(gè)工具方法收編這種邏輯public static boolean isBlank(String str) { return str null || str.trim().isEmpty(); }注意這里用str.trim()而不是str.strip()因?yàn)?Java 8 的trim()已經(jīng)夠用而且strip()是 Java 11 才有的。工具方法的好處是以后項(xiàng)目升級(jí)到 Java 11你只需要改這一個(gè)方法的實(shí)現(xiàn)全項(xiàng)目受益。3.2 集合判空別再寫 list ! null list.size() 0集合判空也是重災(zāi)區(qū)。我見(jiàn)過(guò)太多這種寫法if (list ! null list.size() 0) { // do something }這行代碼有三個(gè)問(wèn)題一是list ! null很啰嗦二是size() 0不如!isEmpty()語(yǔ)義清晰三是如果集合是從某個(gè)查詢結(jié)果轉(zhuǎn)換來(lái)的你其實(shí)更應(yīng)該保證它“非 null 但可能為空”而不是每次用的時(shí)候都提心吊膽。我建議兩個(gè)方向第一用工具類收編判斷邏輯。Spring 的CollectionUtils.isEmpty()、Apache Commons 的CollectionUtils.isEmpty()都能同時(shí)處理 null 和空集合。第二從源頭消滅 null 集合。如果你的代碼是自己創(chuàng)建的集合永遠(yuǎn)不要讓變量為 null。初始化時(shí)用Collections.emptyList()、Collections.emptySet()、Collections.emptyMap()或者 Java 9 直接用List.of()、Map.of()。這些方法返回的是不可變空集合既能安全遍歷又不會(huì)因?yàn)楹罄m(xù)誤操作add而報(bào)錯(cuò)。// 推薦返回空集合而不是 null public ListString getTags() { if (tagStore.isEmpty()) { return Collections.emptyList(); } return tagStore.getTags(); } // 調(diào)用方不需要再判空直接遍歷 ListString tags getTags(); for (String tag : tags) { System.out.println(tag); }這個(gè)習(xí)慣養(yǎng)成之后你的代碼里 null 集合會(huì)越來(lái)越少判空的需求自然也就少了。3.3 對(duì)象判空requireNonNull、Optional 與防御式拷貝對(duì)象判空分兩種場(chǎng)景一種是參數(shù)校驗(yàn)另一種是鏈?zhǔn)秸{(diào)用。參數(shù)校驗(yàn)的最佳實(shí)踐是Objects.requireNonNull()這個(gè)方法本身就是為“快速失敗”設(shè)計(jì)的。在構(gòu)造函數(shù)或方法入口處明確要求某個(gè)參數(shù)不能為 null如果為 null 直接拋NullPointerException并帶著自定義的錯(cuò)誤信息public class UserService { private final UserRepository userRepository; public UserService(UserRepository userRepository) { this.userRepository Objects.requireNonNull(userRepository, userRepository must not be null); } }這樣做的意義在于盡早暴露問(wèn)題。如果你不在構(gòu)造函數(shù)校驗(yàn)等用userRepository的時(shí)候才發(fā)現(xiàn)為 null那時(shí)候的調(diào)用棧已經(jīng)隔了好幾層排查成本高得多。鏈?zhǔn)秸{(diào)用場(chǎng)景我強(qiáng)烈推薦Optional加方法引用的組合String phone Optional.ofNullable(user) .map(User::getProfile) .map(Profile::getPhone) .orElse(未綁定手機(jī)號(hào));這段代碼的優(yōu)雅之處在于它把每一層可能出現(xiàn)的 null 都隱式處理了。map()內(nèi)部會(huì)自動(dòng)包裝如果前一步的結(jié)果是 null后續(xù)的map操作直接跳過(guò)最后落到orElse的默認(rèn)值上。你不用再關(guān)心哪一層是 null只需要關(guān)心“最終沒(méi)有值的話怎么辦”。不過(guò)我要提一個(gè)細(xì)節(jié)鏈?zhǔn)秸{(diào)用的層級(jí)不要太深。如果user - profile - phone - ...要經(jīng)過(guò)五六層map代碼可讀性會(huì)急劇下降同事看了也難受。遇到超過(guò)三層的鏈?zhǔn)秸{(diào)用我一般會(huì)拆成中間變量 提前判空結(jié)合的寫法或者用局部變量承接中間結(jié)果保證“鏈?zhǔn)絻?yōu)雅但不失清晰”。另外還有一道“免死金牌”就是 Spring 的Nullable和NonNull注解配合 IDE 的注解檢查。標(biāo)注好參數(shù)和返回值是否可能為 nullIDE 會(huì)在代碼里給你波浪線提示等于把判空從運(yùn)行時(shí)提前到了編譯期。這個(gè)我后面細(xì)說(shuō)。4. 那些年我們踩過(guò)的判空大坑4.1 Optional 是銀彈嗎濫用 Optional 的翻車現(xiàn)場(chǎng)Optional確實(shí)優(yōu)雅但它不是靈丹妙藥。我見(jiàn)過(guò)項(xiàng)目把 Optional 用歪了越寫越痛苦的總結(jié)下來(lái)有三個(gè)常見(jiàn)的“翻車現(xiàn)場(chǎng)”。第一把 Optional 當(dāng) if 用。有些人拿到Optional之后不用map、filter這些高階方法反而寫if (opt.isPresent())。這等于把Optional退化成了一顆包裝過(guò)的 null代碼比原生判空還啰嗦// 反面教材Optional 的 ifPresent 不是這么用的 OptionalUser userOpt userService.findById(1L); if (userOpt.isPresent()) { User user userOpt.get(); System.out.println(user.getName()); }這寫法還不如直接判空來(lái)得直白。Optional的價(jià)值在于你可以用map鏈?zhǔn)教幚矶皇亲屇愣喟粚釉俨痖_(kāi)。第二把 Optional 當(dāng)字段用。我見(jiàn)過(guò)有人把實(shí)體類的字段直接定義成OptionalString這是大忌。原因有兩個(gè)一是Optional沒(méi)有被 JDK 設(shè)計(jì)為可序列化很多 ORM 框架和 JSON 序列化框架對(duì)它的支持是殘缺的二是把“可空性”暴露到字段級(jí)別調(diào)用方反而不知道該不該判空了。正確的姿勢(shì)是字段保持原樣在 getter 返回值上使用Optional。第三忽視 Optional 本身的性能開(kāi)銷。每次調(diào)用Optional.ofNullable都會(huì)創(chuàng)建一個(gè)新對(duì)象在高頻調(diào)用鏈路上確實(shí)有微小的開(kāi)銷。這種開(kāi)銷平時(shí)可以忽略不計(jì)但如果你在一個(gè)每秒執(zhí)行幾萬(wàn)次的循環(huán)里用Optional包對(duì)象性能影響會(huì)被放大。我一般建議循環(huán)體內(nèi)少用 Optional優(yōu)先用本地變量 判空。4.2 判空速度之爭(zhēng)宏觀性能與微觀性能的取舍說(shuō)到性能我得聊聊一個(gè)常見(jiàn)的誤區(qū)。很多人糾結(jié)str.isEmpty()和str.length() 0哪個(gè)更快糾結(jié)list.size() 0和list.isEmpty()哪個(gè)性能好——說(shuō)實(shí)話這些差異在宏觀性能面前可以忽略不計(jì)。真正影響性能的是“判空之后的執(zhí)行路徑”。比如一個(gè)查詢接口入庫(kù)數(shù)據(jù)判定為 null 后你是直接返回空結(jié)果還是走異常拋出流程異常拋出的成本極高因?yàn)?JVM 要填充完整調(diào)用棧能避免就避免。所以我的實(shí)際經(jīng)驗(yàn)是能用返回空集合解決的問(wèn)題不要用異常表達(dá)“無(wú)數(shù)據(jù)”。另一個(gè)性能相關(guān)的點(diǎn)很多人沒(méi)意識(shí)到判空太晚比判空太早的代價(jià)更高。一個(gè)訂單詳情接口你先查出訂單再查訂單項(xiàng)再查物流信息最后才發(fā)現(xiàn)用戶沒(méi)傳訂單號(hào)要拋異?！懊嫠胁樵兌及鬃隽藬?shù)據(jù)庫(kù)白白承受了壓力。正確的做法是在接口入口處把參數(shù)校驗(yàn)做完凡是必要條件不滿足直接 fail fast不要等到業(yè)務(wù)邏輯深處再發(fā)現(xiàn)不對(duì)勁。4.3 最容易忽略的“偽判空”空對(duì)象、空字符串、空白字符串最后一個(gè)大坑是“偽判空”。很多人以為判空就是! null但在實(shí)際業(yè)務(wù)中很多值雖然“不為 null”卻依然是無(wú)意義的。最典型的場(chǎng)景是數(shù)據(jù)庫(kù)字段。一個(gè)字段在數(shù)據(jù)庫(kù)里可能存的是NULL也可能存的是空字符串甚至可能存的是 幾個(gè)空格。這三種值在 Java 層面做! null判斷時(shí)只有第一種會(huì)命中后兩種都被當(dāng)成“有值”。結(jié)果就是代碼邏輯走上了一個(gè)意想不到的分支查了半天才發(fā)現(xiàn)問(wèn)題是“這個(gè)字段不是 null但它是個(gè)空格”。我之前做過(guò)一個(gè)數(shù)據(jù)清洗的需求用戶上傳的 CSV 文件里很多單元格看起來(lái)是空的實(shí)際讀進(jìn)來(lái)是或者 。如果只用! null判斷這些“臟值”就會(huì)被當(dāng)成有效數(shù)據(jù)入庫(kù)。后來(lái)我把所有入口字段統(tǒng)一走isBlank()校驗(yàn)才徹底解決。所以我的核心建議是判空之前先想清楚“這個(gè)值的合法形態(tài)是什么”。是 null 才叫空還是 null、空串、空白串都叫空如果是后者請(qǐng)務(wù)必使用isBlank()這種能一次性覆蓋所有空形態(tài)的方法。5. 團(tuán)隊(duì)落地經(jīng)驗(yàn)如何讓全組的判空變得一致優(yōu)雅5.1 約定優(yōu)于配置判空規(guī)范清單文章寫到這里我更想說(shuō)點(diǎn)團(tuán)隊(duì)層面的東西。判空寫得優(yōu)雅不優(yōu)雅不完全是個(gè)人技術(shù)問(wèn)題還跟團(tuán)隊(duì)有沒(méi)有統(tǒng)一的規(guī)范強(qiáng)相關(guān)。我待過(guò)幾個(gè)項(xiàng)目組總結(jié)出一份比較實(shí)用的判空規(guī)范清單分享給你參考場(chǎng)景規(guī)范要求推薦寫法外部傳入字符串參數(shù)統(tǒng)一按 blank 處理StringUtils.isBlank(str)方法返回值集合一律返回空集合不返回 nullCollections.emptyList()構(gòu)造函數(shù)必需參數(shù)使用快速失敗Objects.requireNonNull(param)鏈?zhǔn)秸{(diào)用多級(jí)對(duì)象用 Optional 表達(dá)可能缺失Optional.ofNullable(...).map(...)實(shí)體類字段不在字段上用 Optional僅 getter 返回 Optional循環(huán)體內(nèi)判斷優(yōu)先本地變量避免 Optional 包裝if (item ! null)規(guī)范定好之后剩下的就是靠工具和 code review 來(lái)執(zhí)行。沒(méi)有規(guī)范的時(shí)候每個(gè)人按自己的習(xí)慣寫代碼庫(kù)里就會(huì)出現(xiàn)“同一個(gè)意思三種寫法”的情況有人用StringUtils.isBlank有人用s null || s.isEmpty()還有人用.equals(s)。這不是風(fēng)格偏好問(wèn)題而是維護(hù)成本的隱患——后來(lái)的人閱讀代碼時(shí)每一種寫法都得在腦子里重新翻譯一遍。定規(guī)范的時(shí)候讓全組討論是有價(jià)值的因?yàn)槟銜?huì)發(fā)現(xiàn)每個(gè)人都有自己的“慣性寫法”。比如有人特別喜歡用.equals(str)理由是這樣的寫法天然避免了 str 為 null 時(shí)調(diào)用equals可能出現(xiàn)的 NPE。這個(gè)理由我認(rèn)可但如果全項(xiàng)目都規(guī)范用StringUtils.isBlank那.equals這種寫法就沒(méi)必要保留了——統(tǒng)一一個(gè)入口統(tǒng)一一種表達(dá)。5.2 靜態(tài)檢查與 CR 要點(diǎn)從制度上消滅低級(jí)判空規(guī)范定完就要靠工具強(qiáng)制執(zhí)行不然寫代碼的激情一上來(lái)什么規(guī)范都會(huì)忘。靜態(tài)檢查是繞不開(kāi)的。我比較推薦在項(xiàng)目里引入 SpotBugs或者說(shuō)它的前身 FindBugs 的繼任者。SpotBugs 有兩個(gè)跟判空強(qiáng)相關(guān)的檢測(cè)器NP_NULL_ON_SOME_PATH能識(shí)別出“某個(gè)引用在某條路徑上可能為 null但你沒(méi)有判空就調(diào)用了它的方法”RCN_REDUNDANT_NULLCHECK_OF_NONNULL_VALUE能識(shí)別出“你寫了一個(gè)多余的判空但這個(gè)值根本不可能是 null”。前者幫你堵住 NPE 的漏網(wǎng)之魚后者幫你清理無(wú)效代碼。兩個(gè)都開(kāi)著代碼的判空質(zhì)量會(huì)肉眼可見(jiàn)地提升。SonarQube 的檢查規(guī)則里我特別建議打開(kāi)S2259空指針解引用檢測(cè)和S1168返回空數(shù)組/空集合而不是 null。項(xiàng)目有一定規(guī)模之后這些規(guī)則能避免不少線上事故。Code Review 方面我一般盯著三個(gè)點(diǎn)看。第一新寫的代碼是否在“沒(méi)有值”的情況下有明確策略——是返回默認(rèn)值、拋異常還是跳過(guò)邏輯不能默默吞掉。第二嵌套 if 超過(guò)三層就要提醒拆方法——就算判空邏輯是對(duì)的三層嵌套的可讀性也基本廢了。第三集合操作優(yōu)先用 stream 和 Optional 的鏈?zhǔn)奖磉_(dá)——能一行結(jié)束的不要寫成五行的 for 循環(huán)加 if 判斷。最后說(shuō)一個(gè)很多人忽視的點(diǎn)單元測(cè)試不要只測(cè)“有值”的 happy pathnull 和空值的用例至少各加一個(gè)。我自己吃過(guò)虧——報(bào)文解析模塊測(cè)了一大堆正常返回的用例結(jié)果一上線第一個(gè) null 請(qǐng)求就把服務(wù)打掛了。從那以后我養(yǎng)成了一個(gè)習(xí)慣凡是寫了判空邏輯的地方一定補(bǔ)一個(gè)“空值輸入”的測(cè)試用例。這樣才能保證你的判空在重構(gòu)之后仍然活著而不是被某個(gè)優(yōu)化順手刪了。說(shuō)到重構(gòu)我想提醒一下用Optional重構(gòu)老代碼時(shí)不要大面積替換。一次只動(dòng)一個(gè)模塊改完跑完整測(cè)試再動(dòng)下一個(gè)。我見(jiàn)過(guò)團(tuán)隊(duì)一個(gè)周末把全項(xiàng)目的判空全部換成 Optional結(jié)果周一上線炸了一片——有些老代碼里get()方法返回的 null 是有特殊語(yǔ)義的被Optional一包反而把語(yǔ)義搞丟了。6. 寫在最后優(yōu)雅判空背后的邏輯回到標(biāo)題說(shuō)的“別人家的判空”。說(shuō)到底別人家的判空之所以優(yōu)雅不是因?yàn)橛昧硕嗬溟T的 API也不是因?yàn)殪偶及愕赜昧?Optional 鏈?zhǔn)秸{(diào)用而是因?yàn)樗麄兿肭宄嗣總€(gè)變量“可能沒(méi)有值”時(shí)的應(yīng)對(duì)策略。我的體會(huì)是判空代碼寫得越多越說(shuō)明系統(tǒng)設(shè)計(jì)有問(wèn)題。合理的設(shè)計(jì)應(yīng)該是接口契約清晰、返回值有明確約束、參數(shù)不允許為 null 的在入口就失敗。判空是防御但防御不能靠到處撒網(wǎng)而是靠邊界上的關(guān)卡。我也知道現(xiàn)實(shí)項(xiàng)目里的老代碼不可能一夜之間全部重寫。所以我的建議是從今天開(kāi)始新寫的代碼里嘗試用isBlank()替代isEmpty()用返回空集合替代返回 null用Optional表達(dá)可能缺失的返回值。哪怕只是先改一兩個(gè)方法你也會(huì)慢慢感受到這種寫法的清爽。等積累到一定程度你回頭看之前寫的那些 if 套娃會(huì)忍不住感慨原來(lái)判空這件事真的可以做得這么干凈。