小程序如何处理手机号授权、账号绑定和换绑流程？

简化版

小程序账号绑定通常以微信身份作为入口，再按业务需要获取手机号并绑定站内账号。设计时要区分 openid、业务用户、手机号三者关系，处理首次绑定、已有账号合并、换绑、解绑、风控和隐私授权，不能把手机号当作永久唯一身份。

常见流程：

关键点：

openid、手机号和业务用户 ID 是三回事。openid 标识某个用户在某个小程序下的微信身份；手机号是联系方式，可能换号、注销、二次放号；业务用户 ID 才是你系统里的账户主体，承载订单、余额、课程、积分等资产。

如果把手机号直接当作唯一用户 ID，后续换绑和二次放号会非常麻烦。更稳的做法是系统内部生成 userId，再把 openid、手机号等作为登录方式或绑定信息。

业务用户 userId
  ├─ 微信身份 openid
  ├─ 手机号 phone
  └─ 订单、权益、积分等资产

用户刚打开小程序时，未必需要提供手机号。强行索取会降低信任。更合适的时机是提交订单、预约服务、联系客服、领取权益等确实需要联系或校验身份的动作。

例如首页索权转化率可能只有 20%，提交预约时索权可能达到 70%。因为用户此时知道手机号用于预约确认或服务通知。授权时机本身就是产品体验的一部分。

用户授权手机号后，服务端要判断这个手机号是否已经绑定其他业务账号。如果没有，可以绑定当前 userId；如果已经存在，要让用户确认是登录已有账号、合并资产，还是提示冲突。

危险做法是直接把手机号从旧账号挪到新账号。这样可能导致旧账号订单和权益无法找回。账号体系的核心是资产归属，手机号只是入口之一。

手机号授权成功
  ├─ 手机号未绑定：绑定当前 userId
  ├─ 已绑定当前 userId：直接通过
  └─ 已绑定其他 userId：进入确认/合并流程

换绑手机号是敏感操作。用户必须先证明自己是当前账号主人，再证明新手机号可用。常见方式是登录态校验、短信验证码、支付密码或其他二次验证。只靠当前小程序会话直接换绑风险较高。

数字例子：如果账号里有余额 500 元或重要订单，换绑手机号相当于改变找回入口。一次被盗会话就能换绑，会让攻击者长期控制账号。因此换绑安全级别应高于普通资料修改。

有些业务允许解绑微信或手机号，有些不允许完全解绑。判断标准是解绑后用户是否还能找回资产、是否影响订单履约、是否满足监管或客服要求。比如付费课程账号，如果解绑所有登录方式，用户可能再也无法登录。

比较稳的规则是：至少保留一种可验证登录方式；解绑前提示影响；高价值账号需要二次确认；解绑后记录审计日志，方便客服追踪。

手机号属于个人信息。获取前要说明用途，存储时要加权限控制，日志里不要打印完整手机号。展示时通常脱敏，例如 138****5678。导出、客服后台和埋点系统都要避免明文扩散。

服务端接口也要防越权。查询绑定状态时只能查当前用户自己的信息，不能让前端传任意 userId 查询手机号。

记忆钩子：openid 是微信身份，手机号是联系方式，userId 才是资产主体；绑定流程围绕资产安全设计。

误区：手机号就是用户唯一 ID。 手机号可能换绑、注销和二次放号，系统应使用内部 userId 承载资产。
误区：用户授权手机号后可以直接覆盖旧绑定。 覆盖可能导致资产串号，应判断冲突并走确认流程。
误区：换绑只是普通资料修改。 换绑改变登录和找回入口，应做二次验证和审计。
追问：openid 和 unionid 有什么关系？ openid 面向单个小程序，unionid 用于同主体多应用打通身份，具体可用性取决于平台条件。
追问：手机号授权失败怎么办？ 提供其他登录或手动填写验证路径，不应让非必要页面不可用。
追问：如何保护手机号隐私？ 最小化采集、脱敏展示、限制后台权限、日志不打印明文。

账号绑定用“三身份一资产”记：openid 识别微信入口，手机号用于联系和验证，userId 承载真实资产。首次绑定要查冲突，换绑要二次验证，解绑要保证还能找回，隐私数据要少采、脱敏、控权限。这样回答既懂小程序，也懂账号系统。