不少小程序打开就弹授权，用户还没看到任何内容就要交出手机号。这种做法能拿到一部分用户，但流失的那部分往往更多，而且流失的人不会告诉你原因。
登录设计的核心问题是，什么时候要，要什么。
一、登录态是怎么一回事
用户在小程序里第一次进来，系统会给他一个临时的标识，这个标识跟微信账号绑定。有了它，系统能识别这是同一个用户，但他的身份信息还是未知的。
要拿到身份信息，需要用户授权。授权分两层，一层是基本的昵称头像，一层是手机号。前者的授权按钮现在也有规范要求，后者需要用户点专门的按钮并确认。
拿到这些信息之后，系统可以建立自己的用户档案。后续用户再进来，通过临时标识找到对应的档案，就不需要重新登录。
二、什么时候该要手机号
判断标准是有没有业务需要。需要联系用户、需要核验身份、需要跨设备同步数据，这些情况下手机号有实际用处。只是想统计用户数、想做推送，那手机号不是必需的。
时机上要往后放。让用户先看到内容，或者先完成一次浏览，在他要执行需要身份的操作时再要。比如浏览商品不要，下单结算要。查资料不要，提交表单要。
要的时候说清用途。弹窗前用一句话说明要手机号做什么，比如用于接收订单通知、用于联系您确认预约。有说明的授权通过率明显高于直接弹窗。
要允许不授权也能用。除核心操作之外的部分应该都能用，用户拒绝授权后不要直接退出小程序或者卡死在弹窗上。
三、登录环节的几处坑
第一处是登录态过期没处理。用户的登录态有有效期，过期之后接口会返回未登录。如果程序没处理这种情况，用户点任何按钮都失败，又不知道要重新登录。合理做法是检测到未登录时引导重新登录，登录完回到原来的操作。
第二处是切换账号不彻底。用户退出再登录另一个账号，如果本地缓存没清，会看到上一个账号的数据。涉及账户余额、订单这类数据，串号的后果很严重。
第三处是手机号换绑。用户换了手机号，系统要能支持更换，并且旧号要能解绑。不支持换绑的系统，用户换号之后就只能重新注册，历史数据全丢。
四、用户资料怎么维护
昵称和头像要允许用户自己改。微信授权带来的昵称头像只是初始值，很多用户后面会想换成别的。不能改的系统体验会打折扣。
资料的完整性可以引导，不要强制。缺手机号、缺邮箱这些，可以在合适的时机用提示引导补充，补充之后给点好处，比如送点积分。强制要求填完才能用，会赶走一部分用户。
注销功能要有。用户想注销账号，要有地方能操作。相关规定对这一点有要求，而且注销之后的数据怎么处理也要有说法。做一个注销入口并不复杂，但很多小程序漏掉了。