见微知著：从细节处辨Radio与Checkbox

近日在验收 UI 稿的时候，发现 UI 设计师将登录页中隐私协议的勾选状态改成了圆点样式——典型的 radio 组件的勾选状态。

相信大部分人看到这种设计时都会产生一丝怪异感——这似乎并不常见。为了验证这种“直觉”，我随机找了几个 app 的登录页面：

可以看到相同场景下，日常用到的 app 都使用的 checkbox 组件。
明明都可以表示“选择”，这里也只有一个可选中项，为什么不能用 radio 组件？要回答这个问题，核心是要弄清楚 radio 和 checkbox 组件的本质区别。

Radio 单选框

功能语义：从一组互斥的选项中选出唯一一个。例如，选择性别、颜色、支付方式。Radio 要求必须且只能选择一个选项。就以隐私协议为例，我们可以试着分析下几种情况：

• 默认已勾选——这属于“强制同意”，是绝对禁止的。在各地的相关法律法规中都要求用户的同意必须是知情且明确的
• 默认未勾选，用户勾选后不可取消——Radio 组件不存在“未勾选”状态，违反组件使用规范且存在与第一种情况相同的问题
• 提供“同意”和“不同意”两个选项——这种方式逻辑上行得通，但会造成设计冗余。

Radio 更适合用于从多个互斥的选项中做出唯一选择。

Checkbox 复选框

功能语义：代表一个或多个独立、可勾选的选项。它的状态是“选中”或“未选中”，表示“是/否”或者“同意/不同意”。常用于同意使用条款、记住密码或需要多选的场景。
隐私协议的勾选与否，实际是在询问用户：“你是否同意 XXX？”。Checkbox 可以精确表达这种二元状态：

• 未勾选：代表“不同意”。默认状态下不勾选，符合相关法律法规。
• 已勾选：代表用户主动操作后变为“同意”的状态，这个动作也暗含了用户是知情且明确的。

此外，“勾选表示同意”这个交互模式已经深入人心——这也是你看到第一种设计会直觉性感到怪异的原因。

一个小小的勾选按钮需要设计师综合考量交互规范、操作习惯、功能隐喻、法律法规等因素。细节的重要性，管中窥豹，可见一斑。