注册：用户告诉系统WhoisTom，系统记录Tom和口令。
1.2Passport产品线及近亲
注册、找回密码、修改密码都是低频操作，但都属于迫切程度比较高，也最容易引发挫败感，导致用户投诉及放弃使用产品。
1.4术语：查重、校验、验证、匹配
查重，“查询是否有重复存在”的简称，比如：排除以手机为主键的重复注册。
校验，检查数据是否符合格式，比如：输入的时候为一个手机号码。
匹配，用户提交的数据是否与存储中的数据一致。
1.5术语：Spam与Anti-Spam
Spam指使用脚本、机器人进行恶意批量提交或遍历破解的行为。Anti-Spam指防止Spam的系统措施。
主键是数据库设计中的一个概念，为了保证唯一性，新增用户时必须进行主键查重。
2.1以用户名为主键注册
Anti-Spam：非常弱（批量Spam账户）。扩展性：高，随时可切换为以其他数据为主键。使用场景：私有内容/私有操作较少的情况，比如仅提供了回复、投票、点赞等轻操作，产品雏形期，进行测试的新产品（开发比较容易）。
注意事项：为了让用户找回密码，必须设置密保问题，找回密码代价很高（把自己用户名给忘记了）。
2.2以邮件地址为主键注册
2.3以手机为主键注册
Anti-Spam：弱（各种遍历、各种骚扰，需要采取措施）。
扩展性：低，几乎不可逆（用户也不答应）。
使用场景：带有支付功能的电商、消费类产品。实名用户系统，需要用户的绝对信任，初期转化率低，最好从邮件主键过度。只有移动版本的产品。
便利设计：根据手机号自动匹配地区城市、电信运营商（也有一部分用户是携号转网的#_#）。
注意事项：手机是绝对隐私，能不显示就不显示，显示必须掩码，如果包含社交功能，注册时可能需要采集昵称。国外手机号几乎不可以，短信通道需要至少双备，如果验证短信中包含一些根本想不到的敏感词，会很惨。用户更换手机，运营商回收旧号码卖给新用户，都会大量存在，请一定给出解决方案。
Anti-Spam：高（等于是把验证权交给别人了）。扩展性：高，可以在第三方验证后再创建自有账户。
使用场景：几乎适合各种类型的用户自主注册账户。
2.5社会卡证类主键（身份证、信用卡）注册
Anti-Spam：高，因为规律性比较差，但也不排除社会工程hack手段。扩展性：都到了这步了，算是个终极。。使用场景：特殊场合和人群，需要展示特殊的功能；实名用户系统，需要用户的绝对信任；必须关联在线支付/移动支付才能使用的产品；通常都不会包含社交功能。
便利设计：直接关联到用户真实身份和征信。
注意事项：通常验证都是通过第三方信用组织进行，比如提交信用卡关联的身份信息，由支付机构或银行匹配之后发送一个验证短信/邮件/二维码。同样是把鸡蛋放在别人的篮子里（通常是亲爹的篮子）。
2.6其他主键
用汽车牌照做主键，真的可以有，不是不可以，但是尽量还是别摸着石头过河。注册主键在真实社会里一定是具有非重复且个人专有的特点。
2.7多主键复合注册
2.8切换主键时注意事项
其切换主键之前，一定要对数据进行筛查，情况可能是这样的，用户使用邮件主键生成了一个用户，当系统切换手机为主键时，用户会因迷惑而创建另外一个新账户，此时可能涉及到用户数据合并的问题。如果这些没有想清楚，就不要随便更换主键。
3.1查重错误，不要在注册环节随便给出
填写一个手机号码，异步查询是否可以注册，虽给用户带来了方便，但也给骇客提供了可乘之机：写一个脚本就能遍历出来哪些号段多少个号码注册过产品！请在验证码正确之后给出结果，或者单独跳转URL给出查重类错误。
3.2前端校验和后端校验都要进行
3.4分步注册，暂存数据，只有在用户提交密码那一刻，才创建正式数据
3.5有必要重复确认密码么？
没必要！设置这个的初衷无非是避免用户注册时输错密码，输错=忘记密码，就去找回密码咯。
3.6只采集必要数据，填写项目越少越好
在注册环节，标注必填是个爆弱的设计，如果是选填，就别让用户在注册环节提交。
3.7包含社交的产品一定要让设置头像成为必填
注册之后，需要很大的运营代价才会让用户上传头像，因此这一步骤最好是前置。
3.8昵称需要查重么？
需要！避免李逵和李鬼，尽量杜绝录入火星文和特殊字符（视情况额定）。
3.9让用户发送密码短信到特定号码进行手机注册，这很low
谁会用？有多少用户愿意自己付出短信成本？除非特别紧急的情况下。
3.10同意《用户使用协议》
让用户勾选阅读并遵守《用户使用协议》，不如把注册按钮改为“同意用户协议，提交注册”。
3.11邀请码注册要走单独流程
输入邀请码或点击邀请邮件中加密连接进行注册，可关联邀请者ID，需要的单独设计注册界面。
这不仅仅是个仪式感，而且是安全的需要，增加自动脚本Spam账户的难度。
3.14注册应该避免设计成lightbox（快速注册除外）
注册复杂程度不一，并且会经常迭代改善产品，因此校验代码和各种逻辑判断非常多，如果做成lightbox效果，可能会拖累很多界面的加载速度，也会让维护和测试变得麻烦。
4.1商家注册（申请）建立在个人账户基础上
先完成个人账户注册，再创建商家。在注册商家的同时，创建一个个人账户。以上两种方法都可以。因为商家账户的管理者通常是员工，如果该员工离职，企业会要求进行管理权转移，把商家挂在个人账户下面，灵活度最高。
4.2在注册之前分流角色，而不是注册过程中
企业商家用户通常按行业分类，比如卖方需要提供代理证明，而买方需要填写收货地址。此时最好设置为两个入口，而不要在注册的过程中进行条件分支。
4.3审核期过度界面
4.4企业子账户应该是邀请的，而不是随便填写的
不要让企业商户管理员直接填写子账户的用户名和密码，建议企业子账户以email为主键，走邀请的流程，让其他员工自己验证邮件、填写验证手机和密码，这样做责权清晰，安全性最高。
4.5企业管理员不能直接修改子账户密码
企业管理员触发一个验证邮件给子账户，子账户可以自行通过加密连接修改密码。必要时，管理员可以冻结那个强制要求修改密码的子账户的权限。
在主键input当中，允许用户填写不同的主键，虽然校验比较麻烦，但是用户便利了。
单独抛出“该用户不存在”或者“密码不正确”可能会是不科学的，因为很可能方便了别有用心的人，比较安全做法是“用户名不存在或密码不匹配”。
5.3记住用户和记住密码是两种不同的功能
一种是保存“主键”，另外一种是保存“主键+口令”。记住用户名，就一定要有切换用户的功能。保存口令，要看产品的使用频率，使用频率越高保存周期越短（在便利和安全之间的平衡），保存周期最好不要超过3个月（甚至可以设置3个月强制更换密码）
6.1密码的安全
除了足够的位数要求、大小写和特殊字符要求，可以通过判断要求用户不允许把密码修改为曾经用过的密码（开发量略大），不能使用常见密码、纯数字密码、生日密码等。指纹、虹膜、手势……密码的种类会越来越多的。
6.2按问题找回密码，或创造问题找回密码
6.4按照手机找回密码
手机发送要防遍历Spam，手机验证码有效期越短越好，10~20分钟就可以。要提供“这个手机号码已不再使用”的解决方案，仅以手机为主键，且手机丢失、号码不再使用的情况，要求进行验证，比如“下面多用户哪些是你曾经的联系人”、“请输入你曾经用过的密码”“下面哪些宝贝你曾经购买过”等等，然后再进行解绑和重新绑定。必要时加入身份证信息上传功能。实在不行了，再转人工服务；手机丢了怎么办？手机不是有屏保密码么？不设屏保密码，那责任在谁？
依然是一个安全问题，也是给Spam脚本增加难度。
6.6找回密码/修改密码与提醒
用手机找回密码，就不要发手机提醒了，发个邮件是可以的。用邮件找回密码，不需要特殊的提醒。只用问题就找回密码，发个邮件比较好。
6.7人工密码服务
7.1要控制邮件发送的频率
7.2手机短信这个坑啊
7.3验证码何时出现
Anti-Spam的验证码降低了用户感受，因此，推荐在初次使用时不出现验证码，在1~3次错误之后，出现验证码。尽量让验证码新奇好玩一些，减轻用户反感。
8.1需要专职的产品人员和运营人员负责Passport？
8.2注册转化率那点事儿
要看追求何种目标，如果是以注册量为KPI，注册过程越简单越好，在注册之前尽量给与更多的利益展示。
8.3注册统计
通过促销活动注册的用户，要单独进行渠道统计，虽然理论上这些几乎都不会成为持久的DAU，但总是需要知道各种渠道的效果对比。
8.4与运营团队配合解决问题
为1%的用户创建100%的功能，得不偿失，但产品经理总是要给出一些答案。