http请求首先到达wsgi服务器，解析封装为request对象， 交给web框架处理
在框架中，中间件对请求进行进一步处理(例如：csrf、session (赛神)、路由匹配)
然后进行路由匹配， 执行不同的视图函数，可能涉及到数据库操作，模版渲染等
最后将结果传递到中间件， 封装为response响应对象
最后wsgi服务器将响应对象转换为http报文，返回给浏览器
MVC模式
M(Model)：主要封装对数据库层的访问，进行增删改查操
V(View)：用于封装结果，生成页面展示的HTML内容
C(Controller)(肯戳拉)：用于接收请求，处理业务逻辑，返回结果
MVT模式
M(Model)：负责和数据库交互，进行数据处理
V(View)：接收Request，进行业务处理，返回Response
T(Template)(太姆泼累特)：负责模版页面数据渲染
PV和UV都是网站流量统计指标
PV(PageView (配置 v欧)：页面的浏览次数，用户每打开、刷新一次页面就记录一次，多次打开会累计，不去重
UV(Unique Visitor (优尼克,微贼特))：页面的用户访问量，一天内站点的访问人数，一个用户访
问多次也只记为1 ，一般通过Cookie (库k )即可维护
跨域是由于浏览器的同源策略限制的，浏览器不会承认未经确认的跨域数据
在后端设置CORS 头部解决跨域问题，也就是我们在Django
用的corsheaders 中间件，
它使用额外的HTTP 头来告诉浏览器，
让运行在一个域名上的应用被准许访问来自不同源服务器上的指定资源
Cookie是由服务器端生成，发送给浏览器，浏览器会将Cookie的key/value保存到某个目录下的文本文件内，下次请求同一网站时自动发送该Cookie给服务器
Cookie可以用来在某个WEB站点会话间持久的保持状态
Session是另一种记录客户状态的机制，基于Cookie实现，不同的是Cookie保存在客户端浏览器中，而Session保存在服务器上
客户端浏览器访问服务器的时候，服务器把客户端信息以某种形式记录在服务器上，这就是Session，客户端浏览器再次访问时只需要从该Session中查找该客户的状态就可以了
当服务器使用了负载均衡的时候，当多台服务器使用的都是同一套网站的代码，用户请求网站时，请求会被分发到不同的服务器上
这种情况下，用户第一次请求时，在A服务器生成了Sessionid，但在B服务器和C务器并没有生成Sessionid，此时就会导致用户的登录状态出现问题，各服务器之间不能保持一致
通过HttpResponseRedirect或是redirect实现
永久重定向：301
临时重定向：302
反向迁移其实说的就是当数据库已经建立好之后，我们希望可以在Django中利用ORM操作这些已有的表，那么可以通过ORM的反向迁移操作把已有的SQL表结构反向翻译成models里的模型类
Original: https://blog.csdn.net/mache123456/article/details/124482369
Author: mache123456
Title: DJANGO详情
原创文章受到原创版权保护。转载请注明出处：https://www.johngo689.com/733165/
转载文章受原作者版权保护。转载请注明原作者出处！