Marico's space

最近折腾 Flutter 项目架构，踩了几个坑，这篇把问题说清楚：让应用更容易扩展，靠的往往不是某个流行的状态管理库，而是从一开始就划清职责边界。

大多数 Flutter 应用之所以后期难以维护，并不是 Flutter 本身不能扩展，而是 MVP（最小可行性产品）阶段看起来无伤大雅的架构决策，随着产品增长逐渐变成昂贵的技术债务。

一个页面直接调用 API（应用程序接口），在应用只有五个页面时通常没问题。但当应用扩展到多种用户角色、支付流程、后台同步和复杂业务规则时，这些捷径就会开始制造麻烦。

在实际参与生产级移动应用开发后，我发现，可扩展性更取决于如何定义职责边界，而不是选中了哪款最热的状态管理库。

下面这五个架构决策，确实能带来明显差异。

1. 将业务逻辑与 UI 分离

Flutter 项目中最常见的问题之一，就是把 API 请求、校验、业务规则和导航逻辑直接塞进 Widget 里。

比如：

onPressed: () async { final response = await http.post( Uri.parse('$baseUrl/orders'), body: jsonEncode(orderData), ); if (response.statusCode == 201) { Navigator.pushNamed(context, '/success'); }
}

这种写法一开始可能没问题，但它会让展示逻辑、网络请求和业务行为紧紧耦合在一起。

更合理的做法，是先建立清晰的边界：

Presentation Layer ↓
Application / State Layer ↓
Domain Layer ↓
Data Layer ↓
API / Database

展示层负责渲染和用户交互。

应用层负责协调状态和用例。

领域层负责表达业务规则与契约。

数据层负责 API 通信、本地持久化和数据映射。

这样拆分后，功能模块更容易测试、修改和复用。

实际建议：Widget 不应该关心 API 请求如何完成认证、重试或持久化。

2. 根据复杂度选择状态管理，而不是追趋势

Flutter 提供了多种状态管理方案，包括 Provider、Bloc/Cubit、Riverpod 和 GetX。

并不存在一种方案，能自动让所有应用具备良好的扩展性。

真正重要的是，选定的方案能否提供可预测的状态转换，并把业务逻辑留在 Widget 树之外。

以提交订单功能为例，它的状态可能包括：

• 初始状态
• 加载中
• 成功
• 失败

如果使用 Cubit，代码大致如下：

sealed class OrderState {} class OrderInitial extends OrderState {} class OrderLoading extends OrderState {} class OrderSuccess extends OrderState {} class OrderFailure extends OrderState { final String message; OrderFailure(this.message);
} class OrderCubit extends Cubit<OrderState> { final OrderRepository repository; OrderCubit(this.repository) : super(OrderInitial()); Future<void> submitOrder(Order order) async { emit(OrderLoading()); try { await repository.createOrder(order); emit(OrderSuccess()); } catch (error) { emit(OrderFailure(error.toString())); } }
}

Widget 只负责观察状态并做出相应响应。

Repository 继续负责数据操作。

这样就能更清楚地分开用户界面行为与业务操作。

实际建议：整个项目保持一致的状态管理模式，比在不同库之间反复切换更重要。

3. 把 API 集成视为架构边界

API 不应该只是散落在不同页面中的一堆 HTTP（超文本传输协议）调用。

随着应用规模扩大，API 集成承担的工作远不止收发 JSON（JavaScript 对象表示法）。

它可能还需要处理：

• 身份认证与令牌刷新
• 请求超时
• 网络故障
• 错误标准化
• 分页
• 重试策略
• 响应校验

引入 Repository 抽象，可以把这些职责隔离起来。

abstract class ProductRepository { Future<List<Product>> getProducts(); Future<Product> getProductById(String id);
}

应用随后可以依赖 Repository 契约，而不是绑定某个具体的 HTTP 客户端或后端实现。

class GetProducts { final ProductRepository repository; GetProducts(this.repository); Future<List<Product>> call() { return repository.getProducts(); }
}

以后即使后端发生变化，或者需要加入缓存，也不需要重写展示层。

对于涉及金融交易的应用，重试机制尤其需要谨慎处理。如果支付或创建订单的请求缺少幂等性保护，重复发送可能造成重复操作。

实际建议：把网络行为集中管理，并从项目开始就按照失败场景设计架构。

4. 规划离线行为与数据一致性

移动应用不能假设每个用户始终都有稳定的网络连接。

这一点在库存系统、配送应用、POS（销售点）解决方案和现场服务工具中尤其重要。

一套具备离线能力的架构，可能长这样：

Flutter UI ↓
State Management ↓
Repository ├── Local Database └── Remote API ↓ Backend Database

本地数据库用于支持缓存读取，并在合适的场景下承接排队写入的请求。

同步层负责在网络恢复后处理尚未完成的操作。

但离线支持并不等于把数据保存到本地这么简单。

你还必须明确：

• 哪些操作允许在离线状态下执行？
• 哪一份数据才是权威来源？
• 发生更新冲突时如何解决？
• 某个操作能否安全重试？
• 用户如何知道操作仍在等待处理，还是已经确认完成？

例如，离线 POS 系统不能把本地排队中的销售直接视为服务端已确认的交易，必须等待后端确认。

稳定的操作 ID 与支持幂等性的后端接口，可以帮助避免同步过程中发生重复处理。

实际建议：离线优先设计需要明确的一致性规则，而不只是增加一个本地数据库。

5. 为测试、可观测性与发布准备而设计

可扩展的架构不只是整理源代码。

它还必须支持调试、测试、部署和维护。

通常，我会从三个层次考虑质量保障：

单元测试

独立验证业务规则、计算逻辑和状态转换。

集成测试

验证 Repository、API、本地存储和其他依赖项之间的交互。

端到端测试

检查身份认证、结账或订单提交等关键用户流程。

除了测试，生产应用还需要具备以下能力：

• 结构化错误处理
• 崩溃报告
• 性能监控
• 安全配置管理
• 发布构建校验
• 依赖项与平台兼容性检查

一个功能在开发者的设备上运行正常，并不代表它已经具备生产环境上线条件。

真正的目标，是让失败可以被观察，让每次变更都能安全发布。

实际建议：可维护性还包括你能否有底气测试、部署、监控和更新应用。

最后说两句

Flutter 可以支撑复杂应用，但项目的长期可维护性，取决于应用周围做出的架构决策。

我优先考虑的五条原则是：

1. 让业务逻辑与展示层保持分离。
2. 使用一致且可预测的状态管理方式。
3. 把 API 集成视为定义明确的架构边界。
4. 围绕数据一致性设计离线流程。
5. 把测试与生产发布准备纳入架构本身。

没必要把每一个 MVP 都设计得过度复杂。

但你必须让架构具备成长空间，避免每次新增功能都不得不推倒重写。

关于作者

我是 Ayesha Ahmed，一名软件工程师和移动应用开发者，现居巴基斯坦伊斯兰堡。我专注于移动应用、后端系统、SaaS（软件即服务）平台以及定制业务软件。

下面是我的移动端开发作品和项目：

Mobile App Development Portfolio — AyeshaAppDev

也可以访问 ayeshaappdev.com，查看我的完整作品集。

在你的移动应用维护工作中，究竟是哪一个架构决策带来了最大的变化？