Flutter架构面试被挂的3个盲区

去年面了17个Flutter候选人，问Clean Architecture能画对三层结构的不到一半。不是不知道Domain层要独立，是说不清为什么Data层能依赖Domain，反过来却不行。

这题其实考的是依赖方向，不是背诵。Robert C. Martin（Uncle Bob）在2012年提出Clean Architecture时，核心就一条规则：源代码依赖只能向内指向。Domain层是同心圆最内层，它不能知道外面任何一层的存在。

但很多人面试时把Repository接口放在Data层，这就是盲区。接口定义是契约，契约必须由内层持有。Data层的Repository实现（Repository Implementation）去依赖Domain层的抽象接口，这才是正确方向。

三层结构的面试陷阱

看一个典型的Flutter项目结构。Domain层包含Entities、Repository抽象接口、Use Cases；Data层放Models、Data Sources、Repository的具体实现；Presentation层管UI、状态管理（Bloc/Provider/Riverpod）。

面试常挂的第二个盲区：Use Case到底是什么？

它不是"调用API的地方"，而是封装单一业务逻辑的类。每个Use Case只做一件事——获取用户资料、更新购物车、验证优惠券。输入参数和返回类型都要显式定义，通常用泛型抽象基类统一约束。

第三个盲区更隐蔽：Error Handling怎么跨层传递？

Domain层不能依赖Flutter的http包，也不能用Dio的异常类型。必须自定义Failure类，Data层把技术异常（DioError、SocketException）映射为业务失败（ServerFailure、CacheFailure）。Presentation层只认识Failure，不认识DioError。

为什么Repository必须是抽象接口

讲个类比。Domain层是餐厅菜单，Data层是后厨。顾客（Presentation层）点菜只看菜单，不关心后厨用燃气灶还是电磁炉。但菜单本身不能写"用燃气灶做"，那是后厨的事。

Repository抽象接口就是菜单上的菜品描述。具体用Firebase还是REST API实现，是Data层的自由。这种隔离让单元测试能直接Mock Repository，不用启动真实数据库。

面试时问"为什么要用接口"，答"方便替换实现"只是60分。高分答案是：Domain层定义业务需要什么，Data层决定技术怎么给。需求变更时，改接口是架构破坏，改实现是正常迭代。

Dependency Injection的实战选择

Flutter社区主流用get_it配合injectable代码生成，或者直接用Riverpod的Provider。面试不会问你背API，会问"为什么不用new关键字直接创建对象"。

答案是控制反转（Inversion of Control）。对象生命周期由容器管理，构造函数的依赖由外部注入。这样测试时可以换Mock实现，生产环境用真实实现，不用改业务代码。

injectable的好处是编译时代码生成，零运行时反射。这在Flutter里很重要，因为反射（dart:mirrors）在Release模式被禁用，会影响包体积和启动速度。

SOLID原则在Flutter里的具体落地

Single Responsibility：一个Widget只做一件事。不是"登录页面"一个文件2000行，而是拆成LoginForm、LoginButton、ErrorMessage三个独立Widget。

Open/Closed：用扩展方法给String加验证逻辑，而不是改原来的类。Flutter 3.0的extension语法让这变得干净。

Liskov Substitution：Bloc的状态类设计。AuthState是基类，AuthLoading、AuthSuccess、AuthError是子类。UI层用switch-case处理，任何子类都能替换基类位置。

Interface Segregation：不要一个Repository接口塞20个方法。按功能拆成UserRepository、OrderRepository、PaymentRepository。调用方只依赖自己需要的接口。

Dependency Inversion：前面说的Domain层持有接口，Data层实现接口。高层模块（Use Case）不依赖低层模块（Dio Client），两者都依赖抽象。

设计模式的面试高频考点

Singleton在Flutter里慎用。GetIt默认单例，但BLoC通常用Factory，保证每个页面独立状态。面试问"Singleton有什么问题"，要答全局状态难测试、生命周期难管理。

Factory Pattern的典型场景是平台适配。创建PlatformChannel时，根据Platform.isAndroid返回Android实现，iOS返回iOS实现。调用方无感知。

Observer Pattern就是Flutter的NotificationListener、ScrollNotification，或者BLoC的Stream。面试常问"BLoC和Provider区别"，本质是Observer和InheritedWidget两种状态传播机制的差异。

Builder Pattern在Flutter里无处不在。AlertDialog.builder、showModalBottomSheet的builder参数，都是把构造逻辑延迟到需要时执行。复杂对象的 step-by-step 构造，避免构造函数参数爆炸。

Strategy Pattern用于替换算法。图片加载用CachedNetworkImageStrategy，测试用MockImageStrategy，都实现同一个ImageLoader接口。运行时切换，不用if-else堆逻辑。

Decorator Pattern在Dio的Interceptor里体现。日志拦截器、重试拦截器、Token刷新拦截器，层层包装原始请求。每个拦截器只加一个职责，符合Single Responsibility。

Adapter Pattern解决接口不兼容。第三方SDK返回的数据结构和你定义的Entity不同，写个Adapter做字段映射。不是改SDK，也不是改Entity，中间加一层转换。

Command Pattern把请求封装成对象。Undo/Redo功能、离线操作的队列缓存，都是典型场景。Flutter里用Isolate执行耗时Command，避免阻塞UI线程。

这套架构体系是14篇面试系列的第5篇。前面4篇覆盖了Dart基础、Widget原理、状态管理、性能优化，后面还有9篇讲测试、部署、混合开发。完整路线图在GitHub上能搜到，作者叫Mangirdas Kazlauskas，立陶宛的Flutter GDE。

他有个观点挺有意思：Clean Architecture在Flutter里的最大敌人，是Hot Reload。快速迭代让人懒得分层，原型直接堆在main.dart。但产品上线后，技术债的利息比银行还高。