组件规范：输入与控制
输入与控制类的组件，是用户与系统交互最频繁的部分，也是最容易出错的部分。交互设计师的功力，很大程度上体现在如何让用户“少输入，不犯错”。这个类别包含众多组件，为方便分析，我们先对其进行细分：
- 命令与操作：用户发出指令，告诉系统去做某件事。主要代表：Button按钮；
- 文本与数值录入：Input输入框、Search Bar搜索栏、Stepper步进器、Slider滑块等；
- 选择与状态：Switch/Toggle开关、Checkbox复选框、Radio Button单选按钮、Tags标签、Segmented分段控件（既是导航，也是控制）；
- 复杂输入：Picker选择器、Uploader上传器。
命令与操作
Button 按钮
一个可点击的交互空间，用于触发即时操作
使用规范
按钮设计的核心——需要依据操作的重要性，建立清晰的视觉层级。常见三个等级：
- 主按钮：一个页面通常只有一个主按钮，是唯一的核心操作，常用实心填充色，视觉分量最重；
- 次按钮：替代性、辅助性的操作，常用描边或浅色背景样式，视觉分量中等；
- 文本按钮：低频操作，优先级最低，常用纯文本表示，通过颜色或下划线表示其可点击，视觉分量最低；
核心用途
提交数据：如提交表单、购物下单
做出决策：如对话框的确认/取消
改变状态：如关注/已关注
注意事项
1、避免一个页面主次不分，存在多个主按钮或全是一个类型的按钮，缺少层级管理，会让用户失去重点，感到迷失；
2、不要滥用“禁用状态”，如果表单未填写完，“提交”按钮通常有两种处理方式：
- 置灰：通过样式提示用户当前无法提交，但可能会造成用户困惑；
- 保持可点击状态，用户点击后，再提示无法提交的原因，帮助用户快速定位问题。
交互细节
状态区分： 按钮具有常规态、点击态、禁用态、加载态，
- 常规态：正常显示；
- 点击态：手指按下时，按钮样式变化（颜色变深或尺寸缩小），给予用户即时的“按压感”；
- 禁用态：置灰，不可点击；
- 加载态：在等待网络请求时，按钮文字应变为加载动画，避免用户反复提交；
按钮文案： 结合上下文选择更准确的文案，如“确定”、“完成”、“保存”，不同的文案给予用户的认知是有差异的；
触控热区： iOS标准最小热区44x44pt，Android标准最小热区48x48dp。
文本与数值录入
Text Field / Input 输入框
一个允许用户通过键盘输入和编辑文本或数字的界面控件
组件构成
1、容器：输入区域的背景或边框；
2、标签：告诉用户该填什么，可以在框外，也可以使用浮动标签（默认在框内，聚焦时浮动到左上角）；不要仅用占位符代替标签，一旦用户输入时，占位符会消失，用户可能会忘记需要填什么内容；
3、 占位符：输入前的提示语；建议直接提供示例（如： name@example.com），而不是重复标签内容；
4、辅助文本：位于输入框下方，提供输入说明或报错提示；
5、前/后缀图标：前缀图标常用于增强语义；后缀图标则多用于功能性操作，如“密文/明文”、“一键清除”。
核心用途
文本输入、数字输入
注意事项
1、不要用输入框来做“选择”。选项有限时，直接提供单选框更好，尽量少让用户输入；
2、不要用于日期/时间的输入。选择日期/时间，请使用Picker选择器。
交互细节
键盘匹配：根据输入场景选择合适的键盘类型
- Default：标准全键盘
- Number：纯数字键盘
- Phone：电话键盘
- Email：带有 @ 和.com 的键盘
- URL：带有 / 和 .com 的键盘
回车键行为：键盘右下角的按钮需要根据输入场景提供合适的功能
- 直接触发下一步动作：搜索、发送、确定、前往…
- 仅收起键盘：确定、完成
- 继续输入：换行
输入校验：
- 即时校验：适用于格式检查
- 失焦校验：输入框失去焦点时，再校验输入内容
- 错误反馈：错误信息显示在输入框下方，且需要用醒目的红色标注
Search Bar 搜索栏
一个允许用户输入关键词以从庞大的数据库中检索特定内容的控件
核心用途
1、全局搜索
帮助用户跳过层级结构，快速找到目标，常位于首页顶部
2、页内筛选
在一个长列表中，帮助用户快速定位特定项
主要形态
1、持久栏
直接展示完整的搜索框，适用于搜索是APP的核心高频功能。通常位于页面顶部。
2、展开式
默认为一个放大镜图标，点开后展开成搜索框，可以有效节省屏幕空间，适用于搜索是APP的次要功能。
注意事项
1、不要只写“搜索”或“请输入”：占位符最好直接告诉用户能搜什么，如“搜索设备名称”、“搜索联系人名称”等；
2、退出按钮需要明显，输入时，右上角必须有“取消”按钮（常见iOS）或左上角变成“返回”箭头（常见Android），方便用户退出搜索模式。
交互细节
激活态： 点击搜索栏，键盘弹起，页面不要展示空白，可以展示“历史记录”、“热门搜索”等内容，提高空间利用率；
输入中：
- 联想搜索（可选，视性能而定），根据用户输入的字符实时显示建议列表，减少输入成本；
- 联想搜索不能输入一个字母就发一次网络请求，必须设置一个防抖计时器，当用户停止打字超过设定的时间后，才发送请求；
- 建议在输入框提供“x”按钮，允许用户一键清空当前输入；
结果页：
- 用户点击键盘上“搜索”键或点击联想词后进入搜索结果页，同时搜索框回显输入的词，方便用户修改；
- 若未找到搜索结果，则需要提供文案提示，同时提供“建议”或“去逛逛别的”。
Stepper 步进器
一个包含增减按钮和数值显示区的控件
核心用途
小范围的整数调整，例如购物车的商品数量、酒店的入住人数等
注意事项
1、不要用于大范围数值调整；
2、不要用于调节连续、非离散的值，如音量、亮度等，这类数据适合使用滑块。
交互细节
步长： 通常是1，但也可以是其他逻辑值；
标签： 步进器旁边通常需求说明调节的对象；
极限值： 当数值达到最大/最小值时，增减按钮置灰；
直接输入： 建议中间的数字不仅仅是显示，允许用户点击后输入，体验更佳。
平台差异
iOS：iOS提供的标准组件内容不显示数值，适用场景少，常见APP中步进器多是自定义的；
Android：非系统原生组件，需要自定义。
Slider 滑块
允许用户通过沿轨道拖动滑块来从一个连续或间断的范围内选择一个特定值或数值范围
核心用途
1、调节主观感受的参数
用户不关心具体数值，只关注“程度”，如音量调节、屏幕亮度等
2、筛选数值范围
通过双头滑块确定一个数值区间，这个区间通常要高亮显示以与选择外的范围区分
3、用于有限的、有序的选项选择
轨道上设有刻度，滑块会被吸附到临近的刻度点上。常用于调节字号大小（小/标准/大/特大）、播放倍速（0.5x/1.0x/2.0x）
4、媒体播放进度
视频或音乐的进度条本质上也是一种特殊的滑块
注意事项
1、不要用于极大的数据范围：数据范围很大时，滑块移动的单位值就会很大，用户无法控制精度；
2、不要在数据延迟高时使用：如果拖一下滑块就要请求一次服务器，会让人感觉很卡顿。
交互细节
热区： 滑块的热区必须足够大，否则很难拖动；
刻度： 如果是离散型滑块，需要标出刻度，提示有哪些档位；
数值气泡： 用户拖动时，手指可能遮住滑块，所以建议提供一个气泡显示在滑块上方，实时告诉用户数值。
平台差异
iOS：常规滑块为系统原生组件，可直接调用，但双头滑块需要开发自定义；
Android：系统原生组件，可直接调用。
选择与状态
Switch/Toggle 开关
一种用于在两个互斥状态之间进行切换的控件
核心用途
1、即时生效的系统设置
当用户改变状态后，系统立刻执行相应的操作，而不需要用户再去点击“保存”按钮，常用于打开“深色模式”、开启“飞行模式”等
2、独立的二元选项
用于控制某个独立功能的开启或关闭
注意事项
1、不要用于“动作”：开关代表状态，而不是动作，执行动作应该用按钮；
2、不要用于需要“提交”的表单：用户对开关的心理预期是即时生效，而表单是“点了提交才生效”，两者认知有冲突。在表单中的二元选项建议使用Checkbox或Radio。
交互细节
标签文案： 标签必须清晰描述打开后的状态，否则会出现双重否定句式，增加用户认知负荷。例如：关闭通知「开/关」，打开开关=关闭通知，不易理解；
异步加载： 如果开关控制的是一个网络请求的功能，点击后开关应显示“加载”状态，或先变为开启状态（同时禁用，防止连续请求），请求失败后再自动弹回并报错。
平台差异
iOS：系统原生组件，可直接调用；
Android：系统原生组件，可直接调用。
Checkbox 复选框
一种非互斥的数据输入组件
核心用途
1、在一组选项中选择任意数量选项
常见场景：筛选、问卷调查、批量操作
2、独立的二元确认
通常用于动作执行前的最终确认，如勾选隐私协议
注意事项
1、不要用于互斥选项：若两个选项互斥，请用Radio；
2、不要用于即时生效的设置：如果需要即时生效，请用Switch。
交互细节
点击热区：Checkbox的勾选框通常很小，不方便点击，热区应该尽量扩大；
半选中状态：当在一个存在层级关系的列表中选择时，checkbox通常还有一个半选中状态，代表某个父级下的子级选了部分，但未选完。
平台差异
iOS：iOS习惯用圆形的勾选框，容易与Radio混淆，需要在上下文中给予明显的多选提示；
Android：沿用WEB端的习惯，Android系统原生的Checkbox是方形，但随着如今两个平台越来越融合的设计趋势，也有APP采用圆形的勾选框。
Radio Button 单选框
一组互斥的选项组件，用户必须从两个或多个选项中选择唯一的一个。为什么用“Radio”为单选框命名，源于其对旧式收音机上的物理按键的隐喻——当按下“频道1”时，其他频道的按钮就会自动弹起。这个物理隐喻非常精准地描述了它的互斥逻辑
核心用途
在一组较少的、互斥的选项集合中选择唯一一个选项
注意事项
1、不要用于过多的选项：若选项过多，平铺出来会挤占空间，建议使用Picker；
2、状态切换，请用“Switch”；视图切换，请用“Segmented”、“Tab”；
3、若选项组为非必选，即允许存在“都不选”的情况，不要使用Radio，Radio要求必须有一个选项被选中。
交互细节
默认值：Radio不能存在“全空”的状态，所以必须有默认值，最好默认选中最常用或最推荐的选项；
垂直排列：建议垂直堆叠排列，视线移动最顺畅。
平台差异
iOS：iOS多使用“对勾”，勾选后改变选项右侧出现对号，其他行的对号消失，不会在每一项选项后都显示圆圈；
Android：标准的圆形，默认显示在文本左侧，勾选后显示圆点。
Tags 标签
一个万能的组件，用于表示一个属性、文本输入、过滤条件或动作
核心用途
1、展示
给内容打标记，不可交互
2、筛选
替代“Checkbox/Radio”，用于筛选内容
3、选择
代替“Radio”，用于单选
4、输入
代表用户输入的内容，通常包含一个关闭按钮
注意事项
1、不要作为主按钮：标签外形有点类似于按钮，但其通常代表“属性”而不是“命令”；
2、不要在标签里放太长的文字；
3、谨慎使用颜色，如果每类标签都采用不同的颜色区分，可能会导致界面过于花哨。
交互细节
布局方式： 1、横向滚动布局：超过屏幕部分则隐藏，允许用户左右滑动查看；2、自动换行布局：超过一行长度时，自动换行到第二行展示；
状态区分： 标签的默认状态、选中状态、置灰状态需要有明显的样式区分。
平台差异
iOS：非系统原生组件，需开发自定义实现；
Android：标准原生组件，在Android端被称为“chips”。
复杂输入
Picker 选择器
一种用于从预设好的、较大的数据集中选择一个或多个值的组件
核心用途
1、普通选择
当选项较多，不适合用Radio承载时，可使用Picker代替
2、日期与时间选择
结构化的时间数据
3、级联选择
从一组多维、有层级关系的数据中选择
注意事项
1、不建议用于少选项（2-3）的选择：少选择用Radio会跟方便直接；
2、不要用于海量数据的选择：当数据量巨大（如选择国家时），更适合用搜索列表；
3、不要全屏展示：Picker通常应该承载于Bottom Sheet，不会占据整个页面。
交互细节
默认选中： 打开时，滚动应该定位的位置——
- 已填过：必须停在用户上次选的值上；
- 未填过：停在最常用、最中间或第一个选项上；
确认生效： 用户在滑动滚轮时，表单里的值不应该变。只有当用户点击“确定/保存”后，数据才回填到表单中。
平台差异
iOS：系统原生组件，可直接调用；
Android：Material Design规范里没有滚轮，但如今大部分APP都会采用了iOS风格的滚轮，因此在开发Android端时，需要自定义或调用第三方库。
Uploader 上传器
允许用户将本地文件上传到服务器的组件
常见类型
1、头像上传
2、宫格上传器
3、文件上传器
4、聊天框上传
交互细节
上传器不是一个静态组件，而是一个微型的流程，涉及到：
1、待触发
- 显示“+”或“上传”按钮，同时显示限制条件。例如“支持JPG/PNG，不超过5MB”等；
- 确认是否支持拍照功能，不要默认只让用户从相册中选择。
2、选择
- 首先需要获取相册权限，若用户未授予权限，要引导用户去设置页开启；
- 选择完后需要预处理：后台对图片/文件进行压缩后再上传，能极大地提升速度和成功率。设计师需要跟开发共同确定压缩策略；
- 即使有限制提示，也建议从技术上筛选出支持的文件类型，“选不中”比选完再报错更友好。
3、上传中
- 进度反馈：需要使用进度条或loading显示上传进度，且通常是局部加载，不要使用全屏loading阻断用户操作；
- 取消机制：上传过程中需要提供取消按钮，允许用户打断上传请求；
- 断点续传：对于大型视频或文件，如果在上传过程中断网了，下次应该接着上次的进度继续上传，而不是从头开始。这点需要跟开发确认后端协议是否支持。
4、上传结构
- 成功：显示完整缩略图；
- 失败：显示异常状态（如感叹号，或失败字样），并提供“重新上传”的按钮。
