用了三年 Flow，還想設計 Callback：一句提議背後，是技術替代卡在習慣那一關

2026年10月28日，開發者「潛龍勿用之化骨龍」在掘金發表〈現代 Android 架構指南：不要再主動設計 Callback 介面〉。文章的起點是一個內部場景：專案已完全協程化，Flow 也用了三年，一位工作十年、同樣用了三年 Flow 的同事，在討論一個持續接收資料的介面時提議「我們設計一個回呼介面吧」。

作者的核心主張很收斂：對應用內部的業務介面與資料存取介面，不要把 Callback 當作預設設計。一次性操作優先使用 suspend 函數，持續資料優先考慮 Flow 體系。這不是要消滅 Callback，而是要改變設計介面時的第一反應。

一篇單人閱讀量九分鐘的技術長文，值得用產業觀察的角度重讀一次，因為它記錄的是技術替代曲線上一個常被忽略的段落：工具已經換完，習慣還沒跟上。

結構拆解：一次性操作與持續資料流的分界

文章的技術判準只有一條線：操作語義。

操作最終回傳單一結果，例如載入一則訊息、送出訂單、查詢車輛資訊，用 suspend 函數表達。呼叫端需要持續接收資料變化，例如不斷到來的訊息、車輛檔位變化、網路狀態，用 Flow 表達。作者引述 Android 官方協程最佳實踐的建議：資料層與業務層用 suspend 函數執行一次性操作，用 Flow 通知資料變化。

值得注意的是作者自己劃出的界線：Flow 並不只適用於無限資料流，有限資料序列同樣可以表達；要做的也不是把所有介面都改成 Flow，而是按操作語義選介面。

這條分界線之所以重要，在於它直接對應兩種截然不同的維護成本結構。

成本結構：Callback 那一套，貴在哪一欄

按文章描述，習慣性設計 Callback 意味著每次遇到持續資料，工程師要寫的是四件套：一個 Listener 介面、一個註冊方法、一個註銷方法、再加上回呼執行緒處理與監聽器生命週期管理。

這四件套的帳要記在兩處。一是程式碼量本身，每多一個資料源就多一套介面定義與管理邏輯。二是認知負擔，呼叫端必須理解註冊時機、註銷時機與執行緒語義，這些都不是業務呼叫方真正關心的內容。呼叫方關心的是要消費什麼資料、資料代表什麼。

換成 observeMessages(): Flow<Message> 這種形式，註冊與註銷的責任移交給 Flow 的收集機制，呼叫端不直接依賴 Listener 型別與註冊方式。用成本結構的語言說，這是把生命週期管理從每個呼叫端複製一份，收斂為框架層集中支付一次。

作者同時劃出 Callback 仍然正當的範圍：Android 系統 API、第三方 SDK、許多底層框架都在用，底層 API 使用 Callback，不代表應用內部必須跟進。換言之，這篇文章談的是應用內部介面的設計慣性，而非對既有生態的批判。

影響推演：誰付帳，誰受惠

傳導鏈其實很短。受壓的是工程團隊的長期維護成本：當協程化專案裡仍混雜自建 Callback 體系，兩套非同步模型並存，新進工程師要同時理解兩種心智模型，code review 的判準也會分裂。作者那句「技術分享不等於設計習慣真的改變了」，說的正是這種分裂在組織內的滯留時間。

受惠端有兩層。近端是採用 Kotlin 協程的團隊本身，介面語義統一後，suspend 對應一次性、Flow 對應串流，設計決策從逐案討論降為可複製的規則。遠端是 Google 的開發者生態，官方最佳實踐被更多團隊內化為預設選項，框架與語言的開發者體驗投資才真正落到使用端。

這與我們先前分析的Android Intent 傳值背後的記憶體哲學帳屬於同一類問題：平臺在 API 層做的設計取捨，最終都要由應用開發者以學習成本與維護成本的形式結帳，差別只在於結帳的是哪一欄。

收束判斷

技術替代曲線通常被畫成工具採用率的問題，這篇文章記錄的卻是曲線的後半段：工具到位之後，組織內設計習慣的遷移可以比工具本身慢上數年。一位用了三年 Flow 的資深工程師仍以 Callback 為第一反應，說明採用率數字掩蓋了習慣存量的規模。

文章可核實的部分到此為止：技術判準引述官方最佳實踐，成本分析基於作者描述的專案場景。至於這種習慣遷移在整個 Android 開發者族羣中處於哪個階段，來源沒有提供調查數據，本文不代為推算。可以確定的是，這類「工具換完、習慣未換」的帳，在每一次主流技術棧輪替時都會再出現一次。