寫(xiě)Java這幾年我有個(gè)特別深的感觸代碼寫(xiě)得好不好不看功能多花哨先看判空寫(xiě)得干不干凈。前兩天在群里看到一段同事分享的代碼用Optional加方法引用把原本七八行的if嵌套壓縮成了兩行鏈?zhǔn)秸{(diào)用行云流水。底下評(píng)論區(qū)一片“別人家的代碼從不讓人失望”。說(shuō)真的判空這個(gè)動(dòng)作每個(gè)Java開(kāi)發(fā)每天都要寫(xiě)十幾次但絕大多數(shù)人寫(xiě)的都是最原始的if (xxx ! null)堆在一起又臭又長(zhǎng)。這篇文章我就想跟你聊聊判空到底該怎么寫(xiě)才優(yōu)雅優(yōu)雅的背后又是什么邏輯。1. 判空到底在判什么先搞清楚問(wèn)題的本質(zhì)1.1 你以為的判空和真正的判空很多人一提到判空第一反應(yīng)就是“防止空指針異常”。這話(huà)沒(méi)毛病但只說(shuō)對(duì)了一半。判空真正要解決的是一個(gè)值可能不存在時(shí)你的程序該如何優(yōu)雅地繼續(xù)下去。舉個(gè)例子用戶(hù)下單時(shí)要讀取用戶(hù)的默認(rèn)地址。地址可能為空那此時(shí)是拋異常、用備用地址、還是提示用戶(hù)手動(dòng)填寫(xiě)這三種情況的處理邏輯完全不同。所以判空的本質(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ò)誤的用戶(hù)地址都沒(méi)填你應(yīng)該引導(dǎo)用戶(hù)去填寫(xiě)而不是 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ǔ)義異常類(lèi)型都不統(tǒng)一調(diào)用方被迫分別處理。這種接口設(shè)計(jì)的不一致讓 Java 程序員養(yǎng)成了“凡是外部傳入的對(duì)象一律先判空再說(shuō)”的習(xí)慣。于是判空代碼像牛皮癬一樣貼滿(mǎn)了整個(gè)項(xiàng)目。明白這個(gè)背景你就知道為什么后面要引入Optional和一堆工具類(lèi)來(lái)“補(bǔ)救”了。2. 從青銅到王者判空寫(xiě)法的演進(jìn)路線(xiàn)2.1 青銅時(shí)代層層嵌套的 if 判空最原始的判空寫(xiě)法我稱(chēng)之為“套娃式判空”。每個(gè)對(duì)象在訪(fǎng)問(wèn)屬性之前都得先來(lái)一道防線(xiàn)防完一層還有一層代碼縮進(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 未知地址; }這種寫(xiě)法的問(wèn)題不只是丑更致命的是漏判。你永遠(yuǎn)記不清哪個(gè)對(duì)象在前面已經(jīng)判過(guò)了哪個(gè)還沒(méi)判。改需求的時(shí)候往里加一個(gè)新的鏈?zhǔn)秸{(diào)用很容易忘了加判空線(xiàn)上直接 NPE。我相信每個(gè) Java 程序員都有過(guò)“代碼跑得好好的換了個(gè)數(shù)據(jù)就空指針”的慘痛經(jīng)歷。另外這種寫(xiě)法把業(yè)務(wù)邏輯和防御邏輯混在一起。讀代碼的人要在一堆if (xxx ! null)的包圍中尋找真正干活的邏輯心智負(fù)擔(dān)極重。這就是為什么后來(lái)大家開(kāi)始用工具類(lèi)。2.2 白銀時(shí)代工具類(lèi)的集中收編到了白銀時(shí)代大家開(kāi)始用 Apache Commons、Guava 這類(lèi)工具庫(kù)把判空邏輯收編起來(lái)。StringUtils.isBlank()、CollectionUtils.isEmpty()這類(lèi)方法的好處是把 null 和“空”統(tǒng)一處理你不用再寫(xiě)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ì)工具類(lèi)判空的態(tài)度是該用就用但心里得有數(shù)。這些方法本質(zhì)上還是“判斷”只是把判斷條件簡(jiǎn)化了。它解決的是“寫(xiě)得短”的問(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)值”這件事顯式地寫(xiě)進(jìn)了方法的返回類(lèi)型里。一個(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”但用戶(hù)輸入經(jīng)常是那種看著像空、實(shí)際塞了一堆空格的情況。比如注冊(cè)表單里的用戶(hù)名用戶(hù)手滑敲了幾個(gè)空格isEmpty()判斷通過(guò)結(jié)果存進(jìn)數(shù)據(jù)庫(kù)的是 后面做查詢(xún)匹配時(shí)怎么都匹配不上。所以我現(xiàn)在的習(xí)慣是凡是用戶(hù)輸入、外部傳入的字符串一律用isBlank()判斷直接過(guò)濾掉純空白字符的情況。只有那種對(duì)空字符串語(yǔ)義有特殊要求的場(chǎng)景比如你明確區(qū)分“沒(méi)填”和“填了空格”才會(huì)用isEmpty()。如果你還在用 Java 8沒(méi)法用isBlank()我建議寫(xiě)一個(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 集合判空別再寫(xiě) list ! null list.size() 0集合判空也是重災(zāi)區(qū)。我見(jiàn)過(guò)太多這種寫(xiě)法if (list ! null list.size() 0) { // do something }這行代碼有三個(gè)問(wèn)題一是list ! null很啰嗦二是size() 0不如!isEmpty()語(yǔ)義清晰三是如果集合是從某個(gè)查詢(xún)結(jié)果轉(zhuǎn)換來(lái)的你其實(shí)更應(yīng)該保證它“非 null 但可能為空”而不是每次用的時(shí)候都提心吊膽。我建議兩個(gè)方向第一用工具類(lèi)收編判斷邏輯。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)有值的話(huà)怎么辦”。不過(guò)我要提一個(gè)細(xì)節(jié)鏈?zhǔn)秸{(diào)用的層級(jí)不要太深。如果user - profile - phone - ...要經(jīng)過(guò)五六層map代碼可讀性會(huì)急劇下降同事看了也難受。遇到超過(guò)三層的鏈?zhǔn)秸{(diào)用我一般會(huì)拆成中間變量 提前判空結(jié)合的寫(xiě)法或者用局部變量承接中間結(jié)果保證“鏈?zhǔn)絻?yōu)雅但不失清晰”。另外還有一道“免死金牌”就是 Spring 的Nullable和NonNull注解配合 IDE 的注解檢查。標(biāo)注好參數(shù)和返回值是否可能為 nullIDE 會(huì)在代碼里給你波浪線(xiàn)提示等于把判空從運(yùn)行時(shí)提前到了編譯期。這個(gè)我后面細(xì)說(shuō)。4. 那些年我們踩過(guò)的判空大坑4.1 Optional 是銀彈嗎濫用 Optional 的翻車(chē)現(xiàn)場(chǎng)Optional確實(shí)優(yōu)雅但它不是靈丹妙藥。我見(jiàn)過(guò)項(xiàng)目把 Optional 用歪了越寫(xiě)越痛苦的總結(jié)下來(lái)有三個(gè)常見(jiàn)的“翻車(chē)現(xiàn)場(chǎng)”。第一把 Optional 當(dāng) if 用。有些人拿到Optional之后不用map、filter這些高階方法反而寫(xiě)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()); }這寫(xiě)法還不如直接判空來(lái)得直白。Optional的價(jià)值在于你可以用map鏈?zhǔn)教幚矶皇亲屇愣喟粚釉俨痖_(kāi)。第二把 Optional 當(dāng)字段用。我見(jiàn)過(guò)有人把實(shí)體類(lèi)的字段直接定義成OptionalString這是大忌。原因有兩個(gè)一是Optional沒(méi)有被 JDK 設(shè)計(jì)為可序列化很多 ORM 框架和 JSON 序列化框架對(duì)它的支持是殘缺的二是把“可空性”暴露到字段級(jí)別調(diào)用方反而不知道該不該判空了。正確的姿勢(shì)是字段保持原樣在 getter 返回值上使用Optional。第三忽視 Optional 本身的性能開(kāi)銷(xiāo)。每次調(diào)用Optional.ofNullable都會(huì)創(chuàng)建一個(gè)新對(duì)象在高頻調(diào)用鏈路上確實(shí)有微小的開(kāi)銷(xiāo)。這種開(kāi)銷(xiāo)平時(shí)可以忽略不計(jì)但如果你在一個(gè)每秒執(zhí)行幾萬(wàn)次的循環(huán)里用Optional包對(duì)象性能影響會(huì)被放大。我一般建議循環(huán)體內(nèi)少用 Optional優(yōu)先用本地變量 判空。4.2 判空速度之爭(zhēng)宏觀(guān)性能與微觀(guān)性能的取舍說(shuō)到性能我得聊聊一個(gè)常見(jiàn)的誤區(qū)。很多人糾結(jié)str.isEmpty()和str.length() 0哪個(gè)更快糾結(jié)list.size() 0和list.isEmpty()哪個(gè)性能好——說(shuō)實(shí)話(huà)這些差異在宏觀(guān)性能面前可以忽略不計(jì)。真正影響性能的是“判空之后的執(zhí)行路徑”。比如一個(gè)查詢(xún)接口入庫(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)用戶(hù)沒(méi)傳訂單號(hào)要拋異?！懊嫠胁樵?xún)都白做了數(shù)據(jù)庫(kù)白白承受了壓力。正確的做法是在接口入口處把參數(shù)校驗(yàn)做完凡是必要條件不滿(mǎ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ù)清洗的需求用戶(hù)上傳的 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ī)范清單文章寫(xiě)到這里我更想說(shuō)點(diǎn)團(tuán)隊(duì)層面的東西。判空寫(xiě)得優(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ī)范要求推薦寫(xiě)法外部傳入字符串參數(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í)體類(lèi)字段不在字段上用 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í)慣寫(xiě)代碼庫(kù)里就會(huì)出現(xiàn)“同一個(gè)意思三種寫(xiě)法”的情況有人用StringUtils.isBlank有人用s null || s.isEmpty()還有人用.equals(s)。這不是風(fēng)格偏好問(wèn)題而是維護(hù)成本的隱患——后來(lái)的人閱讀代碼時(shí)每一種寫(xiě)法都得在腦子里重新翻譯一遍。定規(guī)范的時(shí)候讓全組討論是有價(jià)值的因?yàn)槟銜?huì)發(fā)現(xiàn)每個(gè)人都有自己的“慣性寫(xiě)法”。比如有人特別喜歡用.equals(str)理由是這樣的寫(xiě)法天然避免了 str 為 null 時(shí)調(diào)用equals可能出現(xiàn)的 NPE。這個(gè)理由我認(rèn)可但如果全項(xiàng)目都規(guī)范用StringUtils.isBlank那.equals這種寫(xiě)法就沒(méi)必要保留了——統(tǒng)一一個(gè)入口統(tǒng)一一種表達(dá)。5.2 靜態(tài)檢查與 CR 要點(diǎn)從制度上消滅低級(jí)判空規(guī)范定完就要靠工具強(qiáng)制執(zhí)行不然寫(xiě)代碼的激情一上來(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í)別出“你寫(xiě)了一個(gè)多余的判空但這個(gè)值根本不可能是 null”。前者幫你堵住 NPE 的漏網(wǎng)之魚(yú)后者幫你清理無(wú)效代碼。兩個(gè)都開(kāi)著代碼的判空質(zhì)量會(huì)肉眼可見(jiàn)地提升。SonarQube 的檢查規(guī)則里我特別建議打開(kāi)S2259空指針解引用檢測(cè)和S1168返回空數(shù)組/空集合而不是 null。項(xiàng)目有一定規(guī)模之后這些規(guī)則能避免不少線(xiàn)上事故。Code Review 方面我一般盯著三個(gè)點(diǎn)看。第一新寫(xiě)的代碼是否在“沒(méi)有值”的情況下有明確策略——是返回默認(rèn)值、拋異常還是跳過(guò)邏輯不能默默吞掉。第二嵌套 if 超過(guò)三層就要提醒拆方法——就算判空邏輯是對(duì)的三層嵌套的可讀性也基本廢了。第三集合操作優(yōu)先用 stream 和 Optional 的鏈?zhǔn)奖磉_(dá)——能一行結(jié)束的不要寫(xiě)成五行的 for 循環(huán)加 if 判斷。最后說(shuō)一個(gè)很多人忽視的點(diǎn)單元測(cè)試不要只測(cè)“有值”的 happy pathnull 和空值的用例至少各加一個(gè)。我自己吃過(guò)虧——報(bào)文解析模塊測(cè)了一大堆正常返回的用例結(jié)果一上線(xiàn)第一個(gè) null 請(qǐng)求就把服務(wù)打掛了。從那以后我養(yǎng)成了一個(gè)習(xí)慣凡是寫(xiě)了判空邏輯的地方一定補(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é)果周一上線(xiàn)炸了一片——有些老代碼里get()方法返回的 null 是有特殊語(yǔ)義的被Optional一包反而把語(yǔ)義搞丟了。6. 寫(xiě)在最后優(yōu)雅判空背后的邏輯回到標(biāo)題說(shuō)的“別人家的判空”。說(shuō)到底別人家的判空之所以?xún)?yōu)雅不是因?yàn)橛昧硕嗬溟T(mén)的 API也不是因?yàn)殪偶及愕赜昧?Optional 鏈?zhǔn)秸{(diào)用而是因?yàn)樗麄兿肭宄嗣總€(gè)變量“可能沒(méi)有值”時(shí)的應(yīng)對(duì)策略。我的體會(huì)是判空代碼寫(xiě)得越多越說(shuō)明系統(tǒng)設(shè)計(jì)有問(wèn)題。合理的設(shè)計(jì)應(yīng)該是接口契約清晰、返回值有明確約束、參數(shù)不允許為 null 的在入口就失敗。判空是防御但防御不能靠到處撒網(wǎng)而是靠邊界上的關(guān)卡。我也知道現(xiàn)實(shí)項(xiàng)目里的老代碼不可能一夜之間全部重寫(xiě)。所以我的建議是從今天開(kāi)始新寫(xiě)的代碼里嘗試用isBlank()替代isEmpty()用返回空集合替代返回 null用Optional表達(dá)可能缺失的返回值。哪怕只是先改一兩個(gè)方法你也會(huì)慢慢感受到這種寫(xiě)法的清爽。等積累到一定程度你回頭看之前寫(xiě)的那些 if 套娃會(huì)忍不住感慨原來(lái)判空這件事真的可以做得這么干凈。