刚开始用Django写后端的时候我一度搞不清楚一个地址是怎么被翻译成一段Python代码的。后来看得多了才明白这件事的答案就藏在两个文件里一个叫urls.py另一个叫views.py。Django的视图View和URLs路由URLconf表面上看只是配置一个映射实际上却是整个Web应用的请求分发中枢。请求从浏览器出发经过URLconf找到对应的视图函数视图再调模型、渲染模板最后把响应返回给浏览器——这条链路稍微有一环没理顺后面加功能、做权限、上实时推送就全部跟着遭殃。这篇文章打算把Django视图与URLs路由这件事一次讲透先拆设计思路再带你从头配置一个能跑的项目接着处理查询、删除、权限、Cookie/Token这些业务里绕不开的操作最后聊一聊WebSocket实时推送和企业级项目里视图与路由怎么组织。中间穿插的全是我自己实际踩过的坑和现在还在用的顺手做法。想系统搞懂Django请求链路的初学者可以直接照做写过一阵子但觉得项目越来越乱的人也能在这里找到重新梳理的思路。1. 视图与URLs路由的核心设计思路1.1 Django的MVT模型与请求处理流程首先得承认Django官方文档很少提MVC这个词它喜欢说自己用的是MVTModel、View、Template。如果你熟悉MVC可以把Django的View理解成Controller的角色Template则是MVC里的View。Model负责跟数据库打交道View里写业务逻辑Template只关心页面长什么样。URLconf在这个模型里扮演的是一个额外的分发层它不在MVT缩写里但恰恰是它把请求地址和视图函数绑到了一起。一个完整的请求流程大致是这样的浏览器发送HTTP请求 - Django根据ROOT_URLCONF配置找到项目的urls.py - 从上到下遍历urlpatterns列表拿请求路径和每个路由规则做匹配 - 匹配成功后调用对应的视图函数或者调用类视图的as_view()返回的函数 - 视图函数接收HttpRequest对象必要时通过ORM查询数据库、调用业务逻辑 - 返回HttpResponse可能是渲染过的HTML、JSON或者重定向 - 响应回到浏览器。理解这条链路对定位问题特别有帮助。比如你看到一个404问题往往不在视图函数里而在路由匹配这个环节如果你看到一个500才应该去检查视图函数、模型或者模板。很多新手一报错就钻进views.py里找原因结果问题根本不在那。1.2 为什么URLconf值得单独设计我曾经在一个项目里见过把所有路由写在业务函数里的做法——每个视图函数内部自己if判断路径。当时项目还能跑但加了十几个接口之后维护成本直接爆炸。Django把URLconf单独抽出来本质上是为了解耦URL是给外部使用者和前端团队看的接口契约视图函数是内部实现。只要URL不换视图函数怎么改名、怎么重构都没关系反过来只要视图函数逻辑不变URL调整也只需要改一处。用一个生活化点的比喻urls.py就像公司前台的总机台每个视图函数是分机总机台只有一张转接表外部来电只需要报分机号码至于分机后面坐的是谁、座位有没有变动和打电话的人无关。Django的name参数则像是分机号的备注名内部打电话时不用记住数字说一句找销售部反向解析reverse(sales)就能转接过去。所以我在项目里从来不硬编码URL字符串一律用命名路由加反向解析这样即使哪天把接口路径整体迁移到/api/v2/下业务代码几乎不用动。2. 从零配置第一个视图URLconf与视图函数实操2.1 创建项目与App的标准流程先建立一个干净的项目环境。假设你已经安装好了Django我这边实测4.2 LTS版本以下命令在3.2都通用打开终端# 创建项目把myproject换成你的项目名 django-admin startproject myproject cd myproject # 创建应用 python manage.py startapp blogstartproject会生成一个manage.py和同名配置包里面有settings.py、urls.py等核心文件。startapp则生成blog目录里面包含views.py、models.py、admin.py等应用骨架。这一步做完千万别急着写代码先打开settings.py把blog加进INSTALLED_APPS。很多人卡在创建了App但URL访问还是404十有八九是忘了这一步。然后在blog/models.py里定义一个最简模型比如文章from django.db import models class Article(models.Model): title models.CharField(max_length200) content models.TextField() created_at models.DateTimeField(auto_now_addTrue) def __str__(self): return self.title按顺序执行迁移命令数据库表就建好了python manage.py makemigrations blog python manage.py migrate2.2 路由匹配path()、re_path()与参数传递视图写好了关键是配路由。打开项目的urls.pyfrom django.contrib import admin from django.urls import path, include urlpatterns [ path(admin/, admin.site.urls), path(blog/, include(blog.urls)), ]这里用include把blog的URL配置交给blog/urls.py负责。在blog应用下新建一个urls.pyfrom django.urls import path from . import views urlpatterns [ path(, views.article_list, namearticle_list), path(article/int:pk/, views.article_detail, namearticle_detail), path(article/int:pk/delete/, views.article_delete, namearticle_delete), ]path()的第一个参数是路由字符串第二个参数是视图函数name给这条路由起个名字方便后面用reverse反向解析。尖括号里的 int:pk 叫路径转换器int表示这里只能匹配整数pk是传给视图的关键字参数名。Django内置的转换器有str、int、slug、uuid、path五种日常最常用的就是int和slug。如果你需要文章ID不能小于1这类限制也可以在视图里判断但更推荐写一个自定义转换器注册到系统里让路由匹配阶段就能把不合法的路径挡掉而不是等进视图再处理# converters.py class FourDigitYearConverter: regex [0-9]{4} def to_python(self, value): return int(value) def to_url(self, value): return %04d % value # urls.py 里注册 from django.urls import register_converter, path register_converter(FourDigitYearConverter, yyyy) urlpatterns [ path(articles/yyyy:year/, views.article_by_year, namearticle_by_year), ]顺序问题要特别留意。urlpatterns是按顺序从上到下匹配的一旦匹配成功就停止继续。所以在同一个urls.py里固定路径要写在带参数的路径前面尤其要避免出现 str:name /delete/这种把admin/delete/吞掉的情况。如果要更灵活的匹配可以用re_path()它允许你直接写正则表达式。但我个人建议能不用正则就不用path配转换器已经覆盖了95%的需求正则可读性差还容易把路径结构写复杂。2.3 视图函数里的请求与响应视图函数的核心是拿到HttpRequest对象干完活返回一个HttpResponse。我日常接触到的响应方式就四种返回JSON给接口调用方、渲染HTML模板、重定向到另一个地址、直接返回一个简单的文本状态。对应到视图函数可以这样写from django.shortcuts import render, redirect, get_object_or_404 from django.http import JsonResponse from .models import Article def article_list(request): articles Article.objects.all().order_by(-created_at) context {articles: articles} return render(request, blog/article_list.html, context) def article_detail(request, pk): article get_object_or_404(Article, pkpk) return render(request, blog/article_detail.html, {article: article}) def article_api_detail(request, pk): article get_object_or_404(Article, pkpk) return JsonResponse({title: article.title, content: article.content})request这个对象身上带的信息非常多request.method判断请求方法request.GET和request.POST取查询参数和表单数据request.META可以取HTTP头request.user在登录系统里代表当前用户。判断一个视图是不是安全的先看它有没有区分GET和POST如果写的是删除操作却允许从GET请求里执行那基本等于在页面上留了个后门。3. 视图层核心实战查询、删除、权限与Cookie/Token3.1 视图中的查询与删除对象实操执行查询和删除对象是我看后台日志时最常见的两个操作也是大多数新手第一次接触ORM的地方。Django里的查询操作基本就三板斧get取单个对象、filter取列表、exclude做排除。查询不存在的对象会抛Article.DoesNotExist所以我一般都用get_object_or_404代替裸get它会把没找到自动变成404 Not Found响应前端也省事。from django.shortcuts import redirect, get_object_or_404 from django.views.decorators.http import require_POST from django.contrib.auth.decorators import login_required from .models import Article login_required require_POST def article_delete(request, pk): article get_object_or_404(Article, pkpk) article.delete() return redirect(article_list)这里有两处细节值得说。第一删除必须限制为POST请求不能让人通过一个GET链接就把文章删掉。第二模板里的删除按钮要放在form表单里并且带{% csrf_token %}否则Django的CSRF中间件会直接拦下来。我在真实项目里还习惯在删除之前做一个二次确认通常前端弹一个确认框后端则判断request.POST.get(confirm)是否等于yes两层保护总比一层稳。提示delete()返回的是一个元组包含被删除对象的总数和每个具体类别删除的数量调试时可以打印一下方便确认级联删除的范围。另外删除对象不等于彻底删掉数据。如果文章下面关联了评论这种外键数据直接delete可能有级联删除风险。Django默认的on_deletemodels.CASCADE会把关联数据一起删掉如果你只是想软删除保留数据但不再展示更稳妥的做法是在模型里加一个is_deleted字段查询时默认过滤掉这些记录这样既保住了用户体验也给数据留了后悔药。3.2 FBV与CBV怎么选视图写法有两大流派函数视图FBVFunction-Based Views和类视图CBVClass-Based Views。FBV直观好懂适合逻辑简单、初学者和大部分小型工具类接口。CBV是Django提供的基于类的视图内置了ListView、DetailView、CreateView、UpdateView、DeleteView这些通用视图还允许你用Mixin组合复用权限和缓存逻辑。我实际用下来的看法是页面里要展示一个列表用ListView确实能省掉七八行样板代码from django.views.generic import ListView from .models import Article class ArticleListView(ListView): model Article template_name blog/article_list.html context_object_name articles paginate_by 10但CBV的魔法也很重方法名、属性名记错了报错信息往往很隐晦。所以我给团队定了个简单规矩超过两层继承的CBV一律拆Mixin函数逻辑超过80行就抽service模块不要让CBV变成一个大杂烩。FBV和CBV不是二选一同一个项目完全可以混着来接口简单用FBV页面列表和表单用CBV最后效果最舒服。3.3 创建视图时的权限不足与权限控制搜索创建视图权限不足我猜有人是在Django里做权限控制也有人是部署项目时遇到目录权限问题。先聊Django端的权限控制这几乎是每个后台系统都躲不过的。Django自带一套基于用户的权限系统配合装饰器和Mixin可以组合出很干净的权限控制from django.contrib.auth.decorators import login_required, permission_required login_required permission_required(blog.add_article, raise_exceptionTrue) def article_create(request): # 只有拥有博客添加文章权限的人能进来 passlogin_required负责是不是登录用户permission_required负责有没有操作权限raise_exceptionTrue会让没有权限的用户看到403页面而不是被重定向到登录页API场景下这点尤其有用。如果用CBV则对应LoginRequiredMixin和PermissionRequiredMixin写法上把Mixin放在继承列表的最左侧。至于部署时权限不足通常是运行Django的系统用户对项目目录、静态文件目录或SQLite数据库文件没有写权限造成的。我吃过一次亏用root跑了几个命令生成迁移文件之后切到普通用户发现manage.py直接报权限错误。解决办法是统一用一个低权限的系统账号运行Django把项目目录chown给这个账号SQLite数据库的父目录保证可写这比在视图层面折腾权限问题简单得多。3.4 在视图中设置Cookie与Token很多系统的登录态靠Cookie承载Django里操作Cookie很方便。视图返回HttpResponse后在返回前调用set_cookie即可from django.http import HttpResponse def set_theme(request): response HttpResponse(theme ok) response.set_cookie(theme, dark, max_age7 * 24 * 3600, httponlyTrue) return responsemax_age控制Cookie存活时间单位是秒httponlyTrue可以避免前端JavaScript读取Cookie对防XSS很有用。如果担心Cookie被篡改可以用set_signed_cookieDjango会用settings里的SECRET_KEY对值做签名读取的时候用get_signed_cookie篡改过的值会被直接丢弃。Token的做法则灵活一些。你可以自己生成一段随机Token存到服务端数据库或Redis下发后让前端每次请求放在Authorization请求头里后端通过中间件或装饰器校验也可以把Token塞进HttpOnly Cookie里让浏览器自动携带前端拿不到也改不了适合纯浏览器端的项目。两种方案没有绝对优劣关键看你的前端是网页、小程序还是原生App——App往往更适合Header方式网页则建议优先考虑HttpOnly Cookie。4. 进阶渲染优化、WebSocket实时推送与项目结构演进4.1 视图渲染与查询性能优化视图渲染最常见的写法就是render(request, 模板.html, context)Django会把context里的变量渲染到模板的{{ }}和{% %}语法中。模板做好了视图的响应格式就稳了问题转移到喂给模板的数据查得够不够快。很多新手把视图可以加快查询速度吗理解成在视图里写SQL是不是更快其实不对。Django查询速度的瓶颈主要在三处关联表查询的N1问题、不必要的全表扫描、重复计算。处理N1问题的标准答案是select_related用于外键这类单值关联和prefetch_related用于反向外键和多对多# 文章列表要展示每个作者的昵称 # 不优化的写法会对每条文章单独查一次作者造成N1 articles Article.objects.select_related(author).all()数据库视图能加快查询吗这个热词里提到的视图和Django里的视图是两码事。数据库确实有view语法某些场景下预聚合能省时间但优化查询更常见的操作还是加索引、用select_related、避免在Python循环里逐条查库。另一个物美价廉的优化是视图缓存一个接口实时性要求不高直接用Django的cache_page给整页加缓存from django.views.decorators.cache import cache_page cache_page(60 * 15) def article_list(request): # 这个视图的结果会被缓存15分钟 ...缓存的key默认按完整URL生成所以不同参数会缓存不同页面15分钟内的重复请求直接命中缓存数据库压力瞬间降下来。4.2 Django Channels实现后台数据实时推送到前端python django websocket实现后台有数据前端推送这类搜索基本指向同一个诉求后端数据库表发生变化前端页面想立刻看到最新数据而不是等用户手动刷新。HTTP是无状态的浏览器只能发请求拿响应想反推数据只能轮询或者WebSocket。轮询简单但浪费资源WebSocket是全双工长连接适合告警、工单状态、通知这类实时场景。Django官方把WebSocket的支持交给Channels这个项目它把Django从WSGI升级成ASGI。配置大概分三步。第一步安装并配置pip install channels channels-redis在settings.py里把channels加到INSTALLED_APPS最前面设置ASGI_APPLICATION myproject.asgi.application再配一层Redis做channel layer消息队列CHANNEL_LAYERS { default: { BACKEND: channels_redis.core.RedisChannelLayer, CONFIG: {hosts: [(127.0.0.1, 6379)]}, }, }第二步修改asgi.py让WebSocket请求走Channels的路由分发import os from django.core.asgi import get_asgi_application from channels.routing import ProtocolTypeRouter, URLRouter from channels.auth import AuthMiddlewareStack from blog.routing import websocket_urlpatterns os.environ.setdefault(DJANGO_SETTINGS_MODULE, myproject.settings) application ProtocolTypeRouter({ http: get_asgi_application(), websocket: AuthMiddlewareStack( URLRouter(websocket_urlpatterns) ), })第三步在应用下建routing.py和consumers.py定义WebSocket路由和消费者。一个最简单的消费者长这样# consumers.py import json from channels.generic.websocket import AsyncWebsocketConsumer class NotificationConsumer(AsyncWebsocketConsumer): async def connect(self): await self.channel_layer.group_add(notifications, self.channel_name) await self.accept() async def disconnect(self, close_code): await self.channel_layer.group_discard(notifications, self.channel_name) async def send_notification(self, event): await self.send(text_datajson.dumps(event[message]))# routing.py from django.urls import path from .consumers import NotificationConsumer websocket_urlpatterns [ path(ws/notifications/, NotificationConsumer.as_asgi()), ]最后在业务视图里往WebSocket组里发消息from asgiref.sync import async_to_sync from channels.layers import get_channel_layer def notify_after_create(article): channel_layer get_channel_layer() async_to_sync(channel_layer.group_send)( notifications, {type: send.notification, message: {title: article.title}}, )这样任何一段代码创建了Article前端WebSocket都能实时收到通知。这里我需要提醒一句Channels有同步和异步两套线程模型普通Django视图是同步的调channel_layer.group_send必须用async_to_sync包一层否则消息发不出去如果你用的是异步视图、async def写法则直接用await channel_layer.group_send(...)。这个坑我身边不下三个人踩过表现都是前端连上了但收不到消息翻半天日志最后发现是同步异步没分清。4.3 企业级项目中的视图与路由组织项目到了一定的规模单文件views.py会膨胀到几千行urls.py也变成一长串没人敢动的路由清单。我参与的几个企业级项目里普遍的做法是把views.py改造成一个包blog/ views/ __init__.py article_views.py author_views.py dashboard_views.pyinit.py里用from .article_views import *统一导出。路由则按模块拆include主urls.py只做汇总# 项目级 urls.py urlpatterns [ path(admin/, admin.site.urls), path(api/v1/, include(apps.blog.urls, namespaceblog)), path(api/v1/account/, include(apps.account.urls, namespaceaccount)), ]顺便提一句2024年开始社区流行的Django Unfold这类后台美化组件本质也是替换admin站点的模板和样式你的视图代码完全不用动装好配置一下settings就能让后台颜值上一个台阶。但路由和视图的组织方式才是决定一个后台项目能不能长期维护的关键这些外部工具救不了你的路由混乱。5. 常见问题与排查技巧实录5.1 路由匹配不上与匹配顺序问题明明路径写对了访问还是404排在视图问题榜首。排查思路可以按这个顺序走先在浏览器的开发工具里确认请求的完整路径包括末尾斜杠再看项目根urls.py和对应应用urls.py里是否有include最后确认urlpatterns的顺序。路由顺序这个坑我印象特别深。有一次我把 str:slug /写在about/前面部门介绍页面直接打到文章详情去了页面虽然能渲染但内容完全不对。后来我在项目里定了条铁规矩固定路径永远排在带参数路径的前面URL规则里不允许出现名字含糊的str转换器宁可多写两条固定路由也不把路由交给看起来能用的正则通吃。另外Django默认开启APPEND_SLASH你访问不带斜杠的路径它会自动重定向到带斜杠的版本。如果这个行为不是你想要的可以关掉它但代价是你得自己处理结尾斜杠否则开发环境好好的、测试环境全404。5.2 反向解析NoReverseMatch排查视图代码里用reverse(article_detail)或者模板里用{% url article_detail pkarticle.pk %}时最常见的报错就是NoReverseMatch。这个报错翻译过来是Django在所有的URLconf规则里找不到一条名字匹配的规则。排查只需要抓三个点路由name拼写是否正确、是否漏写namespace前缀、参数个数和关键字名是否和路由里的转换器对应。举个例子路由定义是path(article/ int:pk /, views.article_detail, namearticle_detail)你就必须在reverse里传pk漏了pk必然NoReverseMatch。想快速定位可以在manage.py shell里敲python manage.py shell from django.urls import reverse reverse(article_detail, kwargs{pk: 1})再不行把整个项目的路由表打出来看看——django-extensions里的manage.py show_urls很好用能列出所有URL规则和name一眼就能看出是哪个路由名字写错了。5.3 调试视图VSCode断点与内存视图视图函数报错需要定位时我一直推荐在VSCode里打断点不要光靠print。配置一个调试任务Django类型的launch.json大概长这样{ version: 0.2.0, configurations: [ { name: Django Debug, type: python, request: launch, program: ${workspaceFolder}/manage.py, args: [runserver, 127.0.0.1:8000], django: true } ] }然后在视图函数里点一下行号设断点跑起来访问对应URL代码就会停在断点处。左侧变量面板里可以直接展开request对象查看request.method、request.user、request.POST这些属性你还能在调试控制台里输入表达式比如Article.objects.filter(...)实时查看查询结果。所谓查看内存视图就是在这个面板里把列表、字典、QuerySet等数据结构展开来看不必再靠加print。视图层调试还有一个利器是Django Debug Toolbar装上之后开发者访问页面时右侧会浮出工具条SQL查询耗时、模板渲染时间、缓存命中情况一目了然。我一般先把Toolbar装上看完数据把慢查询标出来再回视图里优化ORM效率比在代码里瞎猜高很多。5.4 常见报错速查与避坑清单综合我自己的经验把视图和路由相关的常见报错整理成一个速查表方便你排查时直接对号入座。报错现象常见原因排查办法访问任何路径都404ROOT_URLCONF配置错、路径没被任何urlpatterns命中检查项目urls.py用show_urls输出路由表比对视图没执行、直接403CSRF校验失败、权限装饰器拦截确认POST表单带csrf_token检查权限装饰器顺序500错误但日志无堆栈ALLOWED_HOSTS里没有当前域名生产环境把域名加入ALLOWED_HOSTS开启日志记录reverse报NoReverseMatchname拼写错、namespace前缀缺失、参数没传全用reverse在shell里测试show_urls列路由表模板渲染变量为空context里的键名写错、模板变量名打错调试模式打断点查看context使用Django Debug Toolbar前端拿不到静态文件STATIC_URL和STATIC_ROOT配置不对collectstatic后检查static目录路径WebSocket连不上ASGI配置未更新、channel layer未连接Redis检查asgi.py、settings.py里ASGI_APPLICATION、Redis服务状态最后单独补一条创建视图权限不足的教训。不管你是想在数据库里创建视图还是想在自己电脑上创建Django视图文件先确认操作用户对目标目录有没有读写权。Unix系统可以直接ls -ld查看目录权限Windows则检查属性里的安全选项卡。权限问题看着是小事但一旦让Django跑在一个写不了日志的账号下线上排查会非常痛苦。我自己的习惯是写Django视图前先画一条思路URL怎么定、请求方法是什么、数据从哪来、响应是什么形态、要不要权限。看起来小题大做但实际项目里视图和路由有没有想清楚直接决定你后面连改查都会不会顺手。我踩过最多的坑不是框架不会用而是最开始图省事把URL写死、把权限写在视图最里面、懒得给路由命名等代码量上来之后才补这些债成本翻了十倍不止。所以你如果想长期维护一个Django项目我强烈建议从第一个页面开始就养成三个习惯路由全部命名并用反向解析、视图函数尽量瘦、权限用装饰器和Mixin统一挂在视图入口。这三个习惯成本极低但能让你后面每一个晚上都不用来回翻代码。
Django视图与URLs路由实战：从请求分发到WebSocket实时推送
刚开始用Django写后端的时候我一度搞不清楚一个地址是怎么被翻译成一段Python代码的。后来看得多了才明白这件事的答案就藏在两个文件里一个叫urls.py另一个叫views.py。Django的视图View和URLs路由URLconf表面上看只是配置一个映射实际上却是整个Web应用的请求分发中枢。请求从浏览器出发经过URLconf找到对应的视图函数视图再调模型、渲染模板最后把响应返回给浏览器——这条链路稍微有一环没理顺后面加功能、做权限、上实时推送就全部跟着遭殃。这篇文章打算把Django视图与URLs路由这件事一次讲透先拆设计思路再带你从头配置一个能跑的项目接着处理查询、删除、权限、Cookie/Token这些业务里绕不开的操作最后聊一聊WebSocket实时推送和企业级项目里视图与路由怎么组织。中间穿插的全是我自己实际踩过的坑和现在还在用的顺手做法。想系统搞懂Django请求链路的初学者可以直接照做写过一阵子但觉得项目越来越乱的人也能在这里找到重新梳理的思路。1. 视图与URLs路由的核心设计思路1.1 Django的MVT模型与请求处理流程首先得承认Django官方文档很少提MVC这个词它喜欢说自己用的是MVTModel、View、Template。如果你熟悉MVC可以把Django的View理解成Controller的角色Template则是MVC里的View。Model负责跟数据库打交道View里写业务逻辑Template只关心页面长什么样。URLconf在这个模型里扮演的是一个额外的分发层它不在MVT缩写里但恰恰是它把请求地址和视图函数绑到了一起。一个完整的请求流程大致是这样的浏览器发送HTTP请求 - Django根据ROOT_URLCONF配置找到项目的urls.py - 从上到下遍历urlpatterns列表拿请求路径和每个路由规则做匹配 - 匹配成功后调用对应的视图函数或者调用类视图的as_view()返回的函数 - 视图函数接收HttpRequest对象必要时通过ORM查询数据库、调用业务逻辑 - 返回HttpResponse可能是渲染过的HTML、JSON或者重定向 - 响应回到浏览器。理解这条链路对定位问题特别有帮助。比如你看到一个404问题往往不在视图函数里而在路由匹配这个环节如果你看到一个500才应该去检查视图函数、模型或者模板。很多新手一报错就钻进views.py里找原因结果问题根本不在那。1.2 为什么URLconf值得单独设计我曾经在一个项目里见过把所有路由写在业务函数里的做法——每个视图函数内部自己if判断路径。当时项目还能跑但加了十几个接口之后维护成本直接爆炸。Django把URLconf单独抽出来本质上是为了解耦URL是给外部使用者和前端团队看的接口契约视图函数是内部实现。只要URL不换视图函数怎么改名、怎么重构都没关系反过来只要视图函数逻辑不变URL调整也只需要改一处。用一个生活化点的比喻urls.py就像公司前台的总机台每个视图函数是分机总机台只有一张转接表外部来电只需要报分机号码至于分机后面坐的是谁、座位有没有变动和打电话的人无关。Django的name参数则像是分机号的备注名内部打电话时不用记住数字说一句找销售部反向解析reverse(sales)就能转接过去。所以我在项目里从来不硬编码URL字符串一律用命名路由加反向解析这样即使哪天把接口路径整体迁移到/api/v2/下业务代码几乎不用动。2. 从零配置第一个视图URLconf与视图函数实操2.1 创建项目与App的标准流程先建立一个干净的项目环境。假设你已经安装好了Django我这边实测4.2 LTS版本以下命令在3.2都通用打开终端# 创建项目把myproject换成你的项目名 django-admin startproject myproject cd myproject # 创建应用 python manage.py startapp blogstartproject会生成一个manage.py和同名配置包里面有settings.py、urls.py等核心文件。startapp则生成blog目录里面包含views.py、models.py、admin.py等应用骨架。这一步做完千万别急着写代码先打开settings.py把blog加进INSTALLED_APPS。很多人卡在创建了App但URL访问还是404十有八九是忘了这一步。然后在blog/models.py里定义一个最简模型比如文章from django.db import models class Article(models.Model): title models.CharField(max_length200) content models.TextField() created_at models.DateTimeField(auto_now_addTrue) def __str__(self): return self.title按顺序执行迁移命令数据库表就建好了python manage.py makemigrations blog python manage.py migrate2.2 路由匹配path()、re_path()与参数传递视图写好了关键是配路由。打开项目的urls.pyfrom django.contrib import admin from django.urls import path, include urlpatterns [ path(admin/, admin.site.urls), path(blog/, include(blog.urls)), ]这里用include把blog的URL配置交给blog/urls.py负责。在blog应用下新建一个urls.pyfrom django.urls import path from . import views urlpatterns [ path(, views.article_list, namearticle_list), path(article/int:pk/, views.article_detail, namearticle_detail), path(article/int:pk/delete/, views.article_delete, namearticle_delete), ]path()的第一个参数是路由字符串第二个参数是视图函数name给这条路由起个名字方便后面用reverse反向解析。尖括号里的 int:pk 叫路径转换器int表示这里只能匹配整数pk是传给视图的关键字参数名。Django内置的转换器有str、int、slug、uuid、path五种日常最常用的就是int和slug。如果你需要文章ID不能小于1这类限制也可以在视图里判断但更推荐写一个自定义转换器注册到系统里让路由匹配阶段就能把不合法的路径挡掉而不是等进视图再处理# converters.py class FourDigitYearConverter: regex [0-9]{4} def to_python(self, value): return int(value) def to_url(self, value): return %04d % value # urls.py 里注册 from django.urls import register_converter, path register_converter(FourDigitYearConverter, yyyy) urlpatterns [ path(articles/yyyy:year/, views.article_by_year, namearticle_by_year), ]顺序问题要特别留意。urlpatterns是按顺序从上到下匹配的一旦匹配成功就停止继续。所以在同一个urls.py里固定路径要写在带参数的路径前面尤其要避免出现 str:name /delete/这种把admin/delete/吞掉的情况。如果要更灵活的匹配可以用re_path()它允许你直接写正则表达式。但我个人建议能不用正则就不用path配转换器已经覆盖了95%的需求正则可读性差还容易把路径结构写复杂。2.3 视图函数里的请求与响应视图函数的核心是拿到HttpRequest对象干完活返回一个HttpResponse。我日常接触到的响应方式就四种返回JSON给接口调用方、渲染HTML模板、重定向到另一个地址、直接返回一个简单的文本状态。对应到视图函数可以这样写from django.shortcuts import render, redirect, get_object_or_404 from django.http import JsonResponse from .models import Article def article_list(request): articles Article.objects.all().order_by(-created_at) context {articles: articles} return render(request, blog/article_list.html, context) def article_detail(request, pk): article get_object_or_404(Article, pkpk) return render(request, blog/article_detail.html, {article: article}) def article_api_detail(request, pk): article get_object_or_404(Article, pkpk) return JsonResponse({title: article.title, content: article.content})request这个对象身上带的信息非常多request.method判断请求方法request.GET和request.POST取查询参数和表单数据request.META可以取HTTP头request.user在登录系统里代表当前用户。判断一个视图是不是安全的先看它有没有区分GET和POST如果写的是删除操作却允许从GET请求里执行那基本等于在页面上留了个后门。3. 视图层核心实战查询、删除、权限与Cookie/Token3.1 视图中的查询与删除对象实操执行查询和删除对象是我看后台日志时最常见的两个操作也是大多数新手第一次接触ORM的地方。Django里的查询操作基本就三板斧get取单个对象、filter取列表、exclude做排除。查询不存在的对象会抛Article.DoesNotExist所以我一般都用get_object_or_404代替裸get它会把没找到自动变成404 Not Found响应前端也省事。from django.shortcuts import redirect, get_object_or_404 from django.views.decorators.http import require_POST from django.contrib.auth.decorators import login_required from .models import Article login_required require_POST def article_delete(request, pk): article get_object_or_404(Article, pkpk) article.delete() return redirect(article_list)这里有两处细节值得说。第一删除必须限制为POST请求不能让人通过一个GET链接就把文章删掉。第二模板里的删除按钮要放在form表单里并且带{% csrf_token %}否则Django的CSRF中间件会直接拦下来。我在真实项目里还习惯在删除之前做一个二次确认通常前端弹一个确认框后端则判断request.POST.get(confirm)是否等于yes两层保护总比一层稳。提示delete()返回的是一个元组包含被删除对象的总数和每个具体类别删除的数量调试时可以打印一下方便确认级联删除的范围。另外删除对象不等于彻底删掉数据。如果文章下面关联了评论这种外键数据直接delete可能有级联删除风险。Django默认的on_deletemodels.CASCADE会把关联数据一起删掉如果你只是想软删除保留数据但不再展示更稳妥的做法是在模型里加一个is_deleted字段查询时默认过滤掉这些记录这样既保住了用户体验也给数据留了后悔药。3.2 FBV与CBV怎么选视图写法有两大流派函数视图FBVFunction-Based Views和类视图CBVClass-Based Views。FBV直观好懂适合逻辑简单、初学者和大部分小型工具类接口。CBV是Django提供的基于类的视图内置了ListView、DetailView、CreateView、UpdateView、DeleteView这些通用视图还允许你用Mixin组合复用权限和缓存逻辑。我实际用下来的看法是页面里要展示一个列表用ListView确实能省掉七八行样板代码from django.views.generic import ListView from .models import Article class ArticleListView(ListView): model Article template_name blog/article_list.html context_object_name articles paginate_by 10但CBV的魔法也很重方法名、属性名记错了报错信息往往很隐晦。所以我给团队定了个简单规矩超过两层继承的CBV一律拆Mixin函数逻辑超过80行就抽service模块不要让CBV变成一个大杂烩。FBV和CBV不是二选一同一个项目完全可以混着来接口简单用FBV页面列表和表单用CBV最后效果最舒服。3.3 创建视图时的权限不足与权限控制搜索创建视图权限不足我猜有人是在Django里做权限控制也有人是部署项目时遇到目录权限问题。先聊Django端的权限控制这几乎是每个后台系统都躲不过的。Django自带一套基于用户的权限系统配合装饰器和Mixin可以组合出很干净的权限控制from django.contrib.auth.decorators import login_required, permission_required login_required permission_required(blog.add_article, raise_exceptionTrue) def article_create(request): # 只有拥有博客添加文章权限的人能进来 passlogin_required负责是不是登录用户permission_required负责有没有操作权限raise_exceptionTrue会让没有权限的用户看到403页面而不是被重定向到登录页API场景下这点尤其有用。如果用CBV则对应LoginRequiredMixin和PermissionRequiredMixin写法上把Mixin放在继承列表的最左侧。至于部署时权限不足通常是运行Django的系统用户对项目目录、静态文件目录或SQLite数据库文件没有写权限造成的。我吃过一次亏用root跑了几个命令生成迁移文件之后切到普通用户发现manage.py直接报权限错误。解决办法是统一用一个低权限的系统账号运行Django把项目目录chown给这个账号SQLite数据库的父目录保证可写这比在视图层面折腾权限问题简单得多。3.4 在视图中设置Cookie与Token很多系统的登录态靠Cookie承载Django里操作Cookie很方便。视图返回HttpResponse后在返回前调用set_cookie即可from django.http import HttpResponse def set_theme(request): response HttpResponse(theme ok) response.set_cookie(theme, dark, max_age7 * 24 * 3600, httponlyTrue) return responsemax_age控制Cookie存活时间单位是秒httponlyTrue可以避免前端JavaScript读取Cookie对防XSS很有用。如果担心Cookie被篡改可以用set_signed_cookieDjango会用settings里的SECRET_KEY对值做签名读取的时候用get_signed_cookie篡改过的值会被直接丢弃。Token的做法则灵活一些。你可以自己生成一段随机Token存到服务端数据库或Redis下发后让前端每次请求放在Authorization请求头里后端通过中间件或装饰器校验也可以把Token塞进HttpOnly Cookie里让浏览器自动携带前端拿不到也改不了适合纯浏览器端的项目。两种方案没有绝对优劣关键看你的前端是网页、小程序还是原生App——App往往更适合Header方式网页则建议优先考虑HttpOnly Cookie。4. 进阶渲染优化、WebSocket实时推送与项目结构演进4.1 视图渲染与查询性能优化视图渲染最常见的写法就是render(request, 模板.html, context)Django会把context里的变量渲染到模板的{{ }}和{% %}语法中。模板做好了视图的响应格式就稳了问题转移到喂给模板的数据查得够不够快。很多新手把视图可以加快查询速度吗理解成在视图里写SQL是不是更快其实不对。Django查询速度的瓶颈主要在三处关联表查询的N1问题、不必要的全表扫描、重复计算。处理N1问题的标准答案是select_related用于外键这类单值关联和prefetch_related用于反向外键和多对多# 文章列表要展示每个作者的昵称 # 不优化的写法会对每条文章单独查一次作者造成N1 articles Article.objects.select_related(author).all()数据库视图能加快查询吗这个热词里提到的视图和Django里的视图是两码事。数据库确实有view语法某些场景下预聚合能省时间但优化查询更常见的操作还是加索引、用select_related、避免在Python循环里逐条查库。另一个物美价廉的优化是视图缓存一个接口实时性要求不高直接用Django的cache_page给整页加缓存from django.views.decorators.cache import cache_page cache_page(60 * 15) def article_list(request): # 这个视图的结果会被缓存15分钟 ...缓存的key默认按完整URL生成所以不同参数会缓存不同页面15分钟内的重复请求直接命中缓存数据库压力瞬间降下来。4.2 Django Channels实现后台数据实时推送到前端python django websocket实现后台有数据前端推送这类搜索基本指向同一个诉求后端数据库表发生变化前端页面想立刻看到最新数据而不是等用户手动刷新。HTTP是无状态的浏览器只能发请求拿响应想反推数据只能轮询或者WebSocket。轮询简单但浪费资源WebSocket是全双工长连接适合告警、工单状态、通知这类实时场景。Django官方把WebSocket的支持交给Channels这个项目它把Django从WSGI升级成ASGI。配置大概分三步。第一步安装并配置pip install channels channels-redis在settings.py里把channels加到INSTALLED_APPS最前面设置ASGI_APPLICATION myproject.asgi.application再配一层Redis做channel layer消息队列CHANNEL_LAYERS { default: { BACKEND: channels_redis.core.RedisChannelLayer, CONFIG: {hosts: [(127.0.0.1, 6379)]}, }, }第二步修改asgi.py让WebSocket请求走Channels的路由分发import os from django.core.asgi import get_asgi_application from channels.routing import ProtocolTypeRouter, URLRouter from channels.auth import AuthMiddlewareStack from blog.routing import websocket_urlpatterns os.environ.setdefault(DJANGO_SETTINGS_MODULE, myproject.settings) application ProtocolTypeRouter({ http: get_asgi_application(), websocket: AuthMiddlewareStack( URLRouter(websocket_urlpatterns) ), })第三步在应用下建routing.py和consumers.py定义WebSocket路由和消费者。一个最简单的消费者长这样# consumers.py import json from channels.generic.websocket import AsyncWebsocketConsumer class NotificationConsumer(AsyncWebsocketConsumer): async def connect(self): await self.channel_layer.group_add(notifications, self.channel_name) await self.accept() async def disconnect(self, close_code): await self.channel_layer.group_discard(notifications, self.channel_name) async def send_notification(self, event): await self.send(text_datajson.dumps(event[message]))# routing.py from django.urls import path from .consumers import NotificationConsumer websocket_urlpatterns [ path(ws/notifications/, NotificationConsumer.as_asgi()), ]最后在业务视图里往WebSocket组里发消息from asgiref.sync import async_to_sync from channels.layers import get_channel_layer def notify_after_create(article): channel_layer get_channel_layer() async_to_sync(channel_layer.group_send)( notifications, {type: send.notification, message: {title: article.title}}, )这样任何一段代码创建了Article前端WebSocket都能实时收到通知。这里我需要提醒一句Channels有同步和异步两套线程模型普通Django视图是同步的调channel_layer.group_send必须用async_to_sync包一层否则消息发不出去如果你用的是异步视图、async def写法则直接用await channel_layer.group_send(...)。这个坑我身边不下三个人踩过表现都是前端连上了但收不到消息翻半天日志最后发现是同步异步没分清。4.3 企业级项目中的视图与路由组织项目到了一定的规模单文件views.py会膨胀到几千行urls.py也变成一长串没人敢动的路由清单。我参与的几个企业级项目里普遍的做法是把views.py改造成一个包blog/ views/ __init__.py article_views.py author_views.py dashboard_views.pyinit.py里用from .article_views import *统一导出。路由则按模块拆include主urls.py只做汇总# 项目级 urls.py urlpatterns [ path(admin/, admin.site.urls), path(api/v1/, include(apps.blog.urls, namespaceblog)), path(api/v1/account/, include(apps.account.urls, namespaceaccount)), ]顺便提一句2024年开始社区流行的Django Unfold这类后台美化组件本质也是替换admin站点的模板和样式你的视图代码完全不用动装好配置一下settings就能让后台颜值上一个台阶。但路由和视图的组织方式才是决定一个后台项目能不能长期维护的关键这些外部工具救不了你的路由混乱。5. 常见问题与排查技巧实录5.1 路由匹配不上与匹配顺序问题明明路径写对了访问还是404排在视图问题榜首。排查思路可以按这个顺序走先在浏览器的开发工具里确认请求的完整路径包括末尾斜杠再看项目根urls.py和对应应用urls.py里是否有include最后确认urlpatterns的顺序。路由顺序这个坑我印象特别深。有一次我把 str:slug /写在about/前面部门介绍页面直接打到文章详情去了页面虽然能渲染但内容完全不对。后来我在项目里定了条铁规矩固定路径永远排在带参数路径的前面URL规则里不允许出现名字含糊的str转换器宁可多写两条固定路由也不把路由交给看起来能用的正则通吃。另外Django默认开启APPEND_SLASH你访问不带斜杠的路径它会自动重定向到带斜杠的版本。如果这个行为不是你想要的可以关掉它但代价是你得自己处理结尾斜杠否则开发环境好好的、测试环境全404。5.2 反向解析NoReverseMatch排查视图代码里用reverse(article_detail)或者模板里用{% url article_detail pkarticle.pk %}时最常见的报错就是NoReverseMatch。这个报错翻译过来是Django在所有的URLconf规则里找不到一条名字匹配的规则。排查只需要抓三个点路由name拼写是否正确、是否漏写namespace前缀、参数个数和关键字名是否和路由里的转换器对应。举个例子路由定义是path(article/ int:pk /, views.article_detail, namearticle_detail)你就必须在reverse里传pk漏了pk必然NoReverseMatch。想快速定位可以在manage.py shell里敲python manage.py shell from django.urls import reverse reverse(article_detail, kwargs{pk: 1})再不行把整个项目的路由表打出来看看——django-extensions里的manage.py show_urls很好用能列出所有URL规则和name一眼就能看出是哪个路由名字写错了。5.3 调试视图VSCode断点与内存视图视图函数报错需要定位时我一直推荐在VSCode里打断点不要光靠print。配置一个调试任务Django类型的launch.json大概长这样{ version: 0.2.0, configurations: [ { name: Django Debug, type: python, request: launch, program: ${workspaceFolder}/manage.py, args: [runserver, 127.0.0.1:8000], django: true } ] }然后在视图函数里点一下行号设断点跑起来访问对应URL代码就会停在断点处。左侧变量面板里可以直接展开request对象查看request.method、request.user、request.POST这些属性你还能在调试控制台里输入表达式比如Article.objects.filter(...)实时查看查询结果。所谓查看内存视图就是在这个面板里把列表、字典、QuerySet等数据结构展开来看不必再靠加print。视图层调试还有一个利器是Django Debug Toolbar装上之后开发者访问页面时右侧会浮出工具条SQL查询耗时、模板渲染时间、缓存命中情况一目了然。我一般先把Toolbar装上看完数据把慢查询标出来再回视图里优化ORM效率比在代码里瞎猜高很多。5.4 常见报错速查与避坑清单综合我自己的经验把视图和路由相关的常见报错整理成一个速查表方便你排查时直接对号入座。报错现象常见原因排查办法访问任何路径都404ROOT_URLCONF配置错、路径没被任何urlpatterns命中检查项目urls.py用show_urls输出路由表比对视图没执行、直接403CSRF校验失败、权限装饰器拦截确认POST表单带csrf_token检查权限装饰器顺序500错误但日志无堆栈ALLOWED_HOSTS里没有当前域名生产环境把域名加入ALLOWED_HOSTS开启日志记录reverse报NoReverseMatchname拼写错、namespace前缀缺失、参数没传全用reverse在shell里测试show_urls列路由表模板渲染变量为空context里的键名写错、模板变量名打错调试模式打断点查看context使用Django Debug Toolbar前端拿不到静态文件STATIC_URL和STATIC_ROOT配置不对collectstatic后检查static目录路径WebSocket连不上ASGI配置未更新、channel layer未连接Redis检查asgi.py、settings.py里ASGI_APPLICATION、Redis服务状态最后单独补一条创建视图权限不足的教训。不管你是想在数据库里创建视图还是想在自己电脑上创建Django视图文件先确认操作用户对目标目录有没有读写权。Unix系统可以直接ls -ld查看目录权限Windows则检查属性里的安全选项卡。权限问题看着是小事但一旦让Django跑在一个写不了日志的账号下线上排查会非常痛苦。我自己的习惯是写Django视图前先画一条思路URL怎么定、请求方法是什么、数据从哪来、响应是什么形态、要不要权限。看起来小题大做但实际项目里视图和路由有没有想清楚直接决定你后面连改查都会不会顺手。我踩过最多的坑不是框架不会用而是最开始图省事把URL写死、把权限写在视图最里面、懒得给路由命名等代码量上来之后才补这些债成本翻了十倍不止。所以你如果想长期维护一个Django项目我强烈建议从第一个页面开始就养成三个习惯路由全部命名并用反向解析、视图函数尽量瘦、权限用装饰器和Mixin统一挂在视图入口。这三个习惯成本极低但能让你后面每一个晚上都不用来回翻代码。
