跨平台 UI 一致性检查清单，用于网页与原生应用

什么是 UI 一致性（以及为什么它这么容易被打破）

UI 一致性意味着你的网页应用和原生移动应用给人的感觉像同一款产品。不是逐像素相同，而是在含义、期望和用户在点击、输入或等待时得到的结果上保持一致。

一个简单的测试：如果用户在一个屏幕学到了一件事，那么他们应该能把这个经验迁移到另一个平台上等效的屏幕。

通常是小差异让人卡壳。如果网页上的按钮写着“保存”，而移动端写着“完成”，用户会停顿。如果某个平台的间距更紧张，同样的功能会让屏幕感觉更压迫。如果在移动端点击列表行会打开详情，而在网页端则显示复选框，用户就会开始猜测而不是信任界面。

哪些内容应当完全匹配？任何影响理解和信心的东西。对大多数产品来说，这包括：

• 相同行为的名称和标签，以及它们出现的位置
• 关键屏幕的核心布局（导航、主要操作、重要信息）
• 加载、错误、禁用和空结果等状态
• 组件行为（点击、滑动、长按、键盘、焦点）
• 信息的语气和结构（发生了什么、下一步做什么）

什么可以适配？那些主要关于各平台舒适度的东西。字体渲染、安全区和像 iOS 返回手势或 Android 系统按钮这样的原生模式可以不同，只要用户仍能到达相同位置并理解变化即可。

一个实用目标是“可预测的模式”。如果用户在网页上更新了个人资料，他们在移动端也应该能认出相同的字段、相同的校验规则和相同的成功信息。即便你用像 AppMaster 这样的工具快速构建（网页 UI 加原生 iOS/Android UI），一致性仍然需要明确规则，这样应用才能朝着同一个方向发展，而不是变成两款相似但不同的产品。

在对比屏幕前先设定共享基线

当每个平台都以不同的“正确”标准来衡量时，一致性评审就会瓦解。在比较网页和原生屏幕之前，先达成共识并把“相同”写下来。虽然不有趣，但能避免大量返工。

你不需要庞大的规范。你需要一些能阻止最常见偏差的规则：

• 排版：字号、行高以及文本如何换行或截断
• 间距：内边距、外边距、网格步长以及何时使用紧凑或舒适布局
• 色彩角色：primary、danger、muted、最低对比度以及暗色模式预期
• 组件：被“批准”的按钮、输入、卡片和导航模式
• 状态：加载、错误、空、禁用和成功反馈

接着，选一个唯一的事实来源。有些团队使用设计文件；另一些依赖 tokens 加简短书面指南。重要的是规则只出现在一个地方，并记录变更。如果你使用 AppMaster，最好在 web 与移动 UI 构建器中对齐 tokens 和可复用组件，这样相同的选项会在各处出现。

最后，设定节奏与负责人。把一致性当作测试对待，而不是临发行前的润色。决定何时进行评审（发布前和共享组件变更后）、谁来签核（设计负责视觉，产品负责意图，QA 负责边界情况和设备覆盖），以及“完成”意味着什么（不匹配被修复或被明确接受并说明理由）。

示例：如果客户门户新增了“发票”页面，事先决定移动端表格如何折叠、空状态如何说明缺失发票以及设备离线时“立即付款”按钮的行为。有了基线，评审就变成快速检查偏差，而不是关于品味的争论。

在各平台保持一致的排版规则

排版是“几乎相同”迅速变成“感觉像不同产品”的地方。先用简单的 token 给样式命名（H1、H2、Body、Caption），并在 web 与原生上以相同方式应用它们。

选择对平台友好的字体族。每个平台使用一套主要字体以匹配相同的气质和密度，然后定义回退。例如：iOS 使用系统字体（SF），Android 使用系统字体（Roboto），网页使用一个相似的 web 字体并回退到 system-ui。目标不是字形完全一致，而是语气和可读性一致。

只定义一次字号刻度，并保持足够小以避免有人发明新尺寸。例如：

• H1：28-32px，行高 1.2-1.3
• H2：20-24px，行高 1.25-1.35
• Body：16px，行高 1.4-1.6
• Secondary：14px，行高 1.4-1.6
• Caption：12-13px，行高 1.3-1.5

文本行为与尺寸同等重要。决定如何处理长标题和不可预测的数据（姓名、地址、工单主题），以免网页和移动端产生偏差：

• 标题：最多 2 行，超出用省略号截断
• 表格单元：单行截断，点击/悬停显示完整值
• 段落：自然换行，不在词中断行
• 数字：如可用使用等宽数字，保持小数点对齐

对齐方式也是常见不匹配点。默认左对齐大部分文本，尤其是表单和列表。仅在简短且单一用途的场景（如成功信息或空状态标题）使用居中。

设定无障碍最低要求并视为不可协商。移动端主文本建议至少 16px，避免在小字号使用过细字重，并保持足够高的对比度以便在强光下也能阅读。如果你使用 AppMaster，将这些作为共享设计 tokens 可以让相同的屏幕在 web 与原生上都有一致的阅读效果。

间距与布局规则（含移动安全区）

间距是“几乎相同”变成“感觉不同”的关键。如果网页屏幕有呼吸感，但移动端显得拥挤，用户会在意，即便颜色和字体匹配。

从双方都使用的一个间距刻度开始。简单的以 4 为基准的刻度能很好地映射到 CSS 和原生布局网格。保持规则简单：相关项间隙较小，独立章节间隙较大，默认屏幕内边距固定，且例外情况少且有文档记录。

一个典型基线如下：

• 共享步长：4、8、12、16、24
• 相关元素间隙：8-12
• 章节间隙：16-24
• 默认屏幕内边距：16

然后在移动端标准化安全区。内容不应出现在刘海、Home 指示器或系统栏下。一个清晰规则是：“所有主要内容遵循安全区 + 基础内边距。”如果有底部栏，要把它的高度包含在内容内边距里，这样最后一行列表仍可触达。

列表密度也需要明确选择。选两个方案并命名（紧凑与舒适），定义行高、垂直内边距和分割线使用。在同一类屏幕上 web 与移动采用相同选项，这样“发票列表”不会给人两种无关的设计感觉。

触控目标也是间距的一部分。在移动端，即便布局紧凑，控件也应易于点击。一个实用的最小值是 44x44，并在动作间保留足够间距以防误触。

在网页端，为关键断点写下响应式行为：列数、侧栏行为，以及列表何时变成卡片。在一致性评审中，比较的是意图而非像素。网页可以同时展示更多内容，但不应改变信息层级或隐藏关键操作。

如果在 AppMaster 中构建，在 web 与移动 UI 构建器中使用相同的间距 tokens 能让屏幕默认更一致。

状态：加载、错误、禁用与空屏

一致性常在状态处破裂，而不是在“愉快路径”上。把状态 UI 作为一级设计，确保 web 与原生在结构、语气和操作上一致。

从操作开始。主要操作应明显且位置一致（例如网页对话框右下角，移动端为粘性底部按钮）。次要操作不应与主要操作争夺注意力。破坏性操作需要额外摩擦：明确标签（“删除项目”）、确认步骤和安全的退出方式（“取消”）。

禁用的控件不应让人以为是错误。只有当动作确实无法执行时才使用禁用，并在控件附近解释原因。帮助性文案比移动用户看不到的 tooltip 更有效。如果用户可以修复，就说怎么做（“添加付款方式以启用结账”）。如果不能，就说明何时会解锁（“审核通过后可用”）。

加载规则

为每种上下文选择一种加载模式并保持稳定：

• 对会在原位出现的页面内容（表格、卡片、列表）使用骨架屏。
• 对短时阻塞等待（登录、提交表单）使用加载圈（spinner）。
• 将指示器放在用户视线所在位置：他们点的按钮内，或正在变化的内容区域。
• 通过为关键元素（标题、主按钮）预留空间，防止布局跳动。

错误与空状态规则

错误要具体、冷静且可恢复。尽可能把信息放在问题旁（字段层级）。否则用横幅或对话框，并提供一个明确的恢复操作：“重试”、“编辑详情”或“联系支持”。避免指责用户。

空状态用可复用的模板效果最好：简短标题、一句指导，以及一个与用户期望下一步一致的主要操作。示例：在用 AppMaster 构建的客户门户中，“发票”为空时可以写“暂时没有发票”，并将“创建发票”作为 CTA，保持 web 与移动端的用词和行为一致。

组件行为规则（不仅仅是外观）

两个屏幕可能看起来很像，但感觉仍可能不同。行为是用户首先注意到的：双击会怎样、错误如何出现、“返回”会带到期望的位置。你的一致性检查清单应覆盖交互规则，而不仅仅是颜色和字体。

为核心组件定义交互规则

为每个组件写下一条核心原则，然后根据各平台的模式映射，不改变最终结果：

• 按钮：定义按下反馈（水波、高亮、触觉反馈）、长按是否有额外功能，以及如何防止重复提交（短时禁用或直到请求返回）。
• 表单：决定何时触发校验。很多团队对邮箱在 blur 时校验，而可选字段只在提交时显示错误。保持内联错误的位置一致，并始终聚焦第一个无效字段。
• 列表：选择主要刷新模式。移动端可能使用下拉刷新，而网页端使用刷新按钮，但两者应更新相同数据并保持滚动位置可预测。还要选择分页方式：分页编号、“加载更多”或无限滚动之一。
• 导航：让返回行为匹配意图，而不是平台的怪癖。定义深链如何表现、模态如何关闭，以及何时将流程作为全屏而非模态。
• 搜索：标准化清除按钮的行为（仅清除文本或同时清除结果）、保持空结果文案一致，并确保筛选 chips 可一键移除。

一个可以测试的小示例

想象一个客户门户，用户能搜索发票、打开详情并付款。在移动端，对“付款”快速双击如果仅显示一个 spinner 但不锁定动作，可能会产生两笔费用。在网页端，即使某字段无效，按回车也可能提交表单。

如果在 AppMaster 中构建，为业务流程设置相同规则（单一进行中的付款请求、统一的校验触发），并在 web 与移动构建器中匹配 UI 行为。

决定一次，然后在每个发布中验证：双击、提交含错误表单、刷新、返回、清除搜索。

逐步指南：如何执行一致性评审

一致性评审作为可重复的例行工作时效果最好。目标是在用户发现之前捕捉“相同功能，不同体验”。

先选一组对比屏幕：登录、搜索、详情页、表单提交和设置。使用相同测试数据在 web 与移动上运行，这样比较的是行为而不是内容。

按固定顺序进行评审：

• 确认标签、操作与结果匹配。
• 验证状态：加载、错误、空、禁用、成功。
• 检查行为：点击、焦点、键盘、滚动、确认。
• 然后检查间距、排版和视觉打磨。
• 对修复后的至少一条“黄金路径”流程重测。

记分卡能让决策更快。对每个屏幕或组件标记为匹配（意图和行为相同，仅平台原生差异）、可接受差异（UI 不同但结果相同，已记录）或不匹配（改变含义、增加步骤或违反规则）。

记录不匹配时，附上两张截图、被破坏的具体规则（例如“主操作位置”或“空状态语气”）以及一句话说明用户影响。如果在 AppMaster 中构建并可共享逻辑，注明问题是 UI 构建器设置、共享组件规则还是流程本身的问题。

也要愿意修订规则。如果同一“不匹配”不断出现，说明指南不清或不现实。更新系统比逐一修补屏幕更有效。

导致不一致的常见陷阱

大多数一致性问题不是重大决断，而是实现、修复和临时调整中溜进来的小改动。清单有用，但前提是你知道偏差通常从哪里开始。

文案偏差是典型案例。网页可能写“保存更改”，移动端写“更新”，尽管功能相同。用户会把它感知为摩擦，尤其在重置密码、编辑资料和付款确认时。

间距偏差更隐蔽。有人为修复某个屏幕多加了 6px 内边距，这种一次性的改动扩散开来。几次迭代后，网页看起来通透，而移动端显得拥挤，尽管两者都宣称“使用相同设计”。

状态缺失会造成最大混淆。网页可能有清晰的空状态和错误提示，而移动端则可能是空白列表、无限旋转的 loading 或沉默失败。这通常发生在状态逻辑分散（网页端在前端处理、移动端在原生视图逻辑处理）时。

在评审时注意：

• 相同行为使用不同标签或语气
• 在间距刻度外随意添加的 padding/margin
• 一端缺失加载、错误、空或禁用状态
• 平台默认控件未经规则覆盖而直接泄露（开关、日期选择器、警告）
• 无障碍回退：网页焦点顺序混乱或移动端点击目标太小

一个简单例子：在客户门户里，网页显示“暂时没有发票”并带提示与添加付款方式按钮，而移动端只显示空列表。修复不是视觉润色，而是就空状态内容和按钮行为达成一致并在各端应用。

即便你在 AppMaster 同时构建 web 与原生，一致性仍需要文本、间距 tokens 和状态处理的规则，否则每个屏幕都会变成自己的例外。

快速一致性检查（发布前的 5 分钟自检）

一次快速的一致性检查能捕捉用户最先注意到的问题：看起来不对的文本、不同行为的按钮和未完成的屏幕。

在电脑和手机上打开同一个“参考屏幕”。选你使用频率最高的流程（登录、搜索、结账、申请表），快速扫描：

• 排版刻度： 标题、正文字体和注释遵循相同的字号步长和字重规则。尤其在小屏上检查行高。
• 间距与触控舒适度： 卡片、表单和对话框周围内边距一致。移动端确认内容不会靠近刘海或 Home 指示器太近。
• 屏幕状态： 关键屏幕有清晰的加载、错误、空与禁用状态。用户应始终知道发生了什么和下一步怎么做。
• 组件行为： 主要操作以相同方式提交、显示相同反馈，并防止双击或双击提交。返回操作不应意外丢失已输入的数据。
• 文案含义： 标签和错误信息在含义上匹配，而不仅仅是字面一致。如果网页写“账单地址”，移动端不应写“支付信息”，除非两者确实不同。

若有问题，问自己一句话：“用户会不会感觉换到了另一款产品？”先修复最大的不匹配项。

示例：在用 AppMaster 构建的客户门户中，你可能发现 web 与原生显示同一表单，但移动端在网络慢时允许双击“提交”。为按钮加明确的加载状态并在请求完成前禁用按钮，以确保行为一致并避免重复提交。

示例：让客户门户在网页与移动端保持一致

想象一个简单的客户门户，有三个屏：登录、个人资料和订单列表。网页在笔记本上被支持人员使用，移动端被客户随时使用。你希望在任何设备上流程和含义一致，即便 UI 细节不同。

一个常见的不匹配出现在用户尚无订单时。网页上的 Orders 页面可能显示友好的空状态（图标、简短信息和“浏览商品”的主按钮），而移动端同一屏有时会变成空白列表让用户以为应用崩溃。

修复是把一致性当作规则而不是视觉猜测来处理。具体规则示例如下：

• 空状态模板： 两端结构与文案一致：标题（“尚无订单”）、一句帮助说明和一个明确的操作。把可选的二级动作做成链接而非按钮。
• 按钮层级： 每个屏只要一个主操作。在网页与移动端上“浏览商品”都是主操作，“联系客服”作为次要且视觉上更轻。
• 间距刻度： 使用相同的间距步长（例如 8、16、24），使布局产生关联。移动端可以在触控目标周围增加一些垂直内边距，但仍使用相同刻度。

行为是最容易破坏一致性的地方，因此做出明确定义：

• 刷新： 移动端支持下拉刷新；网页使用刷新图标或“重新加载”按钮。两者触发相同的加载状态并在可能时保持滚动位置。
• 分页： 网页可显示“加载更多”与页面大小控制；移动端用无限滚动或“加载更多”。无论哪种方式，新条目应追加而不是替换列表。
• 错误： 若 Orders 加载失败，两端显示相同的消息与重试操作。不要在一端用 toast 而在另一端用整屏错误。

结果是用户能明白发生了什么并知道下一步该做什么。界面仍尊重各平台（安全区、键盘行为、悬停与点击差异），但产品整体感觉像一个统一的门户。

接下来的步骤：随着产品增长保持一致性

一致性是一件容易一次性做好但随着产品进化又容易丢失的事。新功能、快速修复和仅平台要求会迅速累积。目标是让“保持一致”成为默认行为。

把你的检查清单视为活文档。每次发布后记录变更和让你惊讶的点。如果某个屏在移动端以不同的空状态发布，把它变成规则或示例以避免再次发生。

让一致性成为最省事的路径

越多可复用的东西，越少需要重新决策。构建一套小型可复用组件与页面模板，覆盖列表屏、详情屏、表单与“无结果”视图。把通用文案（按钮标签、空状态消息）集中管理，避免 web 与移动端在语气上悄然分化。

一个简单的例行流程能帮助团队维持标准：

• 在发布说明中更新一致性规则，而不是发布几周后再补上。
• 在功能验收标准中加入一致性条目（状态、间距、行为）。
• 要求 PR 或 QA 签核时上传两端的截图或短视频。
• 跟踪“已批准差异”，让例外变得明确而非偶发。
• 在设计系统变更后安排一次快速一致性检查。

把一致性融入构建流程

无论使用何种工具，目标是共享 tokens、共享模板与共享行为规则。如果使用 AppMaster，建议把 tokens 和可重用 UI 模式当作在 web 与移动构建器间共享的资产，并将关键行为在 Business Process 编辑器中集中管理。这样一致性由构建方式支持，而不是靠临门一脚的审查来强行实现。

如果想要把这件事坚持下去，挑一个即将上线的功能，把一致性检查作为其完成定义的一部分。这是把“保持一致”变成团队可验证工作的一种简单方式。