嘿，这个问题问得太到位了——不少从Web开发转做iOS的朋友都会有这个困惑，我来给你捋清楚：

首先明确一点：「绝不信任用户输入」这个原则100%适用于移动端APP，甚至比Web场景更需要重视！因为客户端环境是完全不可控的：越狱/root设备可以直接篡改你的Swift代码逻辑、抓包工具能轻松修改请求参数、甚至有人会直接伪造API请求绕过客户端校验。所以服务端验证是安全的底线，绝对不能省。

那客户端、服务端的验证分工该怎么安排？最优方案是两端同时做，但各司其职：

客户端验证：主打用户体验 #

客户端验证的核心目的是「快速反馈，减少无效请求」，比如：

• 输入手机号时，实时用正则校验格式（比如中国大陆手机号的11位规则），用户刚输错就弹出提示，不用等提交到服务端才知道格式不对
• 输入邮箱时，即时检查是否符合xxx@xxx.xx的格式
• 输入密码时，实时提示是否满足长度/复杂度要求（比如至少6位、包含字母数字）

这种即时反馈能大幅提升用户体验，避免用户白等请求响应，但记住：客户端验证只是「体验优化」，绝不能当成「安全屏障」。

服务端验证：守住安全底线 #

不管客户端有没有做验证，服务端必须对所有输入做「全量校验」，包括：

• 再次校验手机号、邮箱的格式（防止有人跳过客户端校验直接发非法请求）
• 校验手机号是否真的在Couchbase数据库中不存在（避免恶意重复发送验证码）
• 校验Twilio验证码的有效性（必须和服务端存储的验证码、过期时间比对，客户端传来的验证码不能直接信任）
• 校验密码的复杂度（比如不能是纯数字、长度达标）
• 所有业务状态的修改（比如phoneVerified、user.status）必须由服务端完成，绝对不能让客户端自己设置这些状态！

举个反例：如果你的Swift代码里直接把phoneVerified设为true，那恶意用户只要篡改本地数据，就能跳过验证码步骤直接进入下一页，完全失去了验证的意义。正确的流程是：客户端发送验证码验证请求，服务端校验通过后，在Couchbase里把phoneVerified更新为true，再给客户端返回成功响应，客户端只负责根据响应更新界面。

结合你的流程的具体建议 #

1. 手机号验证环节：

   • 客户端：先用正则校验手机号格式，格式不对直接提示用户
   • 服务端：再次校验格式 → 查询Couchbase确认手机号未注册 → 调用Twilio发送验证码 → 把验证码、过期时间存在Couchbase（和该手机号绑定）→ 返回「验证码已发送」的响应给客户端
   • 注意：phoneVerified必须由服务端在验证码校验通过后设置，客户端不能私自修改

2. 邮箱密码环节：

   • 客户端：校验邮箱格式、密码长度/复杂度，不符合要求即时提示
   • 服务端：再次校验邮箱格式、密码规则 → 确认用户的phoneVerified已为true（防止跳过手机号验证）→ 更新Couchbase里的user.status为true → 返回成功响应给客户端
   • 客户端收到响应后，再跳转页面或更新界面状态

总结一下：客户端做体验层的即时校验，服务端做安全层的全量校验，所有业务状态的修改必须由服务端主导——这样既能保证用户体验，又能守住安全底线。

内容的提问来源于stack exchange，提问作者Surikate