Django核心原理是理解请求响应生命周期、ORM桥接机制、模板安全渲染及“约定优于配置”思想。请求经WSGI→路由匹配→中间件处理→视图执行→响应返回；ORM通过Model定义表结构、QuerySet惰性执行、select_related/prefetch_related优化查询；模板自动转义、继承与标签约束逻辑分离；实战中通过模型设计、Admin定制和权限装饰器串联六大模块。
Django核心原理不是背概念，而是理解它怎么把请求变成网页、把代码变成数据、把逻辑藏进约定里。这一讲重点不在堆功能，而在看清框架背后那几条主干：请求响应生命周期、ORM如何桥接Python和数据库、模板系统怎样安全地拼接HTML、以及Django如何靠“约定优于配置”大幅减少重复决策。
请求进来后，Django到底做了什么？
一个URL访问触发的不是单一线程，而是一条清晰流水线：
- WSGI服务器（如uWSGI）接收原始HTTP请求，转交给Django
- Django按red">ROOT_URLCONF找到主路由文件，逐条匹配urlpatterns，找到对应视图函数或类
- 视图执行前，中间件按顺序处理请求（如认证、CSRF检查）；执行后，再按逆序处理响应
- 视图返回HttpResponse或其子类（如JsonResponse、HttpRedirect），经中间件再次处理后发回浏览器
关键点：中间件是链式拦截器，不是装饰器；路由匹配是自上而下顺序执行，path('article/
ORM不是SQL翻译器，而是Python对象的数据代理
Django ORM的核心价值不是省写SQL，而是把数据库操作变成面向对象的自然表达：
立即学习“Python免费学习笔记（深入）”；
- Model类定义字段即定义表结构，迁移文件（migrations/）是版本化DDL脚本，不是临时生成的
- QuerySet是惰性对象——Article.objects.filter(published=True)不查库，只有切片、遍历、list()或len()才真正执行SQL
- select_related()解决一对多N+1问题（走JOIN），prefetch_related()解决多对多或反向外键（发额外SELECT）
- 原生SQL用extra()或raw()要谨慎，优先用annotate()+F()/Q()组合复杂查询
模板不是占位符拼接，而是带约束的HTML生成器
Django模板系统强制分离逻辑与展示，所有计算应在视图中完成，模板只做呈现：
- {{ variable }}自动HTML转义，防XSS；{{ variable|safe }}绕过转义需绝对可控
- {% for item in list %}这类标签不支持赋值、函数调用，但可嵌套、可使用with缓存复杂表达式
- 模板继承（{% extends "base.html" %}）靠{% block content %}{% endblock %}实现内容注入，父模板控制结构，子模板填充细节
- 静态文件由{% static %}标签管理，开发时通过django.contrib.staticfiles收集，上线需用Nginx等独立服务托管
实战案例：从零搭一个带权限的后台文章管理模块
不堆功能，聚焦三个关键落地细节：
- 模型设计：用AutoSlugField（来自django-autoslug）自动生成URL友好的slug，避免手动输入错误
- 后台集成：继承admin.ModelAdmin，用list_display控制列显示，list_filter加侧边筛选栏，search_fields启用全文搜索
- 权限控制：不用硬编码user.is_staff，而是用@permission_required('blog.change_article')或在ModelAdmin中重写has_change_permission()方法，对接Django内置权限系统
跑通这个小模块，就串起了路由、视图、模型、模板、后台、权限六大部分，原理自然浮现。
