内建用户系统是Django自带的用户系统，也就是说，原先我们做的那些用户应用，其实可以完全不去创建表，而是用Django已经生成好的表去做相关的登录注册。
所谓内建用户系统，就是Django自己已经写好的一套用户系统，这个系统其实就是admin后台。我们知道，当我们登录admin后台时，有输入用户名和密码的框框，同时它的库里面也是有一个user表的。换言之，我们完全可以用这个user表来做我们用户系统的主表，而不必像之前的云笔记项目那样，自己去写一个用户表了。在实际开发中，有些团队为了图省事，就会直接用这个Django自带的用户表。
1、定义
2、基本字段
??
3、基本模型操作
（1）创建用户
?
（2）删除用户
注意：对于删除用户的操作，建议还是用伪删除
（3）校验密码
之前我们自己建立用户表，我们判断一个用户在登录时输入的用户名和密码是否正确，使用的方法是对比用户输入的用户名和密码的md5哈希值是否和数据库表中存储的用户名和密码哈希值一样来判断的。
而在Django自带的用户表中，它为我们提供了一个自动检验用户名和密码的方法
（4）修改密码
（5）登录状态保持
之前的云笔记项目，我们实现登录状态保持是通过保存session，如果存的时间长一些的话就用cookie，而Django的自建用户系统就比较直接了，是直接存session，但遗憾的是存储的时间不可控，即：session什么时候过期，登录状态就什么时候过期。
在登录之前，我们要用authenticate(vt. 证明...是真实的)先校验一下用户名和密码是否是对的
?
（6）登录状态校验
（7）登录状态取消
?
4、内建用户表之扩展字段
思考：如果内建用户表字段不够用怎么办？比如像添加“手机号”字段？
假设我们真的决定用内建用户表，那么这个表里的字段肯定是不够用的。比如现在已经是移动互联网时代，而内建用户表里却连手机号这个字段都没有。那么这个是人家的表，咱们该怎样给它扩展字段呢？比如我想添加一个手机号字段，这就显得很困难。而解决方案虽然有(下面两个方案)，但也不太容易。
方案1就相当于，如果我扩展一个手机号字段，那手机号字段就放在新表里，然后让新表的数据和旧表产生关联。这个过程其实成本还是挺高的，尤其是在views.py中获取扩展字段的数据的时候，可能想要的数据在另一个表里。
方案2刚开始成本会高一些，但之后使用会舒服一些。这个方案是让我们继承它内建一个的抽象User模型类。抽象User模型类的意思就是说，我们可以把它的所有字段都继承到一个新表里，并且可以选择不让旧表初始化，然后把我们的表告知Django，以后无论是admin后台还是面向外部的用户表，都用这个新表。
方案二具体如下：
?
?
?
?