这在逻辑上和法规上是不允许，简单做个短信验证码验证或者密码就行，只要有手机号就可以了。额外说一下，如果用户注销账号，按照合规性的要求，用户数据是要删除的。但是我估计大部分小公司都是不遵守的，所以在设计的时候就要考虑同一个手机号码二次注册的时候历史数据怎么处理的问题。

我谈一谈这背后的账号体系设计，不管是用哪一种方式进行的注册，都表示背后有一个真实的用户存在。那么对应到数据库就涉及到整个数据库的各类数据表是通过什么要素相互关联的问题了，这就不单单是一个手机号码的事情了。

首先当然是会有一个用户ID，这个ID一般是内部使用的，但是对于业务部门来说用用户ID是不合适的，大家的习惯是用邮箱账号、手机号或者身份证号来进行用户身份的说明，符合日常生活的习惯，用户ID最多就是在产品和技术进行流通。

举个例子，有个用户遇到问题，联系客服进行反馈，这个时候客服肯定是问用户手机号是多少，而不会问用户你的用户ID是多少，问了的话用户都不知道要如何回答。

所以在进行设计的时候，尽量用邮箱账号、手机号或者身份证号做为主key进行关联，关联用户的个人信息、行为信息、交易信息、发布信息等等。用其中一个就行，最好是手机号或者身份证号，如果没有历史遗留用户问题的话在前端就不要设计邮箱登录的方式，方便后续进行数据存储和管理。

这种情况其实就是把手机号/身份证号和用户画上等号，一般来说问题不大的。

如果在设计app端注册方式的时候允许用户使用三方账号登录，那么就涉及到一个问题，用什么做主key关联各种数据，由于三方账号只是用户的一个属性，所以这种情况下就只能使用用户ID进行关联，也就是说在查询的时候需要先根据三方账号查出用户ID，在根据用户ID查询用户数据，其实管理和使用的时候不是很方便。