鸿蒙应用里的空状态不要再写散落的 if：一个可复用组件的做法

在鸿蒙应用里，空状态几乎无处不在：没有收藏、没有订单、搜索无结果、网络异常、权限未开启。最常见的写法，是在每个页面里各自写一套判断和布局。页面一多，文案、间距、按钮样式就开始各不相同，改一处就要翻遍整个工程。本文用一个可复用的空状态组件，把这些散落的逻辑收拢起来。

一、先把空状态分成四类

不要一上来就画界面，先把状态说清楚。实践中常见的有四类：第一是数据为空，例如列表还没有任何内容；第二是搜索无结果，用户输入了条件但没有匹配项；第三是操作失败，例如网络异常或加载失败，需要给用户重试入口；第四是功能受限，例如未登录或未开启权限，需要引导用户去完成前置步骤。分类的好处是，后续的文案和操作可以按类别复用，而不是每个页面重新发明。

二、组件只接收描述，不做业务判断

一个好的空状态组件，应该只负责展示，不负责判断业务。建议用四个参数来描述它：标题、说明文字、操作按钮文字，以及按钮点击后的回调。页面层负责判断当前属于哪一类，并把对应的描述传进来。这样一来，组件本身没有网络请求，没有路由跳转，也没有权限逻辑，任何页面都可以直接使用，改样式也只需要改一个地方。

三、状态来源要唯一

很多空状态出问题，不是因为界面难写，而是因为状态来源太多：有的页面用列表长度判断，有的用加载标志判断，有的用错误码判断，结果同一个页面可能同时出现加载中和空状态。建议在页面层先算出一个统一的页面状态，例如加载中、成功且有数据、成功但无数据、加载失败，然后再根据这个状态决定显示列表、空状态还是错误提示。状态唯一，界面就不会打架。

四、给组件留出可测试的边界

空状态组件的可测试性，往往来自于它的简单。测试时不需要真的发起网络请求，只需要传入不同的标题、说明和按钮文字，检查它们是否正确显示；点击按钮时，检查回调是否被调用一次。页面层的测试则关注状态计算：空列表是否映射为空状态，请求失败是否映射为可重试状态。把展示和判断分开，测试用例也会更清晰。

五、容易踩的几个坑

第一，不要把空状态和加载状态混在一起，用户在等待时不应该看到无数据的提示。第二，操作按钮要有明确结果，重试就真的重新请求，去开启权限就真的打开对应入口，不要只做样子。第三，文案不要写得太技术化，例如直接展示错误码，用户看不懂，也不知道下一步该做什么。第四，空状态也要考虑无障碍和深色模式，文字对比度和点击区域不能只在浅色模式下验证。

结语

空状态不是页面的边角料，它是用户在没有数据时最先看到的内容。把四类状态说清楚，让组件只接收描述，让页面层统一计算状态，再把展示和判断分开测试，空状态就会从散落的判断，变成一套稳定、可复用的能力。先从一个页面开始替换，确认文案、间距和按钮行为一致后，再逐步推广到其他页面，收益会比一次性重构更可控。