去年面了17個Flutter候選人，問Clean Architecture能畫對三層結(jié)構(gòu)的不到一半。不是不知道Domain層要獨立，是說不清為什么Data層能依賴Domain，反過來卻不行。

這題其實考的是依賴方向，不是背誦。Robert C. Martin（Uncle Bob）在2012年提出Clean Architecture時，核心就一條規(guī)則：源代碼依賴只能向內(nèi)指向。Domain層是同心圓最內(nèi)層，它不能知道外面任何一層的存在。

但很多人面試時把Repository接口放在Data層，這就是盲區(qū)。接口定義是契約，契約必須由內(nèi)層持有。Data層的Repository實現(xiàn)（Repository Implementation）去依賴Domain層的抽象接口，這才是正確方向。

三層結(jié)構(gòu)的面試陷阱

看一個典型的Flutter項目結(jié)構(gòu)。Domain層包含Entities、Repository抽象接口、Use Cases；Data層放Models、Data Sources、Repository的具體實現(xiàn)；Presentation層管UI、狀態(tài)管理（Bloc/Provider/Riverpod）。

面試常掛的第二個盲區(qū)：Use Case到底是什么？

它不是"調(diào)用API的地方"，而是封裝單一業(yè)務(wù)邏輯的類。每個Use Case只做一件事——獲取用戶資料、更新購物車、驗證優(yōu)惠券。輸入?yún)?shù)和返回類型都要顯式定義，通常用泛型抽象基類統(tǒng)一約束。

第三個盲區(qū)更隱蔽：Error Handling怎么跨層傳遞？

Domain層不能依賴Flutter的http包，也不能用Dio的異常類型。必須自定義Failure類，Data層把技術(shù)異常（DioError、SocketException）映射為業(yè)務(wù)失�。⊿erverFailure、CacheFailure）。Presentation層只認(rèn)識Failure，不認(rèn)識DioError。

為什么Repository必須是抽象接口

講個類比。Domain層是餐廳菜單，Data層是后廚。顧客（Presentation層）點菜只看菜單，不關(guān)心后廚用燃?xì)庠钸�是電磁爐。但菜單本身不能寫"用燃?xì)庠钭?，那是后廚的事。

Repository抽象接口就是菜單上的菜品描述。具體用Firebase還是REST API實現(xiàn)，是Data層的自由。這種隔離讓單元測試能直接Mock Repository，不用啟動真實數(shù)據(jù)庫。

面試時問"為什么要用接口"，答"方便替換實現(xiàn)"只是60分。高分答案是：Domain層定義業(yè)務(wù)需要什么，Data層決定技術(shù)怎么給。需求變更時，改接口是架構(gòu)破壞，改實現(xiàn)是正常迭代。

Dependency Injection的實戰(zhàn)選擇

Flutter社區(qū)主流用get_it配合injectable代碼生成，或者直接用Riverpod的Provider。面試不會問你背API，會問"為什么不用new關(guān)鍵字直接創(chuàng)建對象"。

答案是控制反轉(zhuǎn)（Inversion of Control）。對象生命周期由容器管理，構(gòu)造函數(shù)的依賴由外部注入。這樣測試時可以換Mock實現(xiàn)，生產(chǎn)環(huán)境用真實實現(xiàn)，不用改業(yè)務(wù)代碼。

injectable的好處是編譯時代碼生成，零運行時反射。這在Flutter里很重要，因為反射（dart:mirrors）在Release模式被禁用，會影響包體積和啟動速度。

SOLID原則在Flutter里的具體落地

Single Responsibility：一個Widget只做一件事。不是"登錄頁面"一個文件2000行，而是拆成LoginForm、LoginButton、ErrorMessage三個獨立Widget。

Open/Closed：用擴(kuò)展方法給String加驗證邏輯，而不是改原來的類。Flutter 3.0的extension語法讓這變得干凈。

Liskov Substitution：Bloc的狀態(tài)類設(shè)計。AuthState是基類，AuthLoading、AuthSuccess、AuthError是子類。UI層用switch-case處理，任何子類都能替換基類位置。

Interface Segregation：不要一個Repository接口塞20個方法。按功能拆成UserRepository、OrderRepository、PaymentRepository。調(diào)用方只依賴自己需要的接口。

Dependency Inversion：前面說的Domain層持有接口，Data層實現(xiàn)接口。高層模塊（Use Case）不依賴低層模塊（Dio Client），兩者都依賴抽象。

設(shè)計模式的面試高頻考點

Singleton在Flutter里慎用。GetIt默認(rèn)單例，但BLoC通常用Factory，保證每個頁面獨立狀態(tài)。面試問"Singleton有什么問題"，要答全局狀態(tài)難測試、生命周期難管理。

Factory Pattern的典型場景是平臺適配。創(chuàng)建PlatformChannel時，根據(jù)Platform.isAndroid返回Android實現(xiàn)，iOS返回iOS實現(xiàn)。調(diào)用方無感知。

Observer Pattern就是Flutter的NotificationListener、ScrollNotification，或者BLoC的Stream。面試常問"BLoC和Provider區(qū)別"，本質(zhì)是Observer和InheritedWidget兩種狀態(tài)傳播機(jī)制的差異。

Builder Pattern在Flutter里無處不在。AlertDialog.builder、showModalBottomSheet的builder參數(shù)，都是把構(gòu)造邏輯延遲到需要時執(zhí)行。復(fù)雜對象的 step-by-step 構(gòu)造，避免構(gòu)造函數(shù)參數(shù)爆炸。

Strategy Pattern用于替換算法。圖片加載用CachedNetworkImageStrategy，測試用MockImageStrategy，都實現(xiàn)同一個ImageLoader接口。運行時切換，不用if-else堆邏輯。

Decorator Pattern在Dio的Interceptor里體現(xiàn)。日志攔截器、重試攔截器、Token刷新攔截器，層層包裝原始請求。每個攔截器只加一個職責(zé)，符合Single Responsibility。

Adapter Pattern解決接口不兼容。第三方SDK返回的數(shù)據(jù)結(jié)構(gòu)和你定義的Entity不同，寫個Adapter做字段映射。不是改SDK，也不是改Entity，中間加一層轉(zhuǎn)換。

Command Pattern把請求封裝成對象。Undo/Redo功能、離線操作的隊列緩存，都是典型場景。Flutter里用Isolate執(zhí)行耗時Command，避免阻塞UI線程。

這套架構(gòu)體系是14篇面試系列的第5篇。前面4篇覆蓋了Dart基礎(chǔ)、Widget原理、狀態(tài)管理、性能優(yōu)化，后面還有9篇講測試、部署、混合開發(fā)。完整路線圖在GitHub上能搜到，作者叫Mangirdas Kazlauskas，立陶宛的Flutter GDE。

他有個觀點挺有意思：Clean Architecture在Flutter里的最大敵人，是Hot Reload�？焖俚屓藨械梅謱樱椭苯佣言趍ain.dart。但產(chǎn)品上線后，技術(shù)債的利息比銀行還高。