登录功能是每个产品的基础功能，用户已经习以为常了，但对于产品经理来说，这是打开用户通往产品世界大门的“钥匙”，需要好好设计。

在用户看来，登录像是一个一次性的功能，很多 APP 在手机上登录过一次之后，在下一次换手机之前，都不会再看到登录页面。

对于用户而言，登录功能是“平平无奇”的，但产品经理却不这么认为。

一、同样的一把锁，有的人选择装在入户门上，有的人选择装在房间门上

目前登录功能的放置逻辑有两种主流的设计：登录前置和登录后置。

登录前置是指用户打开应用时，应用会要求用户先进行登录，登录成功后，才允许用户访问资源。

这种逻辑就好像将锁装在入户门上，要想进入房子，需要先打开入户门上的锁。代表的应用有微信、支付宝等。

登录后置是指用户打开应用时，可以访问应用的部分资源，当用户访问需要账号权限才能访问的特定资源时，才要求用户登录。

这种逻辑就像将锁装在房间门上，你可以随意进入房子，但是想要进入房间，则需要先打开房间锁。代表的应用有抖音、淘宝、京东等。

登录前置还是后置，主要看“资源”。

如果应用的资源基本都是属于“隐私资源”，则需要将登录前置，比如微信、支付宝等，访问的资源基本都是社交、聊天、支付等隐私信息，所以会采用登录前置的设计，就好比你家客厅放着电视沙发电冰箱，你最好给你的入户门上把锁。

如果应用的资源多数是属于“公开资源”，则可以将登录后置，比如抖音、淘宝、京东等，访问的资源都是短视频、商品等，这些都是可以公开访问的资源，只有当你想查看自己的订单或收藏等，涉及到自己的“隐私资源”时，才会要求登录，就好比你家里客厅空空如也，贵重物品都放在房间里，或许你可以做到夜不闭户，但是房间门你确定不上一把锁吗？

二、开锁的时候再来配钥匙

相比以前的账号密码登录，现在应用的主流登录方式变成了验证码登录和第三方授权登录，这样的登录方式弱化了注册的概念。

一般在登录的时候，如果账号不存在，系统会自动注册一个新的账号，这个注册过程对用户而言是无感的。这就好比要开锁的时候，发现没有钥匙，以前的方式是让你跑到另外一个地方配一把钥匙，再跑回来开锁，现在是当场就给你配一把钥匙，直接开锁。

手机验证码已经变成大多数平台首选的登录方式。

有的应用依旧保留了账号密码登录的设计，如果用户首次登录是用手机验证码登录的话，则会出现一个问题，就是新注册的账号没有密码，针对这种情况，一般有3种解决方案：

1、在设置中增加设置密码的入口，如果账号没有密码，则显示入口，如果用户已经设置了密码，则可以将该入口改为修改密码的入口。

2、调整注册流程，在注册账号时增加设置密码的功能。

3、在使用账号密码登录的时候进行判断和处理，这种就比较复杂了。

首先要在登录时进行校验。

然后还需要增加一个未登录状态下设置密码的流程。

也有用户不喜欢接收短信验证码等待的那几秒钟，从而选择第三方授权登录。

授权登录会跳转到第三方应用，由用户点击同意授权，授权成功后获得第三方应用分配的“用户 ID”，系统再将取得的用户 ID 在系统中查找是否有绑定的账号，如果没有绑定账号，则说明之前用户没有使用该 ID 授权登录过，则可以创建新账号并绑定 ID。

这种方式带来的问题比手机验证码更多，账户只能拿到一个第三方的用户 ID，这次不止没有密码，连手机号都没有了。如果用户下次换成手机验证码登录，这个时候就会再注册一个账号，两个账号数据是隔离的，这个对用户来说无疑是一种困扰。

因此，除了那些只支持第三方授权登录的平台，凡是通过第三方授权登录成功的，如果账号还没有绑定手机号，一般都会要求绑定。

当然，如果是新注册的账号，你也可以在绑定手机号之后再要求用户设置密码，但是这个操作对用户来说太过繁琐，一般都会舍弃这个环节。

三、以锁解锁

世界上有一种最难解决的问题，叫做——历史遗留问题。

产品的形成是迭代的结果，在不同的阶段会呈现不同的形态，但这些形态不总是兼容的。可能在某个阶段，产品的登录是以手机验证码为主，到了某个阶段变成了以第三方授权登录为主，前期他们可能是独立的，不同的登录方式会注册为不同的账号，等到了某个阶段，要将这两种方式融合的时候，这才发现问题来了，一个已经有数据的第三方授权登录账号要绑定一个已经有数据的手机验证码登录账号，这个时候就冲突了。

这就好比一个门只能上一把锁，此时你手里有两把锁，你的意图是将两把锁都上上去，这个时候就冲突了。这个时候只能“以锁解锁”，这个不是什么高深的理论，说白了，遇到这种情况，你要么轮流使用两把锁，要么主动放弃一把锁，或被迫放弃一把锁，只使用其中一把锁。

从产品上而言，就是用户可以选择不将第三方账号绑定到这个手机号，还是两个账号，分开使用，如果一定要将第三方账号绑定到这个手机号，系统则只能要求你注销其中一个账号，只保留一个账号。

用户可能是在登录时使用第三方授权登录，被要求绑定手机号，结果手机号也注册了账号。

也有可能是在已经绑定了手机号的账号内绑定第三方账号，或在已经绑定第三方的账号内绑定手机号发现账号冲突，基本思路都是相同的，都是要求注销其中一个账号，只保留一个账号，保留的账号就可以同时绑定手机号和第三方账号。

为什么要做这么“极端”的设计呢，主要是因为两个账号都有数据，如果不注销其中一个，强行合并两个账号数据，有些数据就会产生冲突。

举个例子，假设我要合并两个账号，类似订单这些数据是可以合并到一起的，但是如果是类似头像、昵称等等这些信息，一个账号不能同时存在两份信息，只能保留一份，那到底要保留哪个账号的呢。

或许你认为可以将能合并的数据进行合并，不能合并的数据让用户选择保留其中一个账号的，这种理论上是可行的，但是后续每开发一个跟账号有关的功能，都得考虑哪些数据可以合并，哪些数据得放弃合并，成本太高，远不如让用户注销其中一个账号来的经济。

所以，对用户来说平平无奇的登录功能，其实正是产品经理打开用户通往产品世界大门的“钥匙”。