从 Day 1 把 Flutter 环境跑在鸿蒙设备上到前两天还在折腾平台通道和原生交互说实话前四天都在解决“能不能跑”的问题。到了第五天业务量和页面复杂度明显上来了我不得不正面刚一个所有跨端开发迟早要面对的问题复杂业务状态到底放哪、怎么管。这篇文章就完整记录我用 BLoC 模式重构一个多状态订单流程的核心过程从为什么选它、状态机怎么设计到 UI 层怎么接入、踩了哪些坑。如果你也在鸿蒙上用 Flutter 做中大型业务或者你正处于“setState 还能对付、但总觉得哪里不对劲”的阶段这篇应该能给你一套可以直接抄作业的流式状态管理思路。1. 为什么我在鸿蒙项目里最终选了 BLoC而不是 setState 或 Provider1.1 先说说我最开始是怎么把状态写乱的我手头这个模拟项目 X是一个跨端内容发布与审核工具在鸿蒙平板和手机上都要跑。业务流程不复杂用户创建一条内容草稿提交后经过异步审核审核可能有通过、驳回、系统异常等结果管理员还能中途撤回。听起来就四个状态但实际写起来页面一多就失控了。一开始我用最朴素的方式每个页面自己维护一坨 bool 和枚举比如isSubmitting、isPassed、needRetry跨页面传参靠构造函数页面间同步状态靠回调。结果就是内容列表页要知道详情页有没有提交成功详情页又要在回调里触发列表刷新提交失败还要弹 SnackBar管理端还要能打断当前状态。几天下来光排查“为什么列表状态和详情状态不一致”就花了我大半天。如果你也经历过这种状态一多就四处救火的情况大概率能理解我当时的感受问题不是某个页面逻辑写错了而是状态没有一个统一的归属地每个页面都在偷偷改自己的局部变量改动一多就没有一个清晰的“当前全局状态”可以依赖。1.2 三套方案实测下来的真实差异我在这个项目里实际对比过三种主流状态管理方案各自都有明显适用场景setState适合组件内部、状态变化非常低频的小场景。比如一个展开收起按钮用 setState 没任何问题。但只要是跨页面、跨组件、有异步时序的状态它就会暴露出状态同步成本高、新手容易乱调的缺点。Provider ChangeNotifier比 setState 好很多依赖注入也方便但它本质上仍然是命令式的状态变更。你在业务逻辑里写notifyListeners()UI 层来一个数据就刷新一个逻辑复杂后通知链路一长不好回溯到底谁改了什么。BLoCBusiness Logic Component核心是事件驱动 单向数据流。UI 只做一件事向 BLoC 发送事件Event然后根据 BLoC 输出的状态State来渲染。状态怎么变、什么时候变完全由 BLoC 内部决定UI 不直接改数据。这种风格对“状态机”类业务格外友好因为整个状态迁移路径可以集中在一个类里看清。我最终选择 BLoC 还有一个现实原因鸿蒙端和 Android/iOS 端共用同一套 Flutter 业务代码BLoC 是纯 Dart 实现不依赖任何 UI 上下文天然适合跨端复用。后续即便鸿蒙原生侧要接入BLoC 这一层逻辑也能原封不动地被测试和复用。1.3 BLoC 帮我把三类“状态病”一次性治好了接入了 BLoC 之后回头看我原来那套 setState 写法其实患有三种典型状态病状态散落病每个页面各自定义状态变量没有统一出口。BLoC 用“一个 BLoC 对应一类业务状态”的方式把散落的变量收敛到一个类里。转移条件隐藏病原来“能不能提交”“能不能取消”这类判断分散在按钮点击事件里出了问题要靠人肉搜索。BLoC 通过状态转移守卫逻辑把非法操作挡在入口处。非法状态漏网病比如重复点击提交按钮导致的并发提交、审核完成后还能再取消等问题原始写法很难防住。BLoC 的事件进入 BLoC 后按顺序处理配合状态机守卫这个问题可以干净利落地解决。提示如果你的业务状态只有两三个、互相之间没有复杂流转用 BLoC 反而有点过度设计。先判断是否有“状态之间的转移规则比较复杂”这个前提再决定要不要上这套方案。2. 把“状态机”翻译成“事件流”的基本功2.1 三个必懂概念事件、状态、BLoC 本体BLoC 模式的三件套我习惯用外卖来类比。你在外卖 App 里点“提交订单”这个点击动作就是事件Event。提交后页面显示“下单中”“已接单”“已送达”这些都是状态State。而真正处理下单、接单、送达这套流程的中央调度系统就是BLoC。在一个 Flutter 应用里这套映射是这样的Event你定义的一个普通 Dart 类描述用户意图或外部通知。比如SubmitOrderEvent、CancelOrderEvent。State也是普通 Dart 类描述某个业务阶段下界面的所有数据。比如OrderSubmittingState、OrderSubmittedState。BLoC继承BlocEvent, State的类你注册“当收到某个 Event 时执行什么逻辑”然后通过emit把新状态推给 UI。理解了这个关系再看整套模式就顺了UI 层只负责两件事把用户动作包装成 Event 发出去以及根据 State 渲染页面。它不直接改任何业务数据。2.2 为什么每个状态都必须是新的对象BLoC 模式里有一个很容易被忽略但极其重要的规则状态是不可变的。每次状态变化都必须是生成一个新的状态对象而不是在原有对象上改字段。我第一次用 BLoC 时犯过一个经典错误写了一个可变类当 State在 BLoC 里state.orderList.add(newItem)然后emit(state)。结果 UI 层根本没有刷新。原因就是BlocBuilder比较的是新旧状态对象你 emit 的是同一个对象引用它认为“没变化”直接不重建 widget。后来我改成不可变类的写法用一个包含所有字段的 State 基类每次变更时通过copyWith创建新实例一切就正常了。这不仅是技术上的要求也是思维方式的转变UI 是状态的函数你给我一个不可变的状态我就能可预期地画出一种界面你原地修改状态UI 层根本感知不到变化逻辑就不可追踪了。2.3 流式思维到底“流”在哪里很多人看 BLoC 文档最难理解的点就是 Stream。我刚开始也纠结我又不是在写数据管道为什么要跟 Stream 打交道换个角度来看这件事。传统写法里代码是“拉”数据页面要展示列表时自己去调一个方法拿返回值。而 BLoC 是“推”数据页面创建时订阅一个状态流之后 BLoC 一旦 emit 新状态页面就会自动收到通知从而决定是否重建。这就是“流式思维”你不再关心数据什么时候来、怎么来你只关心事件发出去之后状态流会把你推到哪个状态。UI 就像坐在河边看风景的人河水状态流流到哪一幕他就画哪一幕。这个思路和状态机的契合度也极高状态机关心的就是“当前状态 触发事件 → 新状态”BLoC 内部天然就是这个结构。3. 实战拆解一个跨端内容审核状态机的完整实现3.1 业务场景与状态转移表我在模拟项目 X 里抽出来的业务场景是这样的用户提交一条内容系统先做本地格式校验然后进入异步审核队列审核可能通过、不通过也可能因为服务异常进入失败态。管理员可以在任意非终态时撤回该内容。我把状态机定义成下面这张表当前状态触发事件允许下一状态草稿Draft提交SubmitRequested是提交中Submitting提交中Submitting审核通过AuditPassed是通过Passed提交中Submitting审核不通过AuditRejected是拒绝Rejected提交中Submitting系统异常AuditFailed是失败Failed提交中Submitting撤回RevokeRequested是撤回中Revoking提交中Submitting再次提交SubmitRequested否保持不变失败Failed重试RetryRequested是提交中Submitting通过Passed撤回RevokeRequested是撤回中Revoking撤回中Revoking撤回完成RevokeFinished是已撤回Revoked已撤回Revoked任何事件否保持不变这张表看起来很基础但它就是整个状态机的地基。没有这张表写代码时你会有无数个“万一”有了这张表每个事件在 BLoC 里是放行还是拦截一查便知。3.2 三步定义事件与状态类定义状态与事件的方式非常直白一共三步。第一步定义状态抽象类和具体状态类。我在代码里给状态类加了一个description字段方便调试时直接打印。// 状态基类 abstract class AuditState { const AuditState({required this.description}); final String description; } // 草稿态 class AuditDraft extends AuditState { const AuditDraft() : super(description: 草稿); } // 提交中 class AuditSubmitting extends AuditState { const AuditSubmitting() : super(description: 正在提交审核); } // 通过 class AuditPassed extends AuditState { const AuditPassed({required this.contentId, required this.auditMessage}); final String contentId; final String auditMessage; override String toString() AuditPassed(contentId: $contentId, auditMessage: $auditMessage); } // 拒绝 class AuditRejected extends AuditState { const AuditRejected({required this.reason}); final String reason; } // 失败 class AuditFailed extends AuditState { const AuditFailed({required this.errorMessage}); final String errorMessage; } // 撤回中 class AuditRevoking extends AuditState { const AuditRevoking() : super(description: 正在撤回); } // 已撤回 class AuditRevoked extends AuditState { const AuditRevoked({required this.revokeTime}); final DateTime revokeTime; }第二步定义事件类。注意事件类里可以携带参数比如提交的内容、审核结果、错误信息这些参数是 BLoC 做后续处理时能拿到的原料。abstract class AuditEvent {} class DraftContentChanged extends AuditEvent { DraftContentChanged(this.content); final String content; } class SubmitRequested extends AuditEvent { SubmitRequested({this.contentId}); final String? contentId; } class AuditPassed extends AuditEvent { AuditPassed({required this.contentId, required this.auditMessage}); final String contentId; final String auditMessage; } class AuditRejected extends AuditEvent { AuditRejected({required this.reason}); final String reason; } class AuditFailed extends AuditEvent { AuditFailed({required this.errorMessage}); final String errorMessage; } class RetryRequested extends AuditEvent {} class RevokeRequested extends AuditEvent {}第三步是用 flutter_bloc 包把 BLoC 类写出来。这里我用了两个关键 APIonEvent注册事件处理器emit(State)推送新状态。下面的代码里我还特意给每个事件加了一个状态转移校验先看当前状态允不允许触发这个事件不允许就直接忽略并打印日志。import package:flutter_bloc/flutter_bloc.dart; class AuditBloc extends BlocAuditEvent, AuditState { AuditBloc({required this.auditService}) : super(const AuditDraft()) { onSubmitRequested(_onSubmitRequested); onAuditPassed(_onAuditPassed); onAuditRejected(_onAuditRejected); onAuditFailed(_onAuditFailed); onRetryRequested(_onRetryRequested); onRevokeRequested(_onRevokeRequested); } final dynamic auditService; // 模拟服务层 Futurevoid _onSubmitRequested(SubmitRequested event, EmitterAuditState emit) async { if (state is AuditSubmitting || state is AuditPassed || state is AuditRevoked) return; emit(const AuditSubmitting()); try { final contentId await auditService.submit(event.contentId ?? new); add(AuditPassed(contentId: contentId, auditMessage: 提交成功)); } catch (e) { add(AuditFailed(errorMessage: e.toString())); } } void _onAuditPassed(AuditPassed event, EmitterAuditState emit) { if (state is! AuditSubmitting) return; emit(AuditPassed(contentId: event.contentId, auditMessage: event.auditMessage)); } void _onAuditRejected(AuditRejected event, EmitterAuditState emit) { if (state is! AuditSubmitting) return; emit(AuditRejected(reason: event.reason)); } void _onAuditFailed(AuditFailed event, EmitterAuditState emit) { if (state is! AuditSubmitting) return; emit(AuditFailed(errorMessage: event.errorMessage)); } Futurevoid _onRetryRequested(RetryRequested event, EmitterAuditState emit) async { if (state is! AuditFailed) return; emit(const AuditSubmitting()); try { final contentId await auditService.submit(retry); add(AuditPassed(contentId: contentId, auditMessage: 重试成功)); } catch (e) { add(AuditFailed(errorMessage: e.toString())); } } void _onRevokeRequested(RevokeRequested event, EmitterAuditState emit) { if (state is AuditDraft || state is AuditRevoked || state is AuditPassed false) return; emit(const AuditRevoking()); // 模拟异步撤回 Future.delayed(const Duration(seconds: 1), () { if (!isClosed) emit(AuditRevoked(revokeTime: DateTime.now())); }); } }这套实现有几个细节值得注意事件处理器里第一步都是校验当前状态。比如_onAuditPassed里要求当前必须是AuditSubmitting如果审核结果事件在错误的时机到达直接忽略。这个设计就是状态机里的“非法转移拦截”。add的用法值得留意。在异步逻辑里我不直接在耗时操作后emit下一个状态而是通过add(另一个事件)再次进入 BLoC 的事件处理流程。这种写法的好处是每个状态转移都有明确的事件记录调 bug 时可以看到完整的事件链路。isClosed是为了防止 BLoC 已经销毁后延迟任务还在尝试 emit。做异步操作时这个判断非常重要。3.3 UI 层接入BlocProvider、BlocBuilder 与按钮状态UI 层接入非常模板化。在页面顶层用BlocProvider提供 BLoC 实例然后用BlocBuilder监听状态变化不同状态渲染不同 UI。class AuditPage extends StatelessWidget { override Widget build(BuildContext context) { return BlocProvider( create: (_) AuditBloc(auditService: AuditService()), child: Scaffold( appBar: AppBar(title: const Text(内容审核)), body: BlocBuilderAuditBloc, AuditState( builder: (context, state) { if (state is AuditDraft) { return _buildDraftView(context); } else if (state is AuditSubmitting) { return const Center(child: CircularProgressIndicator()); } else if (state is AuditPassed) { return _buildPassedView(state); } else if (state is AuditRejected) { return _buildRejectedView(state); } else if (state is AuditFailed) { return _buildFailedView(context, state); } else { return _buildRevokedView(state); } }, ), ), ); } }每个 view 里按钮通过context.readAuditBloc().add(SomeEvent())来发起事件。比如提交按钮ElevatedButton( onPressed: () context.readAuditBloc().add(SubmitRequested()), child: const Text(提交审核), )到了这一步你会发现 UI 层里几乎没有if (isXXX) {} else {}的业务逻辑判断全部变成了“对状态做分支渲染”。这带来的直接好处就是UI 层做不了任何改变状态的动作它只能请求 BLoC 去处理。提示不要直接context.readAuditBloc().state来判断页面逻辑。BlocBuilder 的 builder 里拿到的 state 才是当前应该渲染的依据如果你直接读 state 再去改 UI状态变化时不会触发 rebuild很容易出现界面不更新的问题。4. 状态机建模不踩坑非法转移、事件并发和失败重试4.1 把状态转移表变成运行时守卫状态机建模最怕的不是“正常路径走不通”而是“非法路径没拦住”。拿我之前的模拟业务来说最典型的非法路径就是用户连续点了两次提交按钮第一次提交还没返回第二次又发了一个SubmitRequested。在传统 setState 写法里你可能会用一个_isSubmitting布尔值来挡住但这个布尔值只能挡一种情况状态一多你就要写一堆if (!_isSubmitting !_isRevoking ...)维护成本很高。BLoC 的写法就优雅很多把允许的状态转移定义成一张映射表事件进来先查表查不到就拒绝。class AuditStateMachine { static const MapType, ListType _transitions { AuditDraft: [AuditSubmitting], AuditSubmitting: [AuditPassed, AuditRejected, AuditFailed, AuditRevoking], AuditFailed: [AuditSubmitting, AuditRevoked], AuditPassed: [AuditRevoking], AuditRevoking: [AuditRevoked], AuditRevoked: [], }; static bool canTransition(AuditState from, Type to) { return _transitions[from.runtimeType]?.contains(to) ?? false; } }有了这张表BLoC 里的每个事件处理器都可以先来做守卫。比如_onAuditPassed里你可以把if (state is! AuditSubmitting) return;换成更通用化的写法void _onAuditPassed(AuditPassed event, EmitterAuditState emit) { if (!AuditStateMachine.canTransition(state, AuditPassed)) return; emit(AuditPassed(contentId: event.contentId, auditMessage: event.auditMessage)); }这种做法的好处一眼就能看出来以后加一个新状态只需要维护表里的一行数据不需要到大大小小的函数里去翻逻辑。4.2 BLoC 的事件排队机制其实是你的并发保险BLoC 在处理同一类型事件时是默认串行处理的也就是说如果你连续 add 了两个SubmitRequestedBLoC 会先处理完第一个再处理第二个。但注意它不会自动“拦截”第二个它只是排队。所以防重复提交不能只依赖 BLoC 的排队机制一定要配合状态守卫。当第一个SubmitRequested已经把状态变成AuditSubmitting之后第二个SubmitRequested进入处理器时canTransition发现AuditSubmitting不能转移到AuditSubmitting就会直接忽略。我实测下来这个组合拳的效果很理想不管用户多快点击多少次提交最终只会触发一次真正的网络提交。这种“状态机决定放行与否”的思路比任何加锁方案都干净因为你不需要在 UI 层维护额外的互斥变量。4.3 失败重试的两种设计姿势审核失败后的重试逻辑我见过两种设计。第一种是把“重试”当成一个独立事件如上面代码里的RetryRequested。第二种是把“重试”当作一个新的SubmitRequested来处理因为反正最终目的都是提交沿用同一个事件处理器。我建议用独立事件RetryRequested原因有两点。一是语义清晰失败重试和首次提交虽然底层动作一样但用户意图和 UI 展示可能不同。重试时你可能想记录“这是第 N 次尝试”独立事件给这些附加信息留了空间。二是状态机守卫更严谨独立事件可以专门定义“只有 AuditFailed 状态才能触发 RetryRequested”一旦有人在错误状态发了重试日志里一眼就能看清。5. 实战中遇到的 4 个经典问题与排查实录5.1 状态更新了但 UI 不刷新原来是对象相等性在作怪这个问题我在 2.2 小节提过但这里专门展开说一下。当时我写完 BLoC 后遇到一个诡异现象日志明明打出了AuditPassed状态被 emit 出来了但页面的BlocBuilder就是不重建。排查过程是这样的我先是加了大量日志确认 UI 有没有走进 builder发现 builder 没有重新执行之后怀疑是BlocProvider作用域问题最后才发现是我自定义的 State 类没有重写和hashCode。BlocBuilder默认通过判断新旧 State 是否相等来决定是否重建如果两个AuditPassed实例只有contentId不同但没重写它们就被认为是同一个对象于是 builder 被跳过。解决办法是给所有 State 类加上equatable依赖让它们通过字段比较判断相等性class AuditPassed extends Equatable { const AuditPassed({required this.contentId, required this.auditMessage}); final String contentId; final String auditMessage; override ListObject? get props [contentId, auditMessage]; }这是我的第一个建议从项目一开始就给 State 类统一加上 equatable或者统一重写。别等遇到问题时再补因为项目大了以后补这个的排查成本非常高。5.2 事件被“吞”了为什么 add 之后毫无反应还有一次我在一个子页面里context.readAuditBloc().add(SubmitRequested())但页面毫无反应。折腾了半天发现是作用域问题子页面所在的BuildContext根本不在BlocProvider的包裹范围内read找不到对应的 BLoC 实例。排查方法非常简单在read之后立刻用context.watchAuditBloc().state看一眼当前状态。如果read都找不到 BLoC会直接抛异常如果没有抛异常但事件没生效再检查事件类型是否被正确注册到了on里。另外要注意在StatelessWidget的 build 方法里直接read一个 BLoC 再add事件是合法的但如果你在 build 过程中调用add会导致 BLoC 在处理事件时又触发 UI rebuild形成死循环。正确的姿势是永远在事件回调里 add比如按钮的onPressed。5.3 页面销毁后异步结果才回来emit 直接报错这个坑我在做异步撤回逻辑时踩过。页面已经返回上一级BLoC 也调用了close()但异步任务里的Future.delayed回调还在执行这时候如果去emit就会抛异常。flutter_bloc 在emit时其实有安全检查但更稳妥的写法是异步回调里先判断isClosedFuture.delayed(const Duration(seconds: 1), () { if (!isClosed) emit(AuditRevoked(revokeTime: DateTime.now())); });如果你要做的是网络请求后的回调也建议在add进后续事件之前判断一下isClosed。虽然add到已关闭的 BLoC 也会被自动忽略但提前判断日志更干净排查起来更顺畅。5.4 用 BlocObserver 把整个状态流转过程变成可视化日志排这些坑的过程中我最大的收获是养成了一个习惯全局挂一个 BlocObserver。flutter_bloc 提供了BlocObserver这个抽象类你只需要继承它重写onEvent、onTransition、onError三个方法然后把所有 BLoC 的事件、状态变化、异常都打印出来class AppBlocObserver extends BlocObserver { override void onEvent(Bloc bloc, Object? event) { super.onEvent(bloc, event); debugPrint(${bloc.runtimeType} → event: $event); } override void onTransition(Bloc bloc, Transition transition) { super.onTransition(bloc, transition); debugPrint(${bloc.runtimeType} → state: ${transition.currentState} - ${transition.nextState}); } override void onError(Bloc bloc, Object error, StackTrace stackTrace) { super.onError(bloc, error, stackTrace); debugPrint(${bloc.runtimeType} → error: $error); } }全局观察器特别适合排查“状态怎么就到了这个值”这类问题。你只需要把日志打开一整套事件流和状态转移过程就摆在眼前比在业务代码里插桩干净得多。我后来的所有 Flutter 项目都引入了这个观察器跨端调试时省了非常多时间。6. 这套 BLoC 状态机还能怎么扩展6.1 多个 BLoC 之间怎么协作真实业务里页面级 BLoC 之间经常会互相通知。比如内容提交成功后除了AuditBloc要把状态变成AuditPassed全局的NoticeBloc可能还要推一条未读消息UserBloc可能还要更新用户的发布计数。这时候千万别让一个 BLoC 直接持有另一个 BLoC 的实例去add。正确的姿势是让页面自己做编排页面层同时监听两个 BLoC在某个 BLoC 的状态变化回调里主动给另一个 BLoC 发事件。比如在BlocListenerAuditBloc, AuditState里监听AuditPassed然后调用context.readNoticeBloc().add(NoticeAdded(...))。这样每个 BLoC 仍然保持独立状态流转不会被跨逻辑污染。6.2 结合持久化做状态恢复状态机终态比如已撤回、已通过通常要持久化但非终态在 App 崩溃后恢复也是常见需求。BLoC 的模式在这里也很有优势你可以在初始化 BLoC 时读取持久化数据构造初始状态。class AuditBloc extends BlocAuditEvent, AuditState { AuditBloc({required this.auditService, AuditState? initialState}) : super(initialState ?? const AuditDraft()); }页面启动时从本地数据库取最近一次状态如果是AuditSubmitting那说明上次提交可能已经发出但没收到结果直接进入“检测上次提交状态”的恢复流程而不是让用户傻等。这个思路对跨端业务很有用因为鸿蒙 App 的生命周期管理和 Android 不完全一样恢复现场能力尽量放在业务层比平台层灵活得多。6.3 把业务逻辑抽出来做单元测试BLoC 是纯 Dart 类这一点在测试上的优势太大了。你不需要启动 UI不需要模拟点击直接构造事件序列验证状态是否如预期流转即可。test(提交成功流程, () async { final bloc AuditBloc(auditService: FakeAuditService()); expect(bloc.state, isAAuditDraft()); bloc.add(SubmitRequested()); await expectLater( bloc.stream, emitsInOrder([ isAAuditSubmitting(), isAAuditPassed(), ]), ); });注意这里要记得在测试结束后await bloc.close()。我最初写测试时经常忘记 close导致测试进程挂起排查了很久才发现是 BLoC 的 StreamController 没关。这五天真刀真枪写下来我最真实的感受是BLoC 模式的最大价值不是“把代码改好看了”而是逼着你在写代码之前先想清楚业务状态有哪些、能怎么流转、不能怎么流转。流程不清晰的时候setState 能让你糊弄过去而 BLoC 会在建模阶段就逼你把问题露出来。如果你也想把现有的 Flutter 项目往 BLoC 重构我建议从一条最核心的、状态流转最多的业务流程入手先把状态转移表画出来再动手拆事件和状态。等这条链路跑顺了你会发现自己已经用上了流式思维来思考问题而不是再依赖那些散落各处的临时变量了。