把存量 Flutter 应用迁到鸿蒙之后我第一周的多数时间不是耗在界面适配而是蹲在崩溃列表里翻异常。就在那段时间我决定在工程里引入 df_safer_dart用 Result/Option 给所有可能失败的边界补一道防线。这个库不像普通插件那样需要改平台工程它不碰鸿蒙原生代码纯粹靠 Dart 类型系统把“这个操作可能失败”变成显式约束调用方要么处理失败分支要么就会在写代码的时候被迫面对它。下面这篇把它的原理、接入过程、实战改造和踩坑经历全部分享出来适合正在做鸿蒙 Flutter 适配、或者想在 Dart 里实践 Rust 风格错误处理的团队参考。1. 为什么鸿蒙Flutter应用要用Result/Option代替裸露的try/catch1.1 默认异常模型在鸿蒙端的三个弱点Dart 的异常模型和 Rust、Go 这类语言完全不同它仍然遵循“抛出—冒泡—捕获”的路子。某个 async 回调里抛了异常只要没有 await 或者没有 catch异常就会一路向上走最终在顶层变成一行 FlutterError 日志。问题在于这种隐式传播非常依赖每个调用者都自觉写 try/catch而实际工程里漏掉的地方远比补上的地方多尤其在鸿蒙这种新平台上代码里到处是从 Android/iOS 抄过来的历史逻辑异常传播路径被各种 Callback、Future、EventChannel 打断原本在旧平台上勉强能工作的结构到了鸿蒙上经常变成“日志里有异常但找不到谁漏接”。鸿蒙 Flutter 工程还有一层额外风险很多三方插件并没有为鸿蒙写完整的原生实现运行时可能走通用通道、可能返回空数据、可能直接抛 MissingPluginException。也就是说同一段业务代码在 Android 上能读到完整的 Map在鸿蒙上拿到的却可能是一个 null或者一个键值对不全的 Map。Dart 空安全能挡住一部分“显式 null”但挡不住“对象存在但内容不符合预期”的情况更挡不住平台通道抛出的异常类型变化。这些都是默认异常模型在鸿蒙端暴露出来的弱点。对比维度裸 try/catchResult/Option错误信号载体运行时异常冒泡函数返回值显式携带调用方感知方式不阅读文档很难知道会抛什么类型签名直接告诉你会失败覆盖范围只能覆盖 catch 到的代码路径覆盖所有显式使用 Result 的边界鸿蒙跨端适配平台通道错误类型不一致catch 分支难写统一在边界处转换为业务错误对象1.2 把“错误是否被处理”变成编译期可见的决策我所谓的“防线”核心不是运行时去拦截异常而是让错误处理从“记不记得写”变成“不得不写”。ResultT, E 的含义很直白一个操作要么返回成功值 T要么返回失败信息 E。调用方想拿到成功值就必须先处理失败的可能性。Option 则是另一种常见情况一个值可能不存在比如缓存里读不到 token、配置里没有某个 key、平台通道返回 null这些场景用一个 Option 装起来至少强迫你写 onNone 分支。举个例子老代码里经常这样取 tokenfinal String? token await _channel.invokeMethod(readToken); if (token null) { _gotoLogin(); return; } _requestWithToken(token);这种写法本身没有大问题但问题是真正的崩溃往往发生在“忘记判空”的路径上。如果哪天多了一位新同学把这段代码复制到另一个方法里漏掉 null 判断线上就会出现“Null check operator used on a null value”。改用 Option 后代码长这样final OptionString token Option.fromNullable( await _channel.invokeMethodString(readToken), ); token.when( onSome: (value) _requestWithToken(value), onNone: () _gotoLogin(), );这看起来只是换了个写法实际上是把“可能没有 token”这个事实印在了类型里。token 再也不会被当作一个普通 String 直接使用想要它就必须走 when 的两个分支。这个小小的强制正是压制崩溃异动的第一步。2. df_safer_dart核心API拆解Result/Option在Dart里的形态2.1 ResultT,E与Option 的最小语义df_safer_dart 在类型设计上很接近 Rust 标准库中 Result 和 Option 的思路。Result 有两种构造方式一个表示成功一个表示失败。我在项目里最常用的写法是这样Resultint, String divide(int a, int b) { if (b 0) { return Result.failure(除数不能为 0); } return Result.success(a ~/ b); } void main() { divide(10, 2).when( onSuccess: (value) print(结果: $value), onFailure: (error) print(错误: $error), ); }这段代码里没有 throw没有 try/catch。divide 可能失败的事实直接写在返回类型上调用方想拿到 int 结果就必须在 onSuccess 和 onFailure 两个分支里做选择。Option 的用法类似只不过它只有“有”和“没有”两种状态OptionString findUserName(MapString, Object? data) { final name data[name]; if (name is String) { return Option.some(name); } return Option.none(); }如果 data[name] 不存在或者它不是字符串这个函数返回 none调用方就不会拿到一个看似 String 实则可能 null 的脏数据。2.2 map、mapErr、andThen 这类组合子为什么有用只用 Result 包一层还不够因为真实业务里一个 Result 往往要经历多次变换从接口拿到的实体要转成 DTO网络错误要转成业务错误成功值还要继续被下游消费。如果每个环节都用 if/else 展开代码很快就会比原来的 try/catch 还难读。df_safer_dart 提供的方法就是解决这种链式处理的。map 用于转换成功值mapErr 用于把一种错误类型转换成另一种andThen 用于连续执行可能失败的操作ResultUserProfile, AppError profileResult fetchUserProfile() .map((profile) profile.displayName) .mapErr((error) AppError.from(error));我在项目里经常这样理解map 是对“成功值”做变换mapErr 是对“失败原因”做翻译andThen 是把两个可能失败的操作串在一起。组合子本身不神奇但它们能让业务代码只保留关键路径让错误处理的逻辑集中在最终消费点。2.3 when 模式匹配与 Dart 3 的配合Dart 3 引入的 switch 表达式和对象模式让 Result/Option 用起来更像 Rust 的 match。不过在实际鸿蒙工程里我反而更推荐优先用 when因为 when 的语义对团队所有成员来说最容易读懂。一个失败分支明确列出一个成功分支明确处理值不需要理解底层对象模式细节。final message result.when( onSuccess: (value) 成功: $value, onFailure: (error) 失败: $error, );如果你的项目 Dart SDK 已经足够新也可以尝试用 switch 表达式解构 Result但我个人建议先把 when 用熟因为它不依赖编译器版本的特殊支持代码也更直白。2.4 宏增强功能要谨慎对待df_safer_dart 还提供了一些宏增强能力比如用注解包裹会抛异常的函数自动转成 Result。这个想法很好但 Dart 宏目前仍然属于实验性能力在鸿蒙 Flutter 工程里依赖宏意味着你必须和 SDK 版本绑定得很紧一旦升级 Flutter宏行为可能变化。我的做法是把宏当成一个增强预览真正铺防线时用手写构造足够核心价值来自 Result/Option 类型本身而不是宏。3. 鸿蒙工程接入实操从pubspec配置到真机验证3.1 添加依赖并确认纯Dart边界df_safer_dart 的接入比普通 Flutter 插件省心得多因为它是纯 Dart 实现。在 pubspec.yaml 里加一行依赖就能用dependencies: flutter: sdk: flutter df_safer_dart: ^x.y.z这里我把版本号写成 x.y.z 而不是具体数字因为 pub 上的版本迭代很快你拉到的具体版本可能和我当时不一样API 命名细节也会有小差异。重要的是理解一个原则纯 Dart 库不涉及鸿蒙原生代码不需要修改 module.json5不需要配置 oh-package.json5也不存在平台通道适配问题。相比之下那些需要自己写原生插件的三方库在鸿蒙工程里首先要解决的是有没有鸿蒙实现其次才谈功能合不合用。执行 flutter pub get 之后我在鸿蒙工程里做的第一件事不是写业务代码而是先跑一个最小验证。这样可以确认库文件已经正确进入工程同时排除 pub 镜像、缓存版本等环境问题。3.2 最小可运行验证我在 main.dart 里放了一段最不起眼的逻辑作用是从一个很像鸿蒙缓存结构的 Map 里读取头像路径import package:df_safer_dart/df_safer_dart.dart; void main() { const cache String, Object?{avatar: null}; final OptionString avatar Option.fromNullable(cache[avatar]); avatar.when( onSome: (path) print(使用头像: $path), onNone: () print(没有可用头像), ); }这段代码在鸿蒙模拟器和真机上都能直接跑预期输出是“没有可用头像”。它验证的不只是库里能不能正常编译还验证了所有纯 Dart 依赖在该工程里能正常工作。确认这步没问题之后我才会继续往网络层、缓存层铺 Result。3.3 MethodChannel边界统一包Result鸿蒙 Flutter 工程里最常见也最不可控的崩溃来源就是 MethodChannel 调用。Android 和 iOS 上 PlatformException 的形态相对稳定鸿蒙上则可能遇到错误码字符串、空返回、字段缺失等各种各样的结果。我建议在所有 channel 入口处做一次转换统一包成 Resultclass DeviceInfoRepository { FutureResultMapString, Object?, PlatformFailure getInfo() async { try { final raw await const MethodChannel(app/device) .invokeMapMethodString, Object?(getInfo); return Result.success(raw ?? const {}); } on PlatformException catch (e) { return Result.failure(PlatformFailure(e.code, e.message ?? )); } catch (e) { return Result.failure(PlatformFailure(unknown, e.toString())); } } }这里的关键点是转换动作在通道监听入口完成后续所有业务代码面对的都是 Result不再直接面对 MethodChannel 的各种反常结果。4. 把三类线上崩溃改写成Result/Option防线的完整过程4.1 登录态与Token缓存用Option替代散落的判空第一位在我崩溃列表里反复出现的问题是“缓存里拿到 token 后判空逻辑不一致”。有的方法判 null有的方法判空字符串有的直接把 token 用!解包结果一旦缓存被清线上立刻白屏。用 Option 重构之后逻辑变成OptionString nonEmptyToken(String? raw) { if (raw null || raw.isEmpty) { return Option.none(); } return Option.some(raw); } final OptionString token nonEmptyToken(_store.getString(token)); token.when( onSome: (value) _requestWithToken(value), onNone: () _goLogin(), );单独看这段代码可能会觉得只是把 if 换成 when但放到整个工程里收益在于所有读 token 的地方都遵循同一个模式不再有人能“绕过去”判空直接使用 token。后续如果还要拼接刷新令牌、用户信息等也都天然走 Option 的链式处理。4.2 JSON反序列化把FormatException变成可分类的ParseError第二个高频崩溃点是 JSON 解析。鸿蒙端接口返回的字段结构偶尔和 Android 上不一致某个字段类型说变就变导致 jsonDecode 成功但 fromJson 抛 TypeError或者 jsonDecode 直接抛 FormatException。老代码通常用一层 try/catch 包住但 catch 之后缺少分类UI 层只能收到一个笼统的异常。用 Result 改造后我把解析错误明确分成两类FutureResultOrderEntity, ParseError parseOrder(String raw) async { try { final json jsonDecode(raw) as MapString, dynamic; return Result.success(OrderEntity.fromJson(json)); } on FormatException catch (e) { return Result.failure(ParseError.format(e)); } on TypeError catch (e) { return Result.failure(ParseError.type(e)); } } // 调用方 final result await parseOrder(raw); result.when( onSuccess: (order) _renderOrder(order), onFailure: (error) _showError(error.userMessage), );这样 UI 层不用再去判断“这个异常到底是什么”失败原因已经收敛成业务上可理解的对象上报日志时也能直接记录是格式问题还是字段类型问题。这一类改造对鸿蒙适配尤其重要因为从现场崩溃来看类型不符出现的比例明显比旧平台高。4.3 第三方SDK回执用Result统一错误码和未知异常第三类容易崩溃的是三方 SDK 的回调。鸿蒙上很多扫码、推送、定位 SDK 的回调并不直接抛异常而是返回一个 errorCode 或一段错误描述开发者如果没看文档很容易只处理成功分支把失败分支留成空的。这里我用 Result 做了一个很薄的包装类型class ScanResult { static ResultString, ScanError fromRaw(Object? raw) { if (raw is String) { return Result.success(raw); } if (raw is Map raw[errorCode] is int) { return Result.failure(ScanError.fromCode(raw[errorCode] as int)); } return Result.failure(ScanError.unknown); } }调用方拿到的一定是 Result不可能出现“对象为空但名字上写着 String”的情况。所有失败分支统一走 onFailure既不会漏统计也不会让错误码在某个角落被忽略。在这个环节我想强调一个边界原则不要在项目里把所有函数都改成 Result/Option那样代码会变得非常难读。我只在网络层、缓存层、平台通道、JSON 解析这些真实边界上铺防线内部业务代码保持原来的书写习惯。5. 我踩过的坑与df_safer_dart不能解决的问题5.1 失败分支被静默吞掉的隐患Result 最容易被误解的地方在于它不是运行时异常所以如果 onFailure 分支里什么都不写错误不会冒泡也不会出现在 FlutterError 日志里。这就产生了一个新问题崩溃少了但用户可能安静地停在一个失败状态业务上一点反馈都没有。我建议给项目里的 Result 写一个统一扩展强制每个失败分支至少走一次上报extension ResultLogT, E on ResultT, E { ResultT, E logError(String scene) { when( onSuccess: (_) {}, onFailure: (error) _report(scene, error), ); return this; } }调用时这样用final result await parseOrder(raw).logError(order_parse);这就把“错误被显式接收”和“错误被主动上报”连接起来避免防线变成黑洞。5.2 Dart宏在鸿蒙Flutter工程里要慎用我第一次尝试在鸿蒙工程里直接用宏注解时编译就不太顺利。Dart 宏本身还在实验阶段鸿蒙 Flutter SDK 版本又经常走在自定义分支上两者叠加会让问题排查变得非常困难。最后我还是选择了手写构造 Result 的方式。这不是说宏方案没有价值而是说在鸿蒙这类生态迭代比较快的环境里减少对实验特性的依赖反而能让你把精力集中在错误处理逻辑本身上。5.3 空字符串和空Map不是Option.noneOption 的 none 只代表“这个值不存在”不代表“这个值存在但内容无效”。鸿蒙端从缓存或平台通道取数据时经常出现空字符串和空 Map它们不是 null但业务上等同于无效。我在项目里吃过一次亏某次读取设备信息channel 返回了一个空的 Map我用 Option.fromNullable 包装后以为会走 onNone结果它包装的是一个空 Map最终在解析阶段才暴露出问题。正确的做法是在转换入口就把空值过滤掉OptionString nonEmpty(String? raw) { if (raw null || raw.isEmpty) { return Option.none(); } return Option.some(raw); }5.4 异步回调不await导致的错误链断裂接触鸿蒙推送回调时我发现好多底层返回值看起来像字节数组解析逻辑里又没有做异常收口。有一次数据异常导致页面一直白屏查了半天才发现问题出在回调入口没有转成 Result。结合前面的实战这是我在这个阶段最重要的体会Result 只能解决“错误显式化”的问题解决不了“异步回调没被 await”的漏网但如果你在回调入口处强制返回 Result那么回调函数就只剩下一条成功路径即便出错也有明确的对象可以向上传递。6. 如何让防线可测试、可度量单元测试与崩溃率回归6.1 给Result/Option写单元测试引入类型系统之后测试的价值反而更大了。以前 try/catch 包住的解析函数测试只能验证“没有抛异常”现在可以精确验证失败分支走了哪条路径。比如测试空 token 的过滤import package:flutter_test/flutter_test.dart; import package:df_safer_dart/df_safer_dart.dart; OptionString nonEmpty(String? raw) { if (raw null || raw.isEmpty) { return Option.none(); } return Option.some(raw); } void main() { test(empty token should be none, () { final result nonEmpty(); expect( result.when(onSome: (_) false, onNone: () true), isTrue, ); }); test(valid token should be some, () { final result nonEmpty(abc); expect( result.when(onSome: (v) v, onNone: () ), abc, ); }); }这种测试的效果是把“判空规则”固化到代码里以后任何人修改逻辑只要测试还跑着就不会再出现 token 为空字符串却走成功分支的回归。6.2 用崩溃数据验证防线效果工具铺得再多最终还是要看数据。我当时的做法是统计接入前两周与接入后两周的崩溃日志按“Null check operator”“Bad state”“FormatException”“PlatformException”这几个关键词分桶。结果很明显FormatException 和 Bad state 相关的崩溃比例大幅下降剩下的几类零散异常也大多集中在还没改造完的旧接口上。如果你也在做鸿蒙应用适配建议先挑一条最常崩的链路用 Option 处理可能缺失的缓存字段用 Result 包住接口调用和 channel 返回值跑两周再看数据。我自己的体会是df_safer_dart 没有办法替你消灭异常但它能把可能出错的地方从代码路径的暗处抬到明处让你在几乎失控的新平台上重新获得掌控感。
把存量 Flutter 应用迁到鸿蒙之后我第一周的多数时间不是耗在界面适配而是蹲在崩溃列表里翻异常。就在那段时间我决定在工程里引入 df_safer_dart用 Result/Option 给所有可能失败的边界补一道防线。这个库不像普通插件那样需要改平台工程它不碰鸿蒙原生代码纯粹靠 Dart 类型系统把“这个操作可能失败”变成显式约束调用方要么处理失败分支要么就会在写代码的时候被迫面对它。下面这篇把它的原理、接入过程、实战改造和踩坑经历全部分享出来适合正在做鸿蒙 Flutter 适配、或者想在 Dart 里实践 Rust 风格错误处理的团队参考。1. 为什么鸿蒙Flutter应用要用Result/Option代替裸露的try/catch1.1 默认异常模型在鸿蒙端的三个弱点Dart 的异常模型和 Rust、Go 这类语言完全不同它仍然遵循“抛出—冒泡—捕获”的路子。某个 async 回调里抛了异常只要没有 await 或者没有 catch异常就会一路向上走最终在顶层变成一行 FlutterError 日志。问题在于这种隐式传播非常依赖每个调用者都自觉写 try/catch而实际工程里漏掉的地方远比补上的地方多尤其在鸿蒙这种新平台上代码里到处是从 Android/iOS 抄过来的历史逻辑异常传播路径被各种 Callback、Future、EventChannel 打断原本在旧平台上勉强能工作的结构到了鸿蒙上经常变成“日志里有异常但找不到谁漏接”。鸿蒙 Flutter 工程还有一层额外风险很多三方插件并没有为鸿蒙写完整的原生实现运行时可能走通用通道、可能返回空数据、可能直接抛 MissingPluginException。也就是说同一段业务代码在 Android 上能读到完整的 Map在鸿蒙上拿到的却可能是一个 null或者一个键值对不全的 Map。Dart 空安全能挡住一部分“显式 null”但挡不住“对象存在但内容不符合预期”的情况更挡不住平台通道抛出的异常类型变化。这些都是默认异常模型在鸿蒙端暴露出来的弱点。对比维度裸 try/catchResult/Option错误信号载体运行时异常冒泡函数返回值显式携带调用方感知方式不阅读文档很难知道会抛什么类型签名直接告诉你会失败覆盖范围只能覆盖 catch 到的代码路径覆盖所有显式使用 Result 的边界鸿蒙跨端适配平台通道错误类型不一致catch 分支难写统一在边界处转换为业务错误对象1.2 把“错误是否被处理”变成编译期可见的决策我所谓的“防线”核心不是运行时去拦截异常而是让错误处理从“记不记得写”变成“不得不写”。ResultT, E 的含义很直白一个操作要么返回成功值 T要么返回失败信息 E。调用方想拿到成功值就必须先处理失败的可能性。Option 则是另一种常见情况一个值可能不存在比如缓存里读不到 token、配置里没有某个 key、平台通道返回 null这些场景用一个 Option 装起来至少强迫你写 onNone 分支。举个例子老代码里经常这样取 tokenfinal String? token await _channel.invokeMethod(readToken); if (token null) { _gotoLogin(); return; } _requestWithToken(token);这种写法本身没有大问题但问题是真正的崩溃往往发生在“忘记判空”的路径上。如果哪天多了一位新同学把这段代码复制到另一个方法里漏掉 null 判断线上就会出现“Null check operator used on a null value”。改用 Option 后代码长这样final OptionString token Option.fromNullable( await _channel.invokeMethodString(readToken), ); token.when( onSome: (value) _requestWithToken(value), onNone: () _gotoLogin(), );这看起来只是换了个写法实际上是把“可能没有 token”这个事实印在了类型里。token 再也不会被当作一个普通 String 直接使用想要它就必须走 when 的两个分支。这个小小的强制正是压制崩溃异动的第一步。2. df_safer_dart核心API拆解Result/Option在Dart里的形态2.1 ResultT,E与Option 的最小语义df_safer_dart 在类型设计上很接近 Rust 标准库中 Result 和 Option 的思路。Result 有两种构造方式一个表示成功一个表示失败。我在项目里最常用的写法是这样Resultint, String divide(int a, int b) { if (b 0) { return Result.failure(除数不能为 0); } return Result.success(a ~/ b); } void main() { divide(10, 2).when( onSuccess: (value) print(结果: $value), onFailure: (error) print(错误: $error), ); }这段代码里没有 throw没有 try/catch。divide 可能失败的事实直接写在返回类型上调用方想拿到 int 结果就必须在 onSuccess 和 onFailure 两个分支里做选择。Option 的用法类似只不过它只有“有”和“没有”两种状态OptionString findUserName(MapString, Object? data) { final name data[name]; if (name is String) { return Option.some(name); } return Option.none(); }如果 data[name] 不存在或者它不是字符串这个函数返回 none调用方就不会拿到一个看似 String 实则可能 null 的脏数据。2.2 map、mapErr、andThen 这类组合子为什么有用只用 Result 包一层还不够因为真实业务里一个 Result 往往要经历多次变换从接口拿到的实体要转成 DTO网络错误要转成业务错误成功值还要继续被下游消费。如果每个环节都用 if/else 展开代码很快就会比原来的 try/catch 还难读。df_safer_dart 提供的方法就是解决这种链式处理的。map 用于转换成功值mapErr 用于把一种错误类型转换成另一种andThen 用于连续执行可能失败的操作ResultUserProfile, AppError profileResult fetchUserProfile() .map((profile) profile.displayName) .mapErr((error) AppError.from(error));我在项目里经常这样理解map 是对“成功值”做变换mapErr 是对“失败原因”做翻译andThen 是把两个可能失败的操作串在一起。组合子本身不神奇但它们能让业务代码只保留关键路径让错误处理的逻辑集中在最终消费点。2.3 when 模式匹配与 Dart 3 的配合Dart 3 引入的 switch 表达式和对象模式让 Result/Option 用起来更像 Rust 的 match。不过在实际鸿蒙工程里我反而更推荐优先用 when因为 when 的语义对团队所有成员来说最容易读懂。一个失败分支明确列出一个成功分支明确处理值不需要理解底层对象模式细节。final message result.when( onSuccess: (value) 成功: $value, onFailure: (error) 失败: $error, );如果你的项目 Dart SDK 已经足够新也可以尝试用 switch 表达式解构 Result但我个人建议先把 when 用熟因为它不依赖编译器版本的特殊支持代码也更直白。2.4 宏增强功能要谨慎对待df_safer_dart 还提供了一些宏增强能力比如用注解包裹会抛异常的函数自动转成 Result。这个想法很好但 Dart 宏目前仍然属于实验性能力在鸿蒙 Flutter 工程里依赖宏意味着你必须和 SDK 版本绑定得很紧一旦升级 Flutter宏行为可能变化。我的做法是把宏当成一个增强预览真正铺防线时用手写构造足够核心价值来自 Result/Option 类型本身而不是宏。3. 鸿蒙工程接入实操从pubspec配置到真机验证3.1 添加依赖并确认纯Dart边界df_safer_dart 的接入比普通 Flutter 插件省心得多因为它是纯 Dart 实现。在 pubspec.yaml 里加一行依赖就能用dependencies: flutter: sdk: flutter df_safer_dart: ^x.y.z这里我把版本号写成 x.y.z 而不是具体数字因为 pub 上的版本迭代很快你拉到的具体版本可能和我当时不一样API 命名细节也会有小差异。重要的是理解一个原则纯 Dart 库不涉及鸿蒙原生代码不需要修改 module.json5不需要配置 oh-package.json5也不存在平台通道适配问题。相比之下那些需要自己写原生插件的三方库在鸿蒙工程里首先要解决的是有没有鸿蒙实现其次才谈功能合不合用。执行 flutter pub get 之后我在鸿蒙工程里做的第一件事不是写业务代码而是先跑一个最小验证。这样可以确认库文件已经正确进入工程同时排除 pub 镜像、缓存版本等环境问题。3.2 最小可运行验证我在 main.dart 里放了一段最不起眼的逻辑作用是从一个很像鸿蒙缓存结构的 Map 里读取头像路径import package:df_safer_dart/df_safer_dart.dart; void main() { const cache String, Object?{avatar: null}; final OptionString avatar Option.fromNullable(cache[avatar]); avatar.when( onSome: (path) print(使用头像: $path), onNone: () print(没有可用头像), ); }这段代码在鸿蒙模拟器和真机上都能直接跑预期输出是“没有可用头像”。它验证的不只是库里能不能正常编译还验证了所有纯 Dart 依赖在该工程里能正常工作。确认这步没问题之后我才会继续往网络层、缓存层铺 Result。3.3 MethodChannel边界统一包Result鸿蒙 Flutter 工程里最常见也最不可控的崩溃来源就是 MethodChannel 调用。Android 和 iOS 上 PlatformException 的形态相对稳定鸿蒙上则可能遇到错误码字符串、空返回、字段缺失等各种各样的结果。我建议在所有 channel 入口处做一次转换统一包成 Resultclass DeviceInfoRepository { FutureResultMapString, Object?, PlatformFailure getInfo() async { try { final raw await const MethodChannel(app/device) .invokeMapMethodString, Object?(getInfo); return Result.success(raw ?? const {}); } on PlatformException catch (e) { return Result.failure(PlatformFailure(e.code, e.message ?? )); } catch (e) { return Result.failure(PlatformFailure(unknown, e.toString())); } } }这里的关键点是转换动作在通道监听入口完成后续所有业务代码面对的都是 Result不再直接面对 MethodChannel 的各种反常结果。4. 把三类线上崩溃改写成Result/Option防线的完整过程4.1 登录态与Token缓存用Option替代散落的判空第一位在我崩溃列表里反复出现的问题是“缓存里拿到 token 后判空逻辑不一致”。有的方法判 null有的方法判空字符串有的直接把 token 用!解包结果一旦缓存被清线上立刻白屏。用 Option 重构之后逻辑变成OptionString nonEmptyToken(String? raw) { if (raw null || raw.isEmpty) { return Option.none(); } return Option.some(raw); } final OptionString token nonEmptyToken(_store.getString(token)); token.when( onSome: (value) _requestWithToken(value), onNone: () _goLogin(), );单独看这段代码可能会觉得只是把 if 换成 when但放到整个工程里收益在于所有读 token 的地方都遵循同一个模式不再有人能“绕过去”判空直接使用 token。后续如果还要拼接刷新令牌、用户信息等也都天然走 Option 的链式处理。4.2 JSON反序列化把FormatException变成可分类的ParseError第二个高频崩溃点是 JSON 解析。鸿蒙端接口返回的字段结构偶尔和 Android 上不一致某个字段类型说变就变导致 jsonDecode 成功但 fromJson 抛 TypeError或者 jsonDecode 直接抛 FormatException。老代码通常用一层 try/catch 包住但 catch 之后缺少分类UI 层只能收到一个笼统的异常。用 Result 改造后我把解析错误明确分成两类FutureResultOrderEntity, ParseError parseOrder(String raw) async { try { final json jsonDecode(raw) as MapString, dynamic; return Result.success(OrderEntity.fromJson(json)); } on FormatException catch (e) { return Result.failure(ParseError.format(e)); } on TypeError catch (e) { return Result.failure(ParseError.type(e)); } } // 调用方 final result await parseOrder(raw); result.when( onSuccess: (order) _renderOrder(order), onFailure: (error) _showError(error.userMessage), );这样 UI 层不用再去判断“这个异常到底是什么”失败原因已经收敛成业务上可理解的对象上报日志时也能直接记录是格式问题还是字段类型问题。这一类改造对鸿蒙适配尤其重要因为从现场崩溃来看类型不符出现的比例明显比旧平台高。4.3 第三方SDK回执用Result统一错误码和未知异常第三类容易崩溃的是三方 SDK 的回调。鸿蒙上很多扫码、推送、定位 SDK 的回调并不直接抛异常而是返回一个 errorCode 或一段错误描述开发者如果没看文档很容易只处理成功分支把失败分支留成空的。这里我用 Result 做了一个很薄的包装类型class ScanResult { static ResultString, ScanError fromRaw(Object? raw) { if (raw is String) { return Result.success(raw); } if (raw is Map raw[errorCode] is int) { return Result.failure(ScanError.fromCode(raw[errorCode] as int)); } return Result.failure(ScanError.unknown); } }调用方拿到的一定是 Result不可能出现“对象为空但名字上写着 String”的情况。所有失败分支统一走 onFailure既不会漏统计也不会让错误码在某个角落被忽略。在这个环节我想强调一个边界原则不要在项目里把所有函数都改成 Result/Option那样代码会变得非常难读。我只在网络层、缓存层、平台通道、JSON 解析这些真实边界上铺防线内部业务代码保持原来的书写习惯。5. 我踩过的坑与df_safer_dart不能解决的问题5.1 失败分支被静默吞掉的隐患Result 最容易被误解的地方在于它不是运行时异常所以如果 onFailure 分支里什么都不写错误不会冒泡也不会出现在 FlutterError 日志里。这就产生了一个新问题崩溃少了但用户可能安静地停在一个失败状态业务上一点反馈都没有。我建议给项目里的 Result 写一个统一扩展强制每个失败分支至少走一次上报extension ResultLogT, E on ResultT, E { ResultT, E logError(String scene) { when( onSuccess: (_) {}, onFailure: (error) _report(scene, error), ); return this; } }调用时这样用final result await parseOrder(raw).logError(order_parse);这就把“错误被显式接收”和“错误被主动上报”连接起来避免防线变成黑洞。5.2 Dart宏在鸿蒙Flutter工程里要慎用我第一次尝试在鸿蒙工程里直接用宏注解时编译就不太顺利。Dart 宏本身还在实验阶段鸿蒙 Flutter SDK 版本又经常走在自定义分支上两者叠加会让问题排查变得非常困难。最后我还是选择了手写构造 Result 的方式。这不是说宏方案没有价值而是说在鸿蒙这类生态迭代比较快的环境里减少对实验特性的依赖反而能让你把精力集中在错误处理逻辑本身上。5.3 空字符串和空Map不是Option.noneOption 的 none 只代表“这个值不存在”不代表“这个值存在但内容无效”。鸿蒙端从缓存或平台通道取数据时经常出现空字符串和空 Map它们不是 null但业务上等同于无效。我在项目里吃过一次亏某次读取设备信息channel 返回了一个空的 Map我用 Option.fromNullable 包装后以为会走 onNone结果它包装的是一个空 Map最终在解析阶段才暴露出问题。正确的做法是在转换入口就把空值过滤掉OptionString nonEmpty(String? raw) { if (raw null || raw.isEmpty) { return Option.none(); } return Option.some(raw); }5.4 异步回调不await导致的错误链断裂接触鸿蒙推送回调时我发现好多底层返回值看起来像字节数组解析逻辑里又没有做异常收口。有一次数据异常导致页面一直白屏查了半天才发现问题出在回调入口没有转成 Result。结合前面的实战这是我在这个阶段最重要的体会Result 只能解决“错误显式化”的问题解决不了“异步回调没被 await”的漏网但如果你在回调入口处强制返回 Result那么回调函数就只剩下一条成功路径即便出错也有明确的对象可以向上传递。6. 如何让防线可测试、可度量单元测试与崩溃率回归6.1 给Result/Option写单元测试引入类型系统之后测试的价值反而更大了。以前 try/catch 包住的解析函数测试只能验证“没有抛异常”现在可以精确验证失败分支走了哪条路径。比如测试空 token 的过滤import package:flutter_test/flutter_test.dart; import package:df_safer_dart/df_safer_dart.dart; OptionString nonEmpty(String? raw) { if (raw null || raw.isEmpty) { return Option.none(); } return Option.some(raw); } void main() { test(empty token should be none, () { final result nonEmpty(); expect( result.when(onSome: (_) false, onNone: () true), isTrue, ); }); test(valid token should be some, () { final result nonEmpty(abc); expect( result.when(onSome: (v) v, onNone: () ), abc, ); }); }这种测试的效果是把“判空规则”固化到代码里以后任何人修改逻辑只要测试还跑着就不会再出现 token 为空字符串却走成功分支的回归。6.2 用崩溃数据验证防线效果工具铺得再多最终还是要看数据。我当时的做法是统计接入前两周与接入后两周的崩溃日志按“Null check operator”“Bad state”“FormatException”“PlatformException”这几个关键词分桶。结果很明显FormatException 和 Bad state 相关的崩溃比例大幅下降剩下的几类零散异常也大多集中在还没改造完的旧接口上。如果你也在做鸿蒙应用适配建议先挑一条最常崩的链路用 Option 处理可能缺失的缓存字段用 Result 包住接口调用和 channel 返回值跑两周再看数据。我自己的体会是df_safer_dart 没有办法替你消灭异常但它能把可能出错的地方从代码路径的暗处抬到明处让你在几乎失控的新平台上重新获得掌控感。
