异常捕获与页面兜底

很多功能第一版都能跑，但“能跑”和“做稳”之间还有一段距离。异常捕获与页面兜底就是这种很容易被忽略、后期又经常返工的问题。

这一篇不堆 API。我们从真实开发场景切入，先看为什么会出问题，再写一个最小实现，然后补连续操作、异常路径和生命周期。目标不是把代码写得花，而是让下一次需求变化时还能放心改。

1. 先看最常见的误区

开发时最容易只盯结果：按钮点了有反应、页面能跳、数据出来了，就认为这一块结束了。真实项目里，用户连续点击、快速返回、切后台、内容突然变长，才是问题集中出现的时候。

所以我更建议先问三个问题：这段行为由什么状态驱动？中途失败后怎么恢复？页面离开后还有没有任务继续执行？

这三个问题想清楚，很多“偶现 bug”会少一半。

2. 先写最小核心

try { await this.loadData() } catch (e) { this.showFallback = true }

示例故意保持短。先让行为可验证，再决定是否抽组件或工具层。过早抽象往往只是把简单问题分散到更多文件里。

3. 状态来源必须清楚

一个状态最好有明确的拥有者。父组件和子组件都随意修改，同一个异步回调又再改一次，出了问题就很难查。

局部行为尽量让局部组件自己管理；真正影响整个页面的状态再提升。这个原则放到动画、手势、日志、配置、测试里都成立：职责越明确，排错越快。

4. 连续操作比第一次操作更重要

第一次通常没问题。真正值得测的是连续点五次、操作一半返回、失败以后再来一次。

如果逻辑存在处理中状态，记得防重复，并在所有路径恢复：

this.processing = true
try {
  await this.doWork()
} catch (e) {
  console.error('[异常别等线上才发现] failed')
} finally {
  this.processing = false
}

finally 没什么炫技，但它能解决很多“第二次为什么不工作”的问题。

5. 生命周期别忘了

页面离开以后，定时器、监听、异步任务、动画回调是否还需要继续？这是很实际的问题。

创建时注册的能力，要想清楚什么时候释放。页面已经不可见时还频繁更新状态，不仅浪费资源，也可能制造难复现的问题。

6. 调试时别先清缓存

我一般沿调用链查：事件触发了吗？方法进入了吗？状态改了吗？异步有没有异常？生命周期是不是已经变化？

日志尽量短，并带模块名。敏感数据不要打印，大对象也不要每次整包输出。真正需要的是能快速判断“代码走到哪一步”。

7. 别为了高级而高级

异常别等线上才发现并不意味着效果越复杂越好。交互反馈应该克制，工程封装也应该克制。

一个简单功能拆十层，不叫工程化；每个按钮都加一堆动画，也不叫体验好。能让用户明确感知、能让开发者快速理解，就是更实用的标准。

8. 给失败留一条路

成功路径大家都会写，真正拉开质量差距的是失败以后发生什么。

任务失败后状态能不能回去？页面有没有兜底？用户能不能重试？资源有没有释放？这些都应该在写功能时一起考虑，而不是上线前补。

9. 把边界场景主动造出来

把文本改成长一点，把数据变成空，把操作速度加快，把页面快速切走。不要等测试同学帮你发现所有边界。

开发阶段主动“破坏”一次自己的功能，通常能提前发现不少布局、状态和生命周期问题。

10. 代码审查时我会看什么

第一，职责能不能一句话说清。第二，失败后是否恢复。第三，离开页面后是否还有无意义任务。第四，改需求时需要动多少地方。

如果一个小改动需要全局搜索十几个文件，通常说明边界已经开始模糊。

11. 用户看到的是结果，不是架构

用户不知道你用了什么模式，他们只知道点击有没有反馈、页面会不会卡、失败后能不能继续。

工程治理也是一样。日志、测试、资源管理用户看不见，但这些东西决定了线上故障能不能更少、定位能不能更快。

12. 示例代码不是万能模板

教程为了讲清一个点会省略很多业务上下文。放进自己的项目时，要结合团队已有结构调整。

真正值得带走的是判断方法：为什么放这里、为什么要恢复、为什么要拆或不拆。理解这些，比复制一段代码更有用。

总结

这一篇围绕 异常捕获与页面兜底，核心不是记 API，而是建立稳定的开发顺序：先确认职责和状态，再写最小实现，然后补异常、连续操作和生命周期。HarmonyOS 7 的能力本身并不难调用。真正让项目越来越稳的，是这些看起来不起眼的工程习惯。从现有项目找一个最接近本篇的功能，只改一个最明显的问题。改完后连续操作五次，再快速切页返回一次，看看状态和体验是否仍然正常。