在 Web 与移动端保持一致的加载、错误与空状态

为什么这些状态很快就会变得混乱

加载、错误和空状态是当应用在等待、某些操作失败或没有可显示内容时，用户看到的屏幕（或小的 UI 模块）。它们是常态：网络会慢、权限会被拒绝，新账号会从零数据开始。

之所以会混乱，是因为它们通常在开发后期被快速补上。团队先做出顺畅的主路径，然后在各处补上一个加载转圈、一个红色错误信息和一个“无项目”占位。跨几十个屏这么做，最终你会得到一堆各不相同的单例实现。

快速迭代让情况更糟。当 UI 被迅速产出（包括 AI 生成的 UI）时，主布局可能几分钟就出来了，但这些状态很容易被跳过。每个新屏都会出现不同的转圈样式、不同的措辞（“Try again” vs “Retry”），以及按钮位置不一致。你起初获得的速度，最终会在上线前变成大量修饰工作。

状态不一致会让用户困惑，也会拖慢团队。用户无法区分一个空列表是“没有结果”、“还没加载”还是“你没有权限”。QA 要测试大量细微差异，且因为 web 与移动间行为不同，漏洞会漏掉。

“混乱”常常表现为：

• 加载在一个屏幕隐藏了操作，但在另一个屏幕没有隐藏。
• 错误有时阻塞页面，有时只是小字提示。
• 空状态使用不同的语气、图标和后续动作。
• web 与移动对同一操作使用不同的标签。

目标很简单：在 web 与移动之间采用一种共享方案。如果团队快速生成功能（例如使用像 Koder.ai 这类平台），共享的状态模式就更重要，因为每个新屏默认就应该是连贯的。

值得先统一的 5 类状态

大多数应用在相同的地方反复遇到问题：列表、详情页、表单、仪表盘。这些地方会产生大量的转圈、横幅和“什么都没有”的消息。

先命名并统一五类状态：

• 初次加载（Initial loading）：屏幕第一次打开、还没有任何数据时。
• 刷新/更新（Refreshing / updating）：屏幕已有数据，但正在请求更新的数据。
• 空的基线（Empty baseline）：确实没有任何内容（新账号、新工作区、未创建条目）。
• 零结果（Zero results）：数据存在，但过滤或搜索没有返回任何结果。
• 错误（Error）：请求失败、权限阻止访问或出现故障。

有两个特殊情况需要单独规则，因为它们的表现不同：

• 离线（Offline）：尽可能显示缓存内容，并明确写出 “You’re offline”。
• 慢网络（Slow network）：避免快速闪现错误；在短延时后切换到 “Still loading…”（或类似提示）。

在屏幕与平台间保持结构一致：状态出现的位置、图标风格、语气和默认动作（Retry、Refresh、Clear filters、Create）。可以变化的是上下文：屏幕名称和使用用户语言的一句话说明。

示例：如果你为 “Projects” 生成了 web 列表和移动列表，它们应当共享相同的零结果模式。动作标签仍可以按照平台调整（“Clear filters” vs “Reset”）。

构建一个小型状态套件，而不是一次性实现

如果每个屏幕都自己发明转圈、错误卡和空消息，你最终会得到十几种略有差异的版本。最快的解决法是制作一个小型的“状态套件”（StateKit），任何功能都能直接引入。

从三个可复用组件开始：Loading、Error、Empty。刻意让它们看起来“无聊”。它们应该易于识别且不与主 UI 竞争注意力。

通过定义一组小的输入，使组件可预测：

• 标题（短且具体）
• 消息（一到两句）
• 主要动作标签
• 主要动作处理器（重试、刷新或下一步）
• 可选细节（错误码、次要动作）

然后固定视觉规范。一次决定间距、排版、图标大小与按钮样式，并把它当作规则。当图标大小和按钮类型保持一致时，用户就不会注意状态 UI，而会信任它。

保持变体数量有限，避免把套件变成第二套设计系统。三种尺寸通常足够：小（内联）、默认（区块）与全页（阻塞）。

如果你在 Koder.ai 中生成屏幕，一句简单指令例如 “use the app StateKit for loading/error/empty with default variant” 就能避免漂移。它还能减少 React web 与 Flutter mobile 在发布前的收尾工作。

编写一致的状态文案

文案是系统的一部分，不是装饰。即便布局一致，随意的措辞也会让屏幕感觉不同。

选择统一语气：简短、具体、冷静。用平实的语言说明发生了什么，然后告诉用户接下来该做什么。多数屏幕只需一个清晰标题、一句短说明和一个明显动作。

使用模板，避免团队即兴发挥

几个消息模式即可覆盖大部分情形。保持简短以适配小屏：

• 网络：“Can’t connect” + “Check your internet and try again.” + 动作：“Retry”
• 超时：“Taking longer than expected” + “The request timed out.” + 动作：“Try again”
• 权限：“Permission needed” + “Allow access to continue.” + 动作：“Open settings”
• 未找到：“Nothing here” + “This item may have been removed.” + 动作：“Back”
• 校验：“Fix one thing” + “Add a valid email address.” + 动作：“Save”

避免单独使用模糊文本如 “Something went wrong”。如果确实不知道原因，就说明你知道的那部分并告诉用户下一步能做什么。“We couldn’t load your projects” 比单纯写 “Error” 要好。

让下一步动作可预测

设一条规则：每个错误与空状态都应提供下一步。

• 若用户能恢复，提供 “Retry” 或 “Refresh”。
• 若为空是由过滤器引起，建议 “Clear filters”。
• 若被权限阻止，明确告诉用户去哪里更改设置。

这在 AI 生成 UI 场景下尤其重要，因为屏幕出现得很快。模板让文案一致，避免在最终打磨阶段重写数十条一次性消息。

让动作可预测：重试、刷新与下一步

当状态屏在不同页面提出不同动作时，用户会犹豫。团队往往在上线前才去微调按钮与文案。

决定每种状态应对应的动作，并保持位置与标签一致。多数屏应只有一个主要动作。若有第二个动作，应支持主路径而非与之竞争。

一个可扩大的小型动作映射

把允许的动作保持紧凑：

• Loading：通常无动作（对用户发起的长任务可选 “Cancel”）。
• Empty：当用户可以添加内容时提供 “Create”；当过滤器导致空结果时提供 “Adjust filters”。
• Error：临时失败提供 “Retry”；陈旧数据提供 “Refresh”；仅在阻塞工作流时才给出 “Contact support”。
• 成功但数据无变更：提供 “Back” 或 “Done”。

无聊的按钮是优点。它们让 UI 熟悉，并帮助生成的屏幕保持一致。

重试与错误细节规则

仅在重试可能奏效时显示 “Retry”（超时、不稳定网络、5xx）。对重复点击做短暂防抖，重试时把按钮切换为加载状态。

多次失败后，保持同样的主要按钮，同时强化次要帮助（例如“检查连接”提示或“稍后再试”）。避免因为失败两次就完全换新布局。

针对错误详情，展示用户可采取行动的明确原因（例如 “Your session expired. Sign in again.”）。默认隐藏技术细节；若需要，按跨平台一致的方式把它们收纳到 “Details” 的可交互项下。

示例：当 “Projects” 列表在移动端加载失败，两端都显示相同的主要 “Retry” 操作，在重试时禁用并显示加载状态，若失败两次则添加一个小的连接提示，而不是改变整个按钮布局。

推出该系统而不阻碍团队速度

把状态一致性当作小范围的产品改进，而不是重设计。渐进式推进，降低采用成本。

从快速盘点现有实现开始。不求完美，记录常见变体：骨架屏与骷髅屏、全页错误与横幅、“无结果”页面的不同语气等。

一个实用的推广计划：

• 清点 15 到 30 个关键屏（web 与移动），归类最常见的模式。
• 先支持 3 到 4 个典型位置（全页、区块、内联、toast）。
• 为 web 与 mobile 构建匹配组件，确保 props 与命名一致。
• 写简短使用规则，让新屏从套件中选择而不是发明新版本。
• 每次替换一个产品区域（搜索、收件箱、计费），保持发布安全。

组件建成后，真正节省时间的是一套短规则，能避免在“页面是否被阻塞”或“必须提供哪些动作”上产生争论。

把规则保持简短：

• 每个错误都要显示一个明确的下一步（retry、refresh 或 contact support）。
• 空状态要提供一个主要动作（create、import 或 explore）。
• 加载状态在数据到达时不要跳动布局。

如果你用 AI UI 生成器比如 Koder.ai，这些规则会很快带来收益。你可以提示 “use the state kit components”，生成的 React web 与 Flutter mobile 屏幕会更少需要清理。

常见错误，会导致上线前大量修饰工作

后期修饰工作通常来自于状态处理被当成一次性实现。屏幕“能用”，但每次出现等待、失败或无数据时体验却各不相同。

让人觉得卡住的加载

骨架屏有帮助，但显示时间太长会让人以为应用死了。常见原因是在慢请求上一直显示完整骨架却没有任何进度暗示。

设定时限：短延时后切换到更轻的 “Still loading…” 提示，或在可能时显示进度。

文案在各处漂移

团队常常每次都写一条新消息，即使问题相同。 “Something went wrong”、“Unable to fetch” 与 “Network error” 可能描述同一类情况，但读起来不一致，也增加客服难度。

为每类错误选一个标签并在 web 与移动间重用，语气与细节级别保持一致。

空、错误与未加载的混淆

另一个典型错误是数据还没加载完就显示空状态，或在请求失败时显示 “No items”。用户会做错事（例如添加内容），而实际上应该重试。

把决策顺序明确化：先判断 loading，再判断 error，最后在确认请求成功且无数据时显示 empty。

缺失或过载的动作

没有恢复动作的错误会造成死路。相反，三颗争注意力的按钮也很常见。

保持精简：

• 错误默认一个主要动作（通常为 “Retry”）。
• 空状态提供一个明确的下一步。
• 仅在必要时提供次要动作。

平台间的视觉不匹配

小差异会累积：图标风格、内边距、按钮形状。这也是 AI 生成 UI 如果提示在不同屏不一致时会偏离的地方。

锁定状态组件的间距、图标集与布局，让每个新屏继承相同结构。

关于加载行为与无障碍的实用规则

若想在 web 与移动间统一状态处理，需要把“无聊”的规则写清楚。大多数后期修饰来自每个屏自己定义加载行为、超时与标签。

让加载感觉更快的规则（即便实际上不快）

对整页加载，选一个默认：内容密集的屏（列表、卡片、仪表盘）用骨架屏；对短等待且布局未知的情况用转圈。

加入超时阈值，避免界面无声挂起。若加载超过 8 到 10 秒，切换到清晰提示并显示可见动作如 “Retry”。

对局部加载，不要把屏幕清空。保持已有内容可见，在更新的区块附近显示小型进度指示（例如头部一条细条或内联转圈）。

对缓存数据，优先采用 “陈旧但可用”。立即显示缓存内容并添加细微的 “Refreshing…” 指示，让用户知道数据可能会变化。

离线是独立状态。直接说明，并写出还能做什么。例如：“You’re offline. You can view saved projects, but syncing is paused.” 提供单一下一步如 “Try again” 或 “Open saved items”。

可应用于各处的无障碍基本原则

保持跨平台一致：

• 焦点顺序：状态出现时把焦点移动到消息与主要动作上。
• 屏幕阅读器标签：用清晰简短的文本播报加载与错误。
• 点击目标：确保按钮在移动端易于点击，避免很小的内联链接。
• 动效：让转圈低调，不要只靠动画传达信息。
• 颜色：不要仅用颜色作为唯一信号（配合文字与图标）。

如果你用像 Koder.ai 这样的工具生成 UI，把这些规则烙进共享 StateKit，可让每个新屏默认保持一致。

示例：一个功能、三个状态、两个平台

想象一个简单的 CRM，有联系人列表与联系人详情页。如果把加载、错误与空状态都当作一次性实现，web 与移动会迅速偏离。一个小系统能在快速产出时保持对齐。

首次空状态（Contacts 列表）： 用户打开 Contacts 却还没有内容。web 与移动都保持标题一致（“Contacts”）、空状态说明原因（“No contacts yet”），并提供一个明确的下一步（“Add your first contact”）。如果需要额外设置（比如连接收件箱或导入 CSV），空状态应指向确切步骤。

慢网络加载： 用户打开联系人详情页。两端都显示与最终页面结构匹配的可预测骨架（头部、关键字段、备注）。返回按钮仍可用，页面标题可见，避免在不同位置随机放置转圈。

服务器错误： 详情请求失败。web 与移动显示相同模式：简短标题、一句说明和主要动作（“Retry”）。若重试再次失败，提供第二个选项如 “Go back to Contacts”，避免让用户被困住。

保持一致的内容很简单：

• 位置：消息置于内容区，动作在明显位置。
• 文案：相同语气、相同按钮标签（Retry、Add contact）。
• 行为：骨架触发条件相同，重试规则一致。
• 安全性：加载时禁用重复动作。

上线前的快速检查清单

一个版本看起来“完成”直到有人遇到慢网、新账号或不稳定 API。此清单帮助你在不把 QA 变成寻物游戏的情况下发现最后一公里问题。

UI 一致性检查

从列表屏开始，因为它们会成倍增长。挑三个常见列表（搜索结果、已保存项、最近活动），确认它们都使用相同的空状态结构：清晰标题、一句有用的说明和一个主要动作。

确保空状态永远不会在数据仍在加载时出现。如果你短暂闪现 “Nothing here yet” 然后被内容替换，用户信任会迅速下降。

检查加载指示的一致性：尺寸、位置与合理的最短显示时间，防止闪烁。如果 web 显示顶部条形转圈而移动显示同屏骨架，用户会感觉像是两个不同产品。

错误与 QA 检查

错误应始终回答 “接下来怎么办？” 每个错误都需要一个下一步：重试、刷新、修改过滤、重新登录或联系客服。

发布前的快速自查列表：

• 空状态：在列表屏间保持相同布局、图标风格与语气。
• 加载：不要过早替换为空，指示器在各端匹配。
• 错误：每个错误屏或 toast 都要有一个明确的主要动作。
• 文案规则：平台间措辞模式一致（标题、标点、按钮动词）。
• QA 脚本：一套简短可重复的步骤来触发加载、空与错误状态。

如果你使用 Koder.ai 生成屏幕，这些检查显得更重要，因为屏幕可以很快产出，但一致性仍依赖共享套件与共享文案规则。

接下来：随着应用增长保持一致

当一致性成为日常工作的一部分时，就最容易做到，而不是在事后大清洗。每个新屏都应该无需有人记得“让它对齐”，就能使用相同模式。

把状态行为纳入完成定义（definition of done）。屏幕未包含加载状态、空状态（如适用）与带明确动作的错误状态前，不应视为完成。

把规则保持轻量并写下来。一份包含几张截图与精确文案模式的短文档通常足够。把新变体视为例外。当有人提出新的状态设计时，问问它是否真的是新场景，还是能放进已有套件。

若要重构大量屏幕，分步骤降低风险：一次更新一个流程，在 web 与移动上验证，然后继续。在 Koder.ai 中，快照与回滚能让大改更安全，规划模式能帮助定义共享 StateKit，使得新生成的屏从第一天起就符合默认规则。

一个可行的推进方法

本周选一个因状态问题导致后期修饰的区域（通常是搜索结果、引导或活动流）。然后：

• 把状态需求加入该区域的验收清单。
• 用共享组件替换一次性状态。
• 在文档中记录 2 到 3 个示例（好与差）。
• 做一次跨平台审查（语义相同、动作相同、布局相似）。
• 追踪下个冲刺中需要修复的 UI polish 工单数量并比较。

一个具体的有效信号是：像 “add retry”、“empty state looks weird” 或 “loading spinner blocks the page” 这类“小”工单显著减少。

明确责任

为状态标准指定一个统一负责人（设计师、技术负责人或两者）。他们不需审批所有改动，但应保护套件不被慢慢拆散成看似相似却行为不同的新变体，这些都会在后期造成额外成本。