Kotlin 的 if-else 要縮短了：onTrue、onFalse、ifOrNull 三個新函式在做什麼

先交代事件日期。2026 年 11 月，一篇發表於掘金的技術文章整理了 Kotlin 2.5.0-Beta2 中的三個實驗性標準庫函數：onTrue()、onFalse() 與 ifOrNull()。它們已在 2.5.0-Beta1 的發布記錄中列出，目的是減少重複的 if-else 表達式，讓一些常見寫法更容易讀。這不是正式版功能，仍需以 @OptIn(ExperimentalStdlibApi::class) 明確 opt-in 才能使用，但方向值得開發者先看懂。

傳統 if-else 卡在哪裡

用一個 Android 登入頁面當例子。驗證完使用者憑證後，想根據成敗記錄日誌，過去大概會這樣寫：先算出一個 isAuthenticated 布林值，再用 if-else 分別呼叫 logSuccess 或 logFailure，最後把布林值回傳。

這段程式沒有錯，也早已是大家熟悉的形狀。真正的問題是「重複」。當同樣的模式，根據布林結果做點事、然後原封不動把布林值傳下去，在日誌、埋點、輕量提示、回呼觸發這類場景裡反覆出現時，每個呼叫點都要重寫一次 if-else 的骨架。

三個函數各自處理什麼

onTrue() 和 onFalse() 是一對。onTrue() 只有在布林值為 true 時執行傳入的 lambda，值為 false 時什麼都不做，然後回傳原本的布林值。onFalse() 剛好相反。接在一起之後，前述的登入函數可以改寫成：verifyToken 的結果直接接上 .onTrue { 記成功日誌 }.onFalse { 記失敗日誌 }，最後回傳那個布林值。

有點像處理 Result 時的慣用鏈式寫法：值沿著管線流動，副作用掛在旁邊。關鍵性質是這兩個函數不會改變布林值本身，它們是處理副作用的，不是做轉換的。

ifOrNull() 處理另一種重複：條件成立時取某個值，不成立時給 null。以前要寫成 val phoneNumber = if (user.hasContactInfo) user.phoneNumber else null，現在可以寫成 ifOrNull(user.hasContactInfo) { user.phoneNumber }。條件為 false 時 lambda 不會執行，直接回傳 null。典型場景是 API 回傳的用戶資料裡，聯絡資訊可有可無，只有存在時才取出電話號碼。

語法糖的取捨

語法糖向來有兩派意見。一派認為少打幾行程式碼、讀起來更像自然語言是淨收益；另一派認為每多一種寫法，團隊的程式碼風格就多一種分歧的可能，if-else 大家都看得懂，何必再學。這三個函數目前是實驗性 API，正式介面仍可能調整，這本身就是官方留下的緩衝。

值得注意的訊號是趨勢面。原文名作者觀察到，現代語言在語法糖上的一個共同方向，是支援更多鏈式呼叫的寫法。這與近期開發圈對Vibe coding 工具分工邏輯的討論有些呼應：當程式碼愈來愈常由 AI 生成、由人審閱，緊湊且語意集中的表達式，往往比散開的多行區塊更容易被快速核對。

實務上的判斷

什麼時候適合用？依來源整理，判斷標準其實只有一條：如果只是根據 Boolean 執行動作，並保留原本的布林結果，onTrue() 與 onFalse() 就在候選名單上；如果是要「條件成立才有值、否則為 null」，用 ifOrNull()。反過來說，需要把布林值轉換成其他型別的邏輯，仍屬於 if-else 或 when 的領域。

對日常寫 Android 或後端 Kotlin 的人來說，這三個函數短期內不會改變任何專案的架構，但等 2.5.0 正式版定案後，code review 時可能會開始看到同事用它們。先知道語意，到時候就不必停下來查文件。