本篇文章给大家谈谈前端登录注册页面总结，以及后端注册登录界面对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。

本文目录一览：

• 1、登录注册小结
• 2、用户系统设计(上)前端设计和多平台账号打通
• 3、注册与登录界面的设计思考
• 4、超详细的登录注册的业务逻辑流程梳理

登录注册小结

ps：最近在总结过去几个月从事产品工作以来的资料，上次说到要总结注册登录的设计，自己挖的坑哭着也要填完。

ps2:这些总结均源自于项目中一点一滴的总结，可能不是很完善，各位看客需留意。

一、登录从pc端到移动端

移动端的登录沿袭了pc端的很多经验，但也有其独特的演变。

1、pc端

1.1 pc端具有公共属性，输入密码是隐私，需要对密码进行保护；

1.2 pc电脑不可移动，如果是笔记本电脑可移动但使用场景也相对固定，网络环境较好设备稳定；

1.3 屏幕尺寸更大利于展示更多内容，一般全部信息在一个页面内展示；

1.4 鼠标键盘输入方便输入成本低；

2、手机端

2.1 手机设备本身具有私密性，用户在输入时，可对密码进行保护；

2.2 手机设备随身携带，网络环境不稳定因素较多；

2.3 屏幕尺寸小内容可能需要分多屏展示；

2.4 输入成本高，输入麻烦；

二、设计前思考

（目的）为什么要设计这个功能，（时机）什么时候需要注册，（必要性）是否一定需要账号体系，第二步，得了解这个功能前是什么业务，之后跳转到什么页面，从产品的整体角度回答这个问题。

三、注册登录设计的步骤

1、登录模式梳理和信息结构的设计；

2、梳理登录流程，把每一步都列出来，做好各种情况的梳理；例如：用户登录忘记密码忘记后，卖家如何找回。

3、交互设计1：画出每一步的简单线框图，对页面的元素进行初步布局；

4、交互设计2：对每个页面的页面元素、页面跳转、操作反馈、异常处理、按钮和页面的各种状态等做出设计；

5、自行检查，可以制作高办真原型；

6、输出prd；

四、设计范例

主要以一款app手机号注册为案例，对上一步中的交互设计做出详细的说明。

1、账号

1.1 账号有无格式要求，如果是手机号，前端是否需要验证手机号有效性；

1.2 手机号那种格式，3-4-4格式还是普通格式；

1.3 手机号输入键盘是否弹出？键盘是否为数字键盘；

1.4 如果为手机邮箱，是否需要输入提示？前端是否需要校验邮箱格式？

2、密码

2.1 格式：密码的字数限制？最多几位，最少几位？

2.2 有什么要求，是英文+数字还是可以包含特殊符号？如“空格”或者“@”等。是否区分大小写？

2.3 提示文字为“位”还是“字符”？如“请输入6-16位字母或数字”

3.3 密码输入框默认为密文还是明文，是否可切换

3.4找回密码和重置密码有何区别

3、验证码

3.1 验证码位数4位or6位？是数字还是英文+数字？是否区分大小写？

3.2 倒计时时长？是button还是label?

3.3 验证码输入框一般比较短。

3.4 验证码的获取上限，有效时间，超过有效时间给出什么提示？

3.5 验证码的触发，为什么有些设计为点击那妞页面跳转时获取，有些页面跳转后再次点击才能获取？为什么有不同？

3.6 验证码倒计时状态有何变化？重新获取后，原验证码怎么处理？

3.7短时间内多次获取验证码是否还要给用户发送验证码？还是提示验证码已发送请输入？

4、错误提示

4.1 报错是的报错文字是什么？提示格式是弹窗、Toast、还是在当前页面文字显示？

4.2 Toast是没有焦点的，而且Toast显示的时间有限，过一定的时间就会自动消失。

4.3 弹框会阻断用户操作，需要手动点击确认以后才会消失。

4.4 在当前页面文字显示的话，提示文字摆放的位置，页面格式根据提示文字的变化，需要有怎样的视觉效果？

5、异常提示

5.1 点击【获取验证码】，检测手机号已被注册，如无置灰设置，输入框为空，手机号码无效的情况，故需提示：

5.1.1 手机号已被注册，是否提示用户登录？

5.1.2 手机号不能为空，多次为空状态点击是否给出频繁操作提示？

5.1.3 手机号码不正确，“请输入正确的手机号码”是不是比“手机号码错误”好些？

5.2 点击【注册】时，可能会有输入框为空，验证码无效等情况，如无置灰设置，故需提示：

5.2.1 短信验证码不能为空

5.2.2 验证码已被使用，然后给出什么操作呢？

5.2.3 验证码已过期，过期了给出弹窗吗？在弹窗直接获取验证码？

5.2.4 验证码错误，弱提示？

5.2.5 验证码已达到最大尝试次数，最大是多少次？

5.3网络状态不好，给出怎样的提示和反馈？

5.4手机没开wifi或者流量，是否/如何指导用户进行设置？

5.5服务器没有正常接收请求或没有回复，给出怎样的提示较好？

5.6用户所处环境网络信号不好（用户向服务器请求超时），是否需要检查用户的网络状态？还是只给出提示？

5.7注册流程中，检测到手机号码已经注册，是否可以继续获取验证码？然后验证直接登录免去页面跳转和输入密码？

5.8密码第一次错误怎么给出提示？第二次仍然输入错误提示是否需要强提示，给出找回密码的按钮？在弹窗点击找回密码，手机号码在新页面是否需要重新填写？密码连续多次输入错误是否做出禁用限制？

5.9登录时，账户是否在其他设备登录，是否允许多端同时登陆？不允许同时登陆，之前登录设备的账户是否要下线？给出怎样的提示？

6、短信验证码

6.1 短信验证码一般通过第三方通道发送，在技术侧做规避，还需要在产品规则上做一定限制；

6.2 短信验证码的文本格式，

7、邀请码

7.1 注册是否为邀请注册？如是邀请注册，邀请码格式如何设计？

7.2 邀请码错误提示，填写了邀请的用户和没填的用户，在注册成功后有何区别？有邀请码的用户是否有奖励？

8、注册成功后的提示、状态变更及跳转

8.1注册成功后同时1切换为登录状态

8.2给予注册成功的提示并跳转到原网页，原页面是否需要缓存？

8.3注册之前有第三方登录，用户注册后还需要用户绑定第三方账号吗？

9、输入框

9.1手机号账号，显示格式为3 4 4 格式还是一般格式？

9.2验证码输入框一般比较短。

9.3密码输入框默认为密文还是明文，是否可切换？需要切换

9.4其他输入框，如邮箱、邀请码、昵称、个人信息等根据使用场景的不同自行设计；

9.5 不同输入框的提示内容和显示状态

9.6是否需要一键清除按钮“x”，何时显示这个按钮？点击后虚拟键盘是否需要缩回？

10、按钮

10.1按钮的位置，长度、文字

10.2按钮的设计，不同状态也要考虑。默认灰置还是高亮？灰置的条件是什么？

10.3按钮提交反馈，文字是否需要变化

11、返回按钮

11.1 在注册、找回密码、第三方登录等操作流程中，返回时需要特别注意点击返回后的操作提示；比如注册手机的修改，验证码提交后设置密码等。

11.2 点击返回时，干扰了正常流程的操作一般需要强提示，提示弹窗注意文案和按钮文字设计

11.3 点击返回后，当前页面和目标页面状态是否变化？例如手机号码是置空还是显示已输入的手机号码？

11.4 浏览应用过程中进入登录页面，登录页面是否需要有返回按钮？

12、虚拟键盘

12.1虚拟键盘何时弹出？触发条件是啥？

12.2虚拟键盘的类型根据表单不同而不同

12.3虚拟键盘上的GO是否有变化？变成“完成”还是“登录”？

12.4键盘何时隐藏？如何隐藏？

13、第三方登录

13.1 昵称的长度设置，不同平台的账户昵称的长度要求不同，该如何获取？

13.2 绑定多个第三方账户，公开信息如何获取？公开信息不同如何处理？

13.3 用户使用第三方登录，是否还有绑定手机号码？

13.4 登陆后是否需要完善账号资料，如手机号？

用户系统设计(上)前端设计和多平台账号打通

前言

用户系统是很多产品最基础的构成之一，但是越是基础越是开源设计想要完善也更难。在设计用户系统的时候，首先想到的关键词是注册和登录。但并不是有这两者就足够了，更加完善用户系统本身还需要考虑：多平台账号打通，同平台账号之间绑定与解绑，账号安全等及需要怎样的前端设计才是满足这个产品本身定位和用户操作的设计。

用户系统的实现简单来说有两种方式：1、自己构建用户系统；2、用第三方授权。第三方授权获得的用户信息有限且受制于人，而自己构建用户系统研发及用户使用成本均不如第三方授权。所以更多的是两者并存，相互补充。

在定义服务端字段或需求若有不完善和不专业的地方，希望大家多提意见，共同完善。

一、总结需求

1.用户系统基本注册／登录功能及前端页面设计

2.多平台账号打通，即在单一app注册的用户，能够使用此账号登陆系统内所有app

3.用户相对独立，对于单一app来说用户身份唯一

二、前端设计

登陆注册主流设计有三种（原型如下）

1. 账号密码优先

账号密码优先是最常见的一种登录注册设计，适用于普遍场景，鼓励用户用注册方式登录，有利于产品引导用户完善更多的资料，留存自己的用户信息。例如知乎是以账号密码登录为最优先，且会隐藏第三方授权登录。现在的账号密码登录都会以用户注册方式代替系统生成的userid作为账号。纯账号密码登录是较为早期的设计，例如早期qq和飞信。

2. 手机号快捷登陆优先

手机号快捷登陆，也叫免密登录／短信验证码登录，适用于用户不登录能够完成大部分行为，只有在某种场景下必须获得用户身份时才需要用户登录，且此时用户的想要完成的行为是被要求登录操作打断的。常见的如团购类产品，用户在应用内进行了商品的浏览、筛选、添加到购物车，当要进行最后一步付款操作时，发现未登录。这时繁琐的注册或者登录都有可能导致这笔订单甚至这个用户的流失。所以这时获取用户身份的方式一定要尽可能便捷。

3. 第三方授权登陆优先

第三方授权登陆，适用于对用户资料和权限要求不高快速解约开发成本的产品。建议在应用构建用户系统的前期可以首先接入第三方，快速的实现登录功能。但是若想建设自身关系链还是需要完善自己的用户系统。

用户资料实际也属于用户系统等设计的内容。是否要增加此项的判断原则是根据这个产品对用户资料的需求程度决定用户注册时是否要增加资料填写页，资料填写页是强制阻断性的还是可跳过的，必填的资料项有哪些，希望填的有哪些。例如是需要关系链的那么注册的时候就应该强制用户去填写资料设置必要的昵称和头像，这样的用户对于此类应用来说才属于有效用户，不然在app内用户点进资料页，全是系统自动生成的垃圾信息，对于建设关系链和留存伤害较大。

交互细节上又可以延伸用户进行注册或登录需要几个步骤？这些步骤是在一个页面上承载还是一步一个页面以多页面去承载？单一页面承载的优势是用户能够有很清楚的预期，他完成注册需要进行哪些操作，但是劣势是一个页面承载过多信息显得杂乱，操作的次序也会不明确；多页面承载的劣势是用户对完成注册的具体行为没有完整预期，更容易跳出，优势是页面整洁并且路径单一，能引导用户完全按照通畅的预设路径进行。我个人更推荐后者，因为用户预期可以用页码／步骤管理用户预期。

下面是我根据我们产品的定位和需求设计的用户登录／注册系统原型：如上所说，我设计的用户系统是需要承载多产品的，所以我设计融合账号密码登录和手机号快捷登录两种方式，以用户出发需要登录的场景去切换展现在用户面前的是哪一种。

补充一些贴心的小点：

1.申请读取本机号码权限，并帮用户填写

2.申请读写短信权限，获取到验证码后自动填写并点击下一步

3.应该前置到提醒：上次登录方式，合法的手机号，正确的图形验证码等等

三、服务端设计

很多产品，特别是没有技术背景的产品不会去接触和设计服务端需求，实际上我自己日常工作中接触服务端需求也并不多，并不是说产品要负责设计一个完善的用户系统服务端，而是要学会以服务端同事能懂的方式表达清楚自己的诉求，两边对功能的实现不会有太多的偏差，这是产品设计服务端目的所在。

简单的用户系统服务端的基本功能需求为：判断账号身份（注册/未注册），账号身份生成（新用户分配id），账号密码验证；这里要设计的并不满足于注册登录，需要考虑多平台账号打通的用户系统并且要和在打通情况下单一平台或多个平台之间，用户的多个账号之间绑定于解绑。现在先说一下多平台账号打通需要考虑哪些问题：

1.用户系统身份的创建，因为我们是多平台的系统，所以用户身份只能纳入手机号注册的用户，若第三方授权注册的也算用户系统用户，在账号绑定的那一关则会出现混乱；

2.实现多平台账号打通，要实现多平台账号打通，即所有接入多平台都能够查询到此用户身份；

3.平台间用户身份独立，要实现平台间用户身份独立，则需要在用户系统用户身份的基础上创建一个平台的用户身份；

(一) 用户系统多平台打通

名词解释

1)Appid：接入用户系统时首先分配，用于区别接入的各个app；

2)Unionid：用户手机注册时，由用户系统根据手机号创建，在用户系统作为用户唯一身份标识；

3)Appuserid：用户注册时，由app服务端根据union或者第三方授权的openid创建，在app内作为用户唯一的身份标识；

基本原则

1)手机号作为用户系统账号的注册的唯一途径，根据手机号在用户系统服务端创建并保存unionid；app服务端根据unionid创建并保存appuserid，且将unionid对应保存；

2)用户系统同一unionid可对应不同的appuserid

3)使用第三方openid授权的注册用户不计入用户系统仅存在app服务端作为单app用户，即unioid为空只生成appuserid；第三方授权包括微博微信，QQ，Facebook，Twitter

1. 主线流程图

手机号注册主流程为：

用户注册时，用户系统服务端需要验证手机号＋验证码是否为真，此手机号是否已有对应unionid；若有提示已注册，请登录；若无创建对应unionid，app服务端根据unionid创建appuserid。至此成功生成了用户系统身份及当前app用户身份。

手机号登陆主流程为：

用户登录时，用户系统服务的验证手机号＋密码是否为真，此手机号是否有对应unionid，若有，则说明此用户有用户系统身份。

还需要app服务端需要查询是否有对应的appuserid，若有说明此用户有此app身份，直接用其appuserid登录；若无则说明是用户系统内其他联合app注册用户根据unionid创建此app的用户身份，至此登录成功。

用户系统是大多数app都会有多构成，单一的用户系统也并不那么复杂，但是若要构建产品矩阵进行多平台间的用户打通，加上帐号绑定与解绑，并不是一时半会能够想清楚的需求，若大家感兴趣为会继续补充帐号绑定和账号安全产品应该关心和设计的事情。谢谢：）

注册与登录界面的设计思考

登录和注册过程往往是产品和用户的 first sight，因此登录注册入口是给用户留下好的第一印象的关键。遵循「所有的设计都应有据可循」的原则，下面通过对登录与注册几个关键问题的探讨，来思考登录与注册界面的设计逻辑。

1.注册页面的需求是什么？

2.默认注册还是登录？

3.邮箱注册一定要验证通过么？

4.关于手机登录与第三方账号登录

5.iOS 11 带来的新登录方式

6.为什么需要注册？

登录页面比较好理解，我们重点来看注册页面，以 Spotify 为例，以下是一个非常典型的传统注册页面。

由此试图分析，在注册场景下，用户和产品两个维度上的需求如下。

用户需求：

1）进入应用；

2）获得应用完整功能（评论、点赞、收藏等）。

产品需求：

1）获取、验证用户的账号与密码信息；

2）获取用户个人信息、联系方式；

3）告知用户协议；

4）订阅邮件。

首先总体上我们可以发现，用户与产品在注册场景下存在需求冲突。用户对于注册界面的需求非常简单明确，就是为了快速进入应用或者获取完整功能。不会有用户想要主动阅读成百上千字的用户协议，也不太愿意主动提供个人信息或是订阅邮件。因此，产品角度的第 (2)(3)(4）需求在注册场景中，都是对用户体验的破坏。所以，尽量避免产品需求对用户体验的破环，更多地给予用户情感安慰，这是设计注册界面的大原则。

豆瓣默认是登录，Airbnb 默认是注册，而锤子的系列软件将注册与登录按纽都并列在下面，不做默认。

考虑到目前 App 普遍采取的「长久性登录」策略，默认为「注册」也不失为一个具有概率意义的选择。毕竟大家都通常只会在换机、重置系统、登录失效、主动退出这些低频时刻来登录。但其实这个问题，没有通行的做法，更没有绝对意义上的好坏。每个产品根据各自定位和情况的不同，会有不同的侧重点。比如说，约 8 亿用户量的国民级社交应用 QQ，绝大多数场景下都已经没有了「注册账号」这一需求，默认为「登录」操作，同时将「注册」入口极大弱化是比较合适的。而定位于垂直领域的社交应用脉脉，目前拥有约3000 万用户量，目标用户群体中仍然有非常大的潜在用户量增长空间。因此，第一次进入脉脉，在并列给出注册和登录入口的同时，默认引导用户进行「注册」操作。

想到这一步，笔者突然想到，如果是同一产品面对不同市场，注册登录会不会有针对性的侧重点呢？比如说，instagram 在海外用户基数庞大，而在大陆则较为小众，会不会出现海外区 ins 默认为登录，国区 ins 默认为注册呢？笔者特意找到身处海外验证，遗憾的是，两者除了语言的变化之外，并没有其他不同。

其实，默认注册还是登录并不重要，无论做何种默认都无法完全避免用户的误操作，即在登录界面填写注册信息，或者反之。那么怎么避免这种情况呢？

首先，不要急于让用户填写登录/注册表单，可以先让用户确认选择。

其次，可以在文字和样式上对二者进行比较显著的区分。文字方面，英文语境下，Sign up 与 Sign in 容易产生混淆。比较好的解决方案是用 Sign up / Log in，或者 Register / Sign in 等方案。

用词混淆的情况，中文语境下情况会好一些，「登录」与「注册」天然具有区分度，但是仍然可以在文字样式上设定足够的差异，给以足够的提示，引导用户进行正确操作。

此外，可以输入信息后及时反馈，避免全部表单填写完毕再给出反馈。（没找到比较合适的案例，自己动手做了一个...）

其实不管怎么避免，用户依然有将登录与注册弄混淆的可能。关键在于，在用户在错误的界面花费了时间与精力填写信息之后，如何降低用户的纠错成本，也就是说： 如何解决「登录」与「注册」两种界面切换时，发生的数据丢失。 相比较在注册页面粗暴地告诉用户「这个手机号已注册」，更好的解决方案可以是「询问用户是否需要登录，并在登录界面自动转填已填写的信息」，确保用户即使犯错了，也可以辅助其跳往正确的目标，这能大大减轻用户的犯错成本，也可以给人一种产品很「聪明」的印象。

或者，不给用户犯错的机会，弱化「登录」和「注册」，只给出一个「登录身份」的输入框，附带一个「下一步」的按纽。后台验证用户输入的「登录身份」，来判定是登录还是注册。

从用户体验的角度而言，产品应在用户注册后自动登录。而不是通过验证后，再次由用户登录。因此，可以将验证放置在注册完成之后的某个时刻，利用虚拟奖励、功能限制、安全恐吓等方式激发用户去完成验证。

长久以来，为了避免用户注册时输入了错误密码，要求用户输入两次密码也是一种惯例。然而事实上，「注册时输入错误密码」与「忘记密码」并没有本质上的区别，「输入错误密码」并非十分严重的错误。此外，用户容易输错密码的原因是密码通常隐藏显示，而加入「显示密码」选项，也能从根本上更好地防止输入错误。

网页端常常使用「输入两次登录身份」的方法，来避免登录信息的输入错误，但是面对移动设备的输入压力，确认两次「登录身份」的做法并不友善。但是，如果不及时确认登录身份正确的话，在「注册后立即自动登录」的大前提下，「输入错误登录身份」会带来不可逆的后果。一旦在注册时填写错误登录身份，在账户验证期限内无法验证账户，轻则需要重新注册，重则丢失在验证期内产生的所有用户数据。

进一步思考，抛开问题看本质，验证的本质是确认「登录身份」是正确的，可联络的。从这个角度看，验证账户更像是一种事后的纠错机制，而并不能避免用户犯错。那么，怎么降低用户犯错的可能性呢？

可能的解决方案有：

1）增加注册确认界面，降低确认成本。放大「登录身份」信息，让用户无法忽视，并只需点击即可确认。

2）账户未验证时，允许用户修改一次登录身份，并要求输入两次登录信息，在前端验证一致性。

手机 + 验证码登录与第三方登录是目前 App 最为流行的做法，免去了注册过程，改变了账户密码的登录方式。WhatsApp 是最早将手机号码和账户绑定在一起的 App 之一。通过手机号码一键注册/登录是 WhatsApp 获得巨大成功的关键。其创始人 Jan Koum 曾经说到： 「有过传统通讯 app 的痛苦体验，再看看如此简洁的界面，你就明白我们的初衷了。只需要短信就能解决的事，我们有什么理由不做呢？」

此外，对于产品而言，通过第三方登录，产品还可以获取用户的个人信息，甚至是好友关系。

iOS 11 为 iCloud 钥匙串进行升级，在原本 Safari 保存和自动填写密码的基础上，也为 App 提供此项功能。在需要帐号密码的页面输入时，系统键盘会显示 🔑 符号，通过 Touch ID 验证后会自动填入，同时该功能还支持匹配提醒，优先为你显示和该应用有关的密码信息，非常方便。如果你完全生活在苹果的生态中，那么你可以使用这一功能来替代 1Password 和 LastPass。

1Password 等密码工具在 iOS 11 也有了更大的可能性，现在可以直接在注册登录表单中调用了。

跳出「如何设计」的思维框架来进一步思考「为什么设计」，不难发现，其实从用户的角度而言，注册登录更像是「为了正常使用产品，而不得不做的一个步骤」。尤其在接触一款新产品时，注册流程都会在一定程度上打击用户的积极性。那么问题来了，是否所有产品都需要注册，才能使用或是正常使用呢？

1）登录才能使用的产品，需要采用「立即注册」的方式，最典型的例如社交应用

2）不需要登录也能开始使用的产品（如浏览内容），可采用「稍后注册」的方式

首先是内容为主的产品：比如微博，知乎，站酷等，无需注册登录便可以浏览，但是回复、收藏、发帖这类操作必须注册或者登录账号；再其次是有同步和备份需求、有用户数据沉淀的工具类产品，比如记事、记账、todo、日历等等。

不过，其实利用苹果的 iCloud Drive 同步功能，大多数工具类应用也可以避免注册登录操作。当然前提是完全生活在苹果的生态中。

3）无需注册就能正常使用的产品，尽量不要要求用户注册。

比如大部分纯粹的工具类应用，比如时钟、计算器等。以及部分没有同步或备份需求的工具类应用，比如说便签、私密相册等。即使是便签与私密相册这类有特殊用户数据沉淀，也可采用密码（数字密码／手势密码）或是指纹识别的方式来保证数据的安全性，避免注册程序破坏用户体验。

此外，有时候限制注册、提高注册难度这类看似对用户不友好的方式，在特殊的情况下也是一种很好的策略。比如早期的知乎、Dribbble 的发帖权限采用的邀请制、还有 B 站的 up 主考试，虎扑的答题考试，这类 UGC 内容较为丰富的产品，通过提高创作权限的门槛，能有效地保证核心用户和内容的质量。同时，用户由此产生的「付出感」，也有利于其对产品及其使用权利的珍惜，进而触发「特权」的感受。

以上是针对注册与登录界面的几个关键问题展开的引申探讨。其实笔者写到一半时，发现注册登录的水特别深，除上述内容之外，还有非常多的场景与细节值得挖掘与思考。不过设计就是如此，很多看起来似乎非常基本的内容，但是背后需要大量的思考和打磨，绝非一句「好看」就算完成。设计的复杂性，也让我始终保持着一颗敬畏之心。说得不好，希望大家多多批评指正，感谢各位。

超详细的登录注册的业务逻辑流程梳理

这是早前实习期间做的一个登录注册流程的优化，主要是关于登录注册的业务流程图(Transaction Flow Diagram)梳理，包括短信验证码登录、账号密码登录、第三方登录、忘记密码、图形验证码等以及注意的一些情况。

登录注册在不同的产品中有不同的体现，因为对于它的很多功能细节使用的好坏也没法一概而论，还是基于具体场景考虑。

这是早前实习期间做的一个登录注册流程的优化，主要是关于登录注册的业务流程图(Transaction Flow Diagram)梳理，包括短信验证码登录、账号密码登录、第三方登录、忘记密码、图形验证码等以及注意的一些情况。

业务流程图中最主要的几个问题就是：

业务流程图表现形式我用的泳道图，可以突出用户操作、后端系统、前端页面之间的逻辑关系，以及如何运作。

一、手机验证码登录

注意事项：

二、图形验证码流程

注意事项：

三、账号密码登录

注意事项：

四、第三方登录

注意事项：

五、忘记密码流程

注意事项：

总结

△ 当时做的简单超低保真版原型

回到最开始，登录注册里的很多功能细节使用的好坏没法一概而论，还是基于具体场景考虑。

在我之前两份实习中，我的两位导师都告诉过我，登录注册的逻辑是几大复杂场景复杂逻辑之一(此外还有购物车的逻辑，退换货的逻辑等等)。

以上是我对登录注册的业务逻辑和一些需要注意的 case 的总结，也算是理了下最近比较乱的思绪，希望有不同想法的大家多跟我交流。

印象很深的一句话是：做任何分析的时候，不要拘泥于表面，去思考背后的逻辑与深层原因，不需要得到一个准确的答案，思考的过程本就是一种收获。

关于前端登录注册页面总结和后端注册登录界面的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。