可能你已经发现了，Django自带的User模型非常实用，以至于我们没有写用户管理相关的任何模型。
但是自带的User毕竟可用的字段较少。比方说非常重要的电话号码、头像等都没有。解决的方法有很多，你可以不使用User，自己从零写用户模型；也可以对User模型进行扩展。
博客网站的用户信息并不复杂，因此扩展User就足够了。
扩展User模型
扩展User模型又有不同的方法。在大多数情况下，使用模型一对一链接的方法是比较适合的。
编写userprofile/models.py如下：
每个Profile模型对应唯一的一个User模型，形成了对User的外接扩展，因此你可以在Profile添加任何想要的字段。这种方法的好处是不需要对User进行任何改动，从而拥有完全自定义的数据表。模型本身没有什么新的知识，比较神奇的是用到的信号机制。
Django包含一个“信号调度程序”，它可以在框架中的某些位置发生操作时，通知其他应用程序。简而言之，信号允许某些发送者通知一组接收器已经发生了某个动作。当许多代码可能对同一事件感兴趣时，信号就特别有用。
这里引入的post_save就是一个内置信号，它可以在模型调用save()方法后发出信号。
有了信号之后还需要定义接收器，告诉Django应该把信号发给谁。装饰器receiver就起到接收器的作用。每当User有更新时，就发送一个信号启动post_save相关的函数。
通过信号的传递，实现了每当User创建/更新时，Profile也会自动的创建/更新。
当然你也可以不使用信号来自动创建Profile表，而是采用手动方式实现。
为什么删除User表不需要信号？答案是两者的关系采用了models.CASCADE级联删除，已经带有关联删除的功能了。
avatar字段用来存放头像，暂且不管它，下一章讲解。
重建数据库
前面讲过，每次改动模型后都需要进行数据的迁移。由于avatar字段为图像字段，需要安装第三方库Pillow来支持：
(env) E:\django_project\my_blog> pip install Pillow
安装成功后，通过makemigrations、migrate迁移数据：
迁移好数据后，如果你试图登录用户，会得到报错。这是因为之前创建的User数据都没有对应的Profile模型，违背了现有的模型。一种解决办法就是干脆删除旧的数据，因此就需要用到Django的shell命令。
shell是Django提供的互动解释器，你可以在这个指令模式中试验代码是否能够正确执行，是相当方便的工具。
在虚拟环境中输入python manage.py shell就可以进入shell：
看到>>>表示成功进入shell。
输入下面两行指令就可以轻松删除User数据库：
注意因为前面写的article模型中，与User的外键也采用了models.CASCADE级联删除模式，因此随着User的删除，相关的文章也一并删除了。
输入exit()退出shell，输入指令python manage.py createsuperuser，重新创建管理员账户。
对新手来说，修改数据库经常会导致各种头疼的问题，比如说字段失效、新字段为null、赋值错误、外键链接出错等等，最终导致整个业务逻辑报错。因此我的建议是，在设计数据库时尽量考虑周全，避免频繁修改模型。
如果实在要修改，并且已经导致数据库混乱了，不妨删除掉/app/migrations/目录下最新的几个文件，清空相关数据库，重新迁移数据。
接下来编写MTV模式的剩余部分。
表单、视图和模板
有了扩展的Profile模型后，需要新建一个表单类去编辑它的内容：
然后在userprofile/views.py中写处理用户信息的视图函数：
业务逻辑与以前写的处理表单的视图非常相似（还记得吗），就不赘述了。
需要注意下面几个小地方：
user_id是外键自动生成的字段，用来表征两个数据表的关联。你可以在SQLiteStudio中查看它。
留意redirect()是如何携带参数传递的。
然后就是新建模板文件/templates/userprofile/edit.html：
留意模板中如何分别调用User、Profile对象的
行内文本通过value属性设置了初始值，而多行文本则直接设置{{ profile.bio }}
最后配置熟悉的userprofile/urls.py：
启动服务器，输入地址查看功能是否正常。注意旧的用户都删除了（id=1的用户已经没有了），这里的/<int:id>必须为新创建的用户的id。
页面虽然简陋，但是方法是类似的。可以在这个基础上，扩展为一个美观、详细的用户信息页面。
当然最好再给个人信息添加一个入口。修改/templates/header.html：
修改article视图
在前面新建article的章节中，由于没有用户管理的知识，存在一些问题：
new_article.author = User.objects.get(id=1)强行把作者指定为id=1的用户，这显然是不对的。
没有对用户的登录状态进行检查。
因此稍加修改def article_create()：
重启服务器，文章正确匹配到登录的用户，又可以愉快的写文章了。
实际上，删除文章article_delete()、更新文章article_update()都应该对用户身份进行检查。就请读者尝试修改吧。
配置admin
前面我们已经尝试过将article配置到admin后台，方法是非常简单的，直接在admin.py中写入admin.site.register(Profile)就可以了。但是这样写会导致User、Profile是两个分开的表，不方便不说，强迫症的你怎么能受得了。
我们希望能够在admin中将User、Profile合并为一张完整的表格。方法如下：
打开admin中的User表，发现Profile的数据已经堆叠在底部了：
