移动端 App UI 设计参数规范：尺寸、字体、间距与适配

移动端 UI 设计和平面设计有一个很大的区别：界面里的元素最终要被开发实现，所以每个尺寸、字号、间距、圆角、阴影和点击区域都需要有明确参数。

一个按钮看起来“差不多”不够，开发需要知道它到底是 44pt 还是 48dp；一组卡片看起来“挺整齐”也不够，团队需要知道它们遵循的是 4pt 栅格、8pt 栅格，还是完全手动摆放。

移动端 UI 参数的核心目标只有一个：让设计稿在不同屏幕、不同系统、不同分辨率下都能稳定还原，并且让用户操作起来舒服。

可以把移动端 UI 参数理解成一套约束系统：

flowchart TD
    A[设备屏幕] --> B[逻辑尺寸]
    B --> C[栅格与间距]
    C --> D[组件尺寸]
    D --> E[字体与图标]
    E --> F[安全区与适配]
    F --> G[开发实现]

如果前面的单位和尺寸没定清楚，后面的组件规范、页面适配和开发标注都会变得混乱。

1. 移动端 UI 设计到底在规范什么

移动端 UI 规范不是单纯规定“按钮用蓝色”“卡片圆角 12px”，而是把界面里的基础参数统一起来。常见规范包括这些内容：

一套好的 UI 规范，不是为了限制设计，而是为了减少重复判断。基础参数统一之后，设计师不用每个页面重新决定按钮高度，开发也不用每次追问间距到底是多少。

2. 先弄清楚单位：px、pt、dp、sp 不是一回事

移动端设计最容易混乱的地方是单位。很多人习惯把所有尺寸都叫“像素”，但在 iOS、Android 和设计工具里，像素并不总是同一个意思。

2.1 物理像素和逻辑像素

手机屏幕上真正发光的点叫物理像素。设计和开发一般不会直接按物理像素写界面，因为不同设备的屏幕密度差异很大。

比如两个按钮视觉上都应该是一样大的，但在高密度屏幕上需要更多物理像素来显示。

flowchart LR
    A[设计稿中的 100 逻辑单位] --> B{设备像素比 DPR}
    B -->|2x 屏幕| C[200 物理像素]
    B -->|3x 屏幕| D[300 物理像素]

因此，移动端设计更关心“逻辑尺寸”，而不是物理像素。

2.2 iOS 和 Android 常用单位

一个常见做法是：设计稿按逻辑尺寸来做。比如 iOS 使用 375px 宽的画板，可以理解为 375pt；Android 使用 360px 宽的画板，可以理解为 360dp。

3. 设计稿尺寸怎么选

移动端设备很多，不可能给每一种手机单独做一套设计稿。更合理的方式是选一个基准宽度，再用响应式规则处理更宽或更窄的屏幕。

3.1 常见基准尺寸

如果只做一套设计稿，常见选择是：

• iOS App：以 375 或 390 为主画板。
• Android App：以 360 为主画板。
• 跨端 App：可以选 375 作为统一设计基准，但开发标注时要明确映射规则。

基准尺寸不是越大越好。用大屏做出来的界面，在小屏上容易出现文字换行、按钮挤压、底部内容被遮挡等问题。更稳妥的方式是用主流宽度设计，再用小屏和大屏各校验一遍。

4. 栅格系统：别让间距靠手感

移动端界面要整齐，不能只靠拖拽对齐。栅格系统的作用是给所有尺寸和间距提供一个共同基准。

最常见的是 4pt / 4dp 栅格，也可以在模块级间距上使用 8pt / 8dp 栅格。

flowchart LR
    A[4 基础单位] --> B[8 小间距]
    A --> C[12 紧凑模块]
    A --> D[16 常规内边距]
    A --> E[24 分组间距]
    A --> F[32 页面大间距]

4.1 常用间距等级

页面左右边距通常使用 16，也有产品会用 20 或 24。内容型产品适合稍大的边距，工具型产品为了容纳更多信息，可以使用更紧凑的布局。

4.2 页面边距建议

5. 字体规范：字号不是越多越好

移动端字号需要分级，但分级不能太碎。一个产品里如果出现 13、14、15、16、17、18、19，各种字号混在一起，页面会变得难以维护。

更好的方式是建立一组字体等级，每个等级负责一种信息层级。

5.1 常用字号体系

iOS 常用正文大小接近 17pt，Android 常用正文大小接近 16sp。实际产品可以根据品牌风格调整，但正文最好不要过小，尤其是需要长时间阅读或涉及输入确认的页面。

5.2 行高怎么定

移动端文字太挤会影响阅读，太松又会浪费空间。常见行高可以按字号的 1.3 到 1.5 倍设置。

标题可以稍紧，正文需要更舒服的行距。按钮文字和标签文字一般不需要过大的行高，否则会让组件高度变得松散。

6. 触控区域：看起来能点，不等于真的好点

移动端界面不是给鼠标用的，而是给手指用的。手指点击精度远低于鼠标，所以按钮、图标和列表项都需要足够大的触控区域。

注意，这里说的是“可点击区域”，不是图标视觉大小。一个 24pt 的图标，可以放在 44pt 的点击容器中。

flowchart TD
    A[视觉图标 24x24] --> B[居中放入]
    B --> C[点击区域 44x44 或 48x48]

常见做法：

• 工具栏图标视觉尺寸使用 24。
• 图标外层按钮保持 44 或 48 的最小点击面积。
• 列表项高度不要过低，常见高度为 48、56、64、72。
• 相邻可点击元素之间留出足够间隔，避免误触。

7. 常用组件参数

组件规范的价值在于复用。按钮、输入框、导航栏、标签栏这些基础组件一旦定好，页面搭建会更快，也更容易保持一致。

7.1 按钮

按钮需要定义多种状态：

7.2 输入框

输入框不要只靠红色表示错误，最好配合错误文案。比如“请输入手机号”比单纯红框更容易理解。

7.3 列表项

列表项最容易出现的问题是每个页面高度都不一样。更好的方式是按内容复杂度分级，而不是每次手调。

7.4 顶部导航和底部导航

顶部状态栏、刘海区域、灵动岛、底部手势条都会影响真实可用区域，所以导航栏不能只看视觉高度，还要考虑安全区。

8. 安全区：不要让内容撞上系统区域

全面屏手机会有状态栏、刘海、摄像头开孔、底部手势条。界面内容如果不处理安全区，就可能被系统区域遮挡。

flowchart TD
    A[屏幕完整区域] --> B[顶部安全区]
    A --> C[内容区域]
    A --> D[底部安全区]
    B --> E[状态栏 / 刘海 / 开孔]
    D --> F[手势条 / Home Indicator]

安全区处理原则：

• 主要内容不要贴到屏幕顶部硬件区域。
• 底部按钮不要压在系统手势条上。
• 沉浸式页面可以让背景延伸到安全区，但文字和按钮仍要避开。
• 底部固定操作栏需要叠加底部安全区高度。

Web 或混合 App 可以使用 CSS 的安全区变量：

.fixed-bottom-action {
  position: fixed;
  left: 0;
  right: 0;
  bottom: 0;

  padding: 12px 16px;
  padding-bottom: calc(12px + env(safe-area-inset-bottom));

  background: #ffffff;
}

iOS 原生开发会使用 Safe Area Layout Guide，Android 原生开发会处理 WindowInsets。设计稿里也需要标注：哪些背景可以延伸，哪些内容必须避开。

9. 颜色规范：不仅要好看，还要看得清

颜色规范通常包括品牌色、功能色、中性色和状态色。

9.1 文本颜色层级

颜色不能只看设计工具里的观感，还要检查对比度。WCAG（Web Content Accessibility Guidelines，网页内容可访问性指南）常用建议是：

如果浅灰文字放在白色背景上，对比度太低，在户外强光或低亮度屏幕上会很难看清。

10. 深色模式要单独设计，不是简单反色

深色模式不能把浅色界面直接反相。直接反色会导致品牌色刺眼、阴影失效、层级混乱。

深色模式需要重新定义颜色 Token：

深色模式的层级通常靠不同明度的背景色来表达，而不是大量依赖投影。因为深色背景上的阴影不明显，卡片和浮层更适合用边框、高亮描边或背景差异来区分。

11. 图标和图片导出规范

图标在设计稿里看起来清晰，不代表导出后一定清晰。移动端资源要按平台倍率导出。

11.1 iOS 图片资源

例如一个 24pt 的图标：

11.2 Android 图片资源

Android 更推荐使用矢量图标，比如 Vector Drawable 或 SVG 转换资源。简单图标用矢量更省资源，也更容易适配不同密度屏幕。

11.3 图标设计注意点

• 图标视觉尺寸常用 16、20、24、32。
• 工具栏、标签栏图标常用 24。
• 图标线宽要统一，比如 1.5 或 2。
• 同一组图标要保持相同风格，不要线性图标和面性图标混用。
• 点击区域要大于图标本身。

12. 适配规则：固定尺寸和弹性布局要分清

移动端适配不是把所有元素按比例缩放。真正需要适配的是布局规则。

12.1 哪些可以固定

12.2 哪些应该弹性变化

错误做法是把 375 宽设计稿按比例放大到 430 宽。这样会让字号、图标和圆角一起变大，界面看起来笨重。更合理的做法是保持基础组件尺寸稳定，把多出来的空间分配给内容区、留白或布局列数。

13. 设计 Token：把规范变成可复用参数

当规范只写在文档里，很容易被忘记。更好的方式是把颜色、字号、间距、圆角等参数抽象成 Design Token。

示例：

{
  "color": {
    "brand": {
      "primary": "#2563EB",
      "primaryPressed": "#1D4ED8",
      "primaryDisabled": "#AFC8FF"
    },
    "text": {
      "primary": "#111827",
      "secondary": "#6B7280",
      "disabled": "#B8BEC8"
    },
    "background": {
      "page": "#FFFFFF",
      "card": "#F7F8FA"
    }
  },
  "fontSize": {
    "titleLarge": 24,
    "title": 20,
    "body": 16,
    "caption": 12
  },
  "spacing": {
    "xs": 4,
    "sm": 8,
    "md": 16,
    "lg": 24,
    "xl": 32
  },
  "radius": {
    "sm": 4,
    "md": 8,
    "lg": 12,
    "pill": 999
  }
}

Token 的好处是设计和开发可以使用同一套命名。比如设计稿里叫 color.text.secondary，代码里也可以用同样的语义名称，而不是到处写 #6B7280。

14. 标注和交付：让开发能直接实现

设计稿交付时，不能只给静态页面截图。开发真正需要的是结构、状态和规则。

一份可落地的移动端 UI 交付至少包括：

组件状态尤其容易被遗漏。只设计默认状态，会导致开发在禁用、加载、错误、空数据时自行处理，最终每个页面效果不一致。

15. 常见问题和处理方式

15.1 设计稿里用了很多零散间距

如果一个页面里出现 7、9、13、18、23 这种间距，后期维护会很痛苦。可以把它们收敛到 4pt 或 8pt 栅格里。

不是所有尺寸都必须机械地变成 4 的倍数，但主布局、组件内边距和模块间距最好遵循统一规则。

15.2 图标太小但又不想放大视觉尺寸

保持图标 24 不变，把外层点击区域做大。

flowchart LR
    A[错误：24 图标就是 24 点击区] --> B[容易误触]
    C[正确：24 图标放入 44/48 点击区] --> D[更容易点击]

15.3 小屏文字放不下

不要盲目缩小字号。可以按顺序处理：

1. 缩短文案。
2. 允许换行。
3. 调整布局结构。
4. 次要信息折叠或延后展示。
5. 在极端场景才考虑减小字号。

字体太小会直接影响可读性，尤其是表单、金额、订单、权限确认等关键场景。

15.4 深色模式直接套浅色颜色

深色模式需要单独定义背景、文字、分割线和品牌色。浅色模式里的阴影，在深色模式里通常不明显，需要改用描边或背景层级。

15.5 只设计一种正常状态

真实 App 会遇到空数据、加载失败、网络异常、权限关闭、输入错误等状态。核心页面至少需要补齐这些状态，否则上线后容易出现临时拼凑的界面。

16. 移动端 UI 参数检查清单

交付前可以按这份清单检查：

移动端 UI 设计的参数不是装饰细节，而是产品体验和工程实现之间的连接层。尺寸、字体、间距、触控区域和安全区这些基础规则定得越清楚，界面越容易保持一致，开发还原时也越少产生歧义。