第一次布置Django作业的时候很多人的第一反应其实是懵的模模糊糊知道要做一个网站但项目一创建出来满屏的文件夹和文件根本不知道先碰哪个。更别提交作业前还要连数据库、配后台、处理文件下载听起来全是陌生名词。这篇文章我把一个典型的Django第一次作业从零到交付拆开讲覆盖环境搭建、项目结构、模型设计、MySQL接入、admin后台、模板渲染、文件下载这些完整链路所有步骤都是我实际跑过的版本。不管是正在赶作业的学生还是想从零开始跑通Django的初学者照着这个流程走一遍你交出去的就不是一堆半成品代码而是一个能真正打开浏览器操作的小系统。1. 第一次Django作业到底在练什么1.1 这个作业背后真正要考的能力Django的第一次作业表面上交的是一个网站本质上考的是对Web开发数据闭环的理解。我见过太多同学的作业页面做得很花哨但点开之后数据全是写死在HTML里的这种在老师那里一眼就会被看穿。Django这套框架的入门逻辑很简单用户通过浏览器发出请求请求经URL路由找到对应的视图函数视图函数和模型打交道去操作数据库把结果渲染到模板里再返回给用户。所以整个作业的核心就是打通这条链路浏览器 → URL → 视图 → 模型 → 数据库 → 模板 → 浏览器。第一次作业的考核重点不是你会不会写复杂的业务逻辑而是能不能用Django的方式把数据存进去、查出来、展示出来、删得掉这一套走通。很多没有经验的同学容易把精力放在研究前端特效上结果项目后端全是硬编码真让你在后台加一条数据前台页面却纹丝不动——这就说明框架的运转逻辑还没吃透。所以如果你正在做这个作业我建议先别急着美化界面第一步是确认项目能用一个标准的数据流跑通所有操作。另外一个很多人忽略的点是工程习惯。第一次作业里老师往往会看你的项目结构是否规范、应用是否合理拆分、配置是否放在该放的位置。这些习惯比你想象的更重要因为后续的每一次作业、每一个项目都是在这个骨架上长出来的。能在第一次就把项目结构理清楚的人后面学DRF、学部署都会顺很多。1.2 作业选题为什么是多媒体资源管理系统我这里拿一个非常典型的作业选题来讲多媒体资源管理系统。为什么这个题材是Django入门作业里的常客因为它天然覆盖了Web开发需要的大部分基础能力要有数据表存资源信息要有后台管理界面添加和修改数据要有前端页面展示资源列表还要有文件下载功能。这几个需求刚好对应Django的模型、admin、视图模板、文件响应四大块等于一次作业就把框架的核心模块全练了。很多同学拿到这种题目会想复杂上来就设计七八张表什么用户表、权限表、分类表、评论表全建一遍。第一次作业真的不建议这么干。你的目标是用最少的内容把技术链路跑通而不是做一个生产级的系统。通常一张资源表就够了字段包括资源标题、资源描述、文件、上传时间、下载次数顶多加一个资源分类。表设计得越简单你就能把越多的精力放到数据是怎么流转的这个核心问题上而不是陷在ORM关联关系里出不来。功能模块的划分也很重要。我第一次做这种作业的时候就把功能拆成四个后台管理用Django自带admin、前台列表展示写一个视图加模板、详情和下载再做两个视图、删除这步可以放后台也可以自己在前台做。这个拆法既符合Django的MTV模式又不会让代码体量失控对第一次作业来说是最稳妥的架构。接下来我就按这个思路把每一步落地操作都走一遍。2. 跑通第一个Django项目环境与项目的正确打开方式2.1 环境准备虚拟环境与Django版本选择我在批改作业的体验里最常见的第一道坎就是环境问题。有的同学直接就在全局Python环境里pip install django装是装上了但没过多久装别的包就把Django搞乱又或者系统里有多套Python版本命令一敲提示找不到模块。这里我强烈建议从第一次作业开始就养成用虚拟环境的习惯。Python自带的venv模块就够用不需要额外装virtualenv操作也很简单# 创建项目目录并进入 mkdir django_homework cd django_homework # 创建虚拟环境 python -m venv venv # 激活虚拟环境Windows venv\Scripts\activate # 激活虚拟环境macOS/Linux source venv/bin/activate激活之后命令行前面会多一个(venv)前缀这时候再装依赖就不会污染系统环境了。Django版本的选择也要说一下现在Django已经到5.x了但对第一次作业来说除非老师有明确要求否则我建议安装最新的稳定版就好因为教程和资料都最好找。用命令pip install django默认就会装最新稳定版。如果是在校做作业还要顺手装一个生成依赖清单的习惯pip freeze requirements.txt。这个文件能让别人按你的环境一键复现也是很多同学交作业时容易忘掉的一个小加分项。若干依赖都用离线包或镜像源安装那是我推荐大多数初学者都遇到的卡点。尤其是国内网络环境下直接在终端跑pip install经常会出现超时或者连接有问题的报错。最省心的办法是使用国内镜像源比如清华源或者阿里源加一个-i参数就行pip install django -i https://pypi.tuna.tsinghua.edu.cn/simple2.2 创建项目与应用startproject和startapp的边界Django里有两个概念必须要分清项目project和应用app。我用生活里的例子来解释项目就像一个公司负责整体配置、网址分发、全局设置应用则是公司里的各个部门每个部门负责一块具体的业务。第一次作业通常只需要一个应用就够但很多新手会把项目和应用的命令搞反或者在创建时没有进入目标目录导致多套嵌套的奇怪路径。正确操作是先在项目根目录下创建Django项目然后在项目里创建应用# 在虚拟环境激活状态下创建项目 django-admin startproject config . # 创建应用 python manage.py startapp resource注意第一条命令我用了config .这个点非常关键它表示把项目的配置文件生成在当前目录下而不是再套一层同名文件夹。如果你忘记了这个点后面所有命令的路径都会很别扭。第二条命令创建了一个名叫resource的应用这个应用负责多媒体资源相关的所有逻辑。跑完这两条命令你会在目录下看到manage.py、config/配置包和resource/应用包这就是最基础的Django骨架。创建完应用之后还有一件特别容易被忽略的事把应用注册到项目里。在config/settings.py中找到INSTALLED_APPS这个列表把resource加进去。这一步不做你后面定义的模型迁移时Django根本找不到。我第一次做作业时就因为这漏掉卡了半小时才发现是这里的问题。# config/settings.py INSTALLED_APPS [ django.contrib.admin, django.contrib.auth, django.contrib.contenttypes, django.contrib.sessions, django.contrib.messages, django.contrib.staticfiles, resource, # 这个是我们自己的应用 ]2.3 settings.py里最容易出错的几个配置settings.py是Django项目的总控制台第一次作业里大部分诡异的报错都跟这里配置不对有关。最容易踩坑的有三个地方语言与时区、静态文件、数据库。语言和时区如果不改Django后台和页面默认显示英文和UTC时间。对中文作业来说这一步一定要改# config/settings.py LANGUAGE_CODE zh-hans TIME_ZONE Asia/Shanghai USE_I18N True USE_TZ True注意这里USE_TZ设置为True时Django会按UTC存时间显示时再转换到设置的时区。第一次作业阶段保持USE_TZ True即可但如果你的时间逻辑特别简单、只想存本地时间也可以把它设为False但要清楚这会改变Django的时间处理方式。静态文件配置也很关键。第一次作业里你的CSS、JS和上传的媒体文件都必须有对应的URL前缀才能在前台正常加载。默认情况下STATIC_URL已经是配置好的但媒体文件需要自己加两个配置# config/settings.py STATIC_URL /static/ STATICFILES_DIRS [BASE_DIR / static] MEDIA_URL /media/ MEDIA_ROOT BASE_DIR / media同时处理媒体文件访问还需要在根URL配置里加一行否则图片和下载文件在浏览器里会报404# config/urls.py from django.conf import settings from django.conf.urls.static import static urlpatterns [ path(admin/, admin.site.urls), # 你的其他路由 ] if settings.DEBUG: urlpatterns static(settings.MEDIA_URL, document_rootsettings.MEDIA_ROOT)这套配置做完项目才算有了一个稳定的基础环境。我第一次跑作业时就是在这里省了事结果后面上传的图片全是裂的排查到晚上才发现是MEDIA配置没写全。3. 把数据库跑起来模型设计与MySQL接入3.1 模型设计一张表撑起整个作业Django里模型Model就是数据库表的映射你写的每一个类都会被自动转换成一张表这种机制叫ORM。对于第一次作业我建议只做一个模型字段也不要多核心需求满足就行。拿多媒体资源管理系统来说最精简的表长这样# resource/models.py from django.db import models class Resource(models.Model): title models.CharField(标题, max_length100) description models.TextField(描述, blankTrue) file models.FileField(文件, upload_toresources/) category models.CharField(分类, max_length50, blankTrue) download_count models.IntegerField(下载次数, default0) created_at models.DateTimeField(上传时间, auto_now_addTrue) class Meta: verbose_name 多媒体资源 verbose_name_plural 多媒体资源 ordering [-created_at] def __str__(self): return self.title这段代码里的每一个字段类型都有讲究。CharField适合标题这种短文本TextField适合描述这种长文本FileField处理文件上传并自动把文件存到MEDIA_ROOT下DateTimeField用auto_now_addTrue可以自动记录创建时间IntegerField做下载次数的计数。__str__方法决定了在admin后台里每条记录显示成什么文字这个一定要写不然后台列表里全是千篇一律的Resource object (1)。好多人第一次做作业会纠结表要不要加外键、要不要搞一对多。我的建议是真的不用。第一次作业的数据模型能用一张表解决就一张表解决。等你理解了外键的作用再在后面的项目里去扩展。把模型设计得过于复杂只会增加迁移和查询的难度还会影响你对整个流程的判断。3.2 mysqlclient安装的坑与替代方案作业要求通常会把默认的SQLite换成MySQL因为MySQL在真实项目里是主流。但是这一步对初学者来说往往是最劝退的尤其是Windows用户在pip install mysqlclient的时候经常直接编译失败报一堆红色错误。原因很简单mysqlclient需要本机的C编译器并且要和MySQL客户端库对得上Windows默认的环境根本没法满足。遇到这个问题的同学不用死磕有几个替代方案都很成熟。第一个方案是装PyMySQL然后在项目的__init__.py里做一次猴子补丁pip install pymysql# config/__init__.py import pymysql pymysql.install_as_MySQLdb()这样Django就可以继续用django.db.backends.mysql这个驱动去连MySQL底层实际是PyMySQL在干活。用这个方案SQLite迁移过来的代码基本不用改体验最平滑。我实测过Django 5.x配合新版PyMySQL是可以正常使用的。第二个方案是装mysql-connector-python这是MySQL官方提供的纯Python驱动但它和Django的适配需要把数据库引擎改成mysql.connector.django配置上稍稍绕一点。不管用哪种驱动数据库本身的准备工作不能省。在MySQL里要手动建好数据库Django不会帮你创建库它只负责建表。比如用命令行或者Navicat建一个django_homework库字符集选择utf8mb4CREATE DATABASE django_homework DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;然后在settings.py里配置连接信息DATABASES { default: { ENGINE: django.db.backends.mysql, NAME: django_homework, USER: root, PASSWORD: 你的密码, HOST: 127.0.0.1, PORT: 3306, } }配置好之后别急着跑迁移先执行python manage.py check确认项目配置没有语法问题。我第一次配MySQL时就是因为密码里带了符号没有做任何转义处理就直接写进配置结果Django反复报连接失败排查了很久才发现是配置里的特殊字符把连接串拆坏了。3.3 迁移与admin后台注册数据库配置完成模型也写好了接下来要把模型变成真实的数据库表。Django把这一步拆成两个命令先生成迁移脚本再执行迁移python manage.py makemigrations resource python manage.py migratemakemigrations会读取模型的变化在resource/migrations/目录下生成一个迁移文件migrate才是真正把表建到数据库里。很多人只跑migrate不跑makemigrations模型改了也没效果。顺序一定不能反。如果你想知道Django到底生成了哪些SQL可以执行python manage.py sqlmigrate resource 0001查看对理解ORM很有帮助。表结构建好之后接着建后台管理账号。第一次作业一定要给老师演示admin后台所以超级用户是必备的python manage.py createsuperuser按提示输入用户名、邮箱可空和密码就完成了。然后打开resource/admin.py把模型注册进去# resource/admin.py from django.contrib import admin from .models import Resource admin.site.register(Resource)到此为止启动开发服务器python manage.py runserver访问http://127.0.0.1:8000/admin/用刚才创建的超级用户登录你就能在后台看到多媒体资源的管理入口可以添加、编辑、删除记录了。这算是整个作业的第一个里程碑数据链路中最重要的一环——后台管理——已经打通了。到这一步你已经完成了作业30%的工作量。3.4 后台管理界面的基础美化思路关于热搜里经常出现的django admin界面美化第一次作业阶段不用搞得太复杂但有几个低成本、高回报的admin配置建议你加上。默认的admin列表就是一排记录的字符串既没有搜索框也没有分页老师用起来体验很差。在admin.py里做一点点定制观感立刻不一样# resource/admin.py from django.contrib import admin from .models import Resource admin.register(Resource) class ResourceAdmin(admin.ModelAdmin): list_display (title, category, download_count, created_at) search_fields (title, description) list_filter (category,) ordering (-created_at,)list_display控制列表页显示哪些列search_fields添加搜索框list_filter在右侧生成筛选器ordering控制默认排序。这几行配置写完后台就从原始粗糙的状态变成了一个像模像样的管理系统。我第一次做作业时没有配这些老师点评的时候特意提了一句后台交互做得比较粗糙从那以后我就记住了admin不只是用来增删改查的它也是你作业的展示面之一。要是还想再进一步可以安装第三方主题包django-simpleui安装后它会自动替换admin界面侧边栏、卡片、图标都现代化很多而且完全不影响原有功能。安装命令就一行注册app后刷新页面即可生效。但我建议第一次作业先把原生的admin配好再去考虑第三方主题因为你对默认界面的理解越深后面定制起来越有把握。主题美化是锦上添花核心功能才是作业的根本。4. 写业务逻辑视图、URL与模板4.1 URL路由与视图函数的对应关系数据库和后端管理已经通了接下来要做的是让普通用户不登录后台也能在浏览器里看到资源列表。这一步涉及Django的MTV三层协作URL路由负责分发请求视图函数负责获取数据和准备数据模板负责渲染展示。在config/urls.py里Django会自动生成admin的路由。要新增我们自己的页面有两种方式直接写在项目级urls里或者在应用里建一个urls文件再include进来。第一次作业规模不大但为了养成好习惯我建议用到include把resource应用的URL独立管理# config/urls.py from django.contrib import admin from django.urls import path, include urlpatterns [ path(admin/, admin.site.urls), path(, include(resource.urls)), ]然后在resource应用下新建urls.py# resource/urls.py from django.urls import path from . import views app_name resource urlpatterns [ path(, views.index, nameindex), path(download/int:pk/, views.download_file, namedownload), ]这里的int:pk表示URL里的动态参数int是转换器意思是这个位置只接受整数。用户在浏览器访问/download/3/时Django就会把pk3传给download_file这个视图函数。用name给路由命名也很重要模板里通过{% url resource:download item.pk %}来生成链接比硬编码URL科学得多——万一以后改了路径模板代码不用动。注意视图函数的第一个参数永远是request这个对象包含了用户请求的所有信息。视图函数结尾要么返回HttpResponse要么返回render后的页面。我第一次写的时候忘记导入模块或者函数名和模块名冲突导致启动时反复报错这都是在入门阶段很正常的踩坑经历其实每条报错信息里都写了原因认真读一下基本都能解决。4.2 模板渲染与静态资源处理视图负责把数据准备好模板负责把数据填进HTML里。Django的模板语法核心就两个{{ 变量 }}和{% 标签 %}。前者用来输出变量后者用来做控制逻辑比如for循环和if判断。在resource应用下创建templates/resource/目录然后写一个列表页模板!-- resource/templates/resource/index.html -- !DOCTYPE html html langzh-hans head meta charsetUTF-8 meta nameviewport contentwidthdevice-width, initial-scale1.0 title多媒体资源管理系统/title /head body h1多媒体资源列表/h1 table border1 cellpadding8 styleborder-collapse: collapse; tr th标题/th th分类/th th上传时间/th th下载次数/th th操作/th /tr {% for item in resource_list %} tr td{{ item.title }}/td td{{ item.category }}/td td{{ item.created_at|date:Y-m-d H:i }}/td td{{ item.download_count }}/td tda href{% url resource:download item.pk %}下载/a/td /tr {% empty %} trtd colspan5暂无资源请到后台添加。/td/tr {% endfor %} /table /body /html模板里的resource_list这个变量名是给定的它的名字取决于视图里传给模板的上下文键。每个item就是一条Resource记录item.title、item.category直接取字段值。|date:Y-m-d H:i是Django模板的过滤器把默认时间格式改成人类友好的格式。{% empty %}是for循环的配套标签数据为空时显示提示语这个小细节对作业来说很加分。静态文件方面如果你需要引入CSS或JS在static目录下放文件并在模板顶部用{% load static %}加载静态文件模块然后就可以用{% static css/style.css %}生成正确的URL。我见过很多同学把CSS直接写在HTML里当然可以但工程化一点的做法就是独立文件这样目录结构更清晰老师看了也顺手。4.3 ORM查询与删除对象的正确姿势视图函数是整个流程的中枢。列表页视图很简单就是把数据库里的所有资源取出来交给模板渲染# resource/views.py from django.shortcuts import render, get_object_or_404 from django.http import HttpResponse from .models import Resource def index(request): resource_list Resource.objects.all() return render(request, resource/index.html, {resource_list: resource_list})这里Resource.objects.all()就是Django ORM查询的入门语法。objects是模型管理器all()返回QuerySet也就是一组记录的集合。QuerySet是惰性的它不会马上查数据库而是在真正访问结果时才执行SQL。这个特性在做复杂查询时非常有用但第一次作业知道有这个概念就行。判断QuerySet为空可以用exists()比if queryset:更高效也算一个面试级别的细节。删除对象是热搜里被点到的一个操作也是作业里的常见需求。单条删除最标准的写法是def delete_resource(request, pk): item get_object_or_404(Resource, pkpk) item.delete() return redirect(resource:index)get_object_or_404是Django的快捷方式如果根据条件能找到记录就返回找不到就直接抛404。这比自己用try/except捕获DoesNotExist再处理要干净很多。delete()方法会真正从数据库里把这条记录删掉并且是一个原子操作执行后不会留下半条数据。但注意如果模型有关系要小心级联删除把其他关联数据一并删掉。第一次作业模型简单不太会踩到这个坑但思路要有。批量删除也是Django的原生能力QuerySet直接调用delete()比如Resource.objects.filter(categoryPPT).delete()就会把所有分类为PPT的资源一次性删掉。执行批量删除时要格外谨慎因为Django的delete()会遍历对象并触发信号数据量大时可能有点慢但日常作业场景完全无压力。还有个经常被问的细节delete()返回的是一个元组第一个值是删除的总条数第二个值是按模型分类的明细字典用item.delete()[0]就能拿到删除数量这在作业里做删除成功提示时很实用。5. 文件下载与StreamingHttpResponse5.1 StreamingHttpResponse和HttpResponse的区别多媒体资源管理系统里最核心的功能之一就是文件下载。很多同学第一次做到这里会用HttpResponse把文件内容整个读进内存再返回# 不推荐的写法 def download_file(request, pk): item get_object_or_404(Resource, pkpk) data item.file.read() response HttpResponse(data, content_typeapplication/octet-stream) response[Content-Disposition] fattachment; filename{item.file.name} return response这样写对小文件没毛病但一旦文件上到几百MB服务器的内存就会被瞬间吃满多个用户同时下载时基本等于自爆。原因是HttpResponse要求响应体必须一次性构造完成文件再大也得先读到内存里。而StreamingHttpResponse不一样它以流式方式输出响应Django会把内容分块发给浏览器不用一次性把所有数据装进内存。我第一次处理一个视频资源下载时就是用了HttpResponse导致后台疯狂占用内存后来换成流式响应就好了。StreamingHttpResponse的基本用法是传入一个迭代器Django会逐个迭代并发送内容。对文件下载来说我们通常配合FileWrapper使用。需要注意一点StreamingHttpResponse更适合大文件下载场景如果只是几KB的小文件用HttpResponse反而更简单、性能更好。第一次作业里如果文件不大两种写法都可以但理解了流式响应的原理后面无论做什么下载功能都不会再被内存问题卡住。5.2 content_type与content-disposition参数怎么传无论用哪种响应两个HTTP头是绕不开的Content-Type在views里对应content_type参数和Content-Disposition。Content-Type告诉浏览器这个响应体是什么类型的数据。文件下载一般用application/octet-stream这是一个通用的二进制流类型浏览器看到它通常不尝试预览而是直接触发下载。如果你想精确控制也可以用mimetypes模块根据扩展名推断比如PDF是application/pdf图片是image/jpeg这些映射可以用mimetypes.guess_type()自动完成import mimetypes content_type, _ mimetypes.guess_type(item.file.path) if content_type is None: content_type application/octet-streamContent-Disposition则决定了浏览器把响应当成内联展示还是附件下载。设置成attachment; filenamexxx.pdf浏览器就会以下载方式处理设置成inline浏览器会尝试直接在页面里展示。实现下载功能时写法如下# resource/views.py from django.http import StreamingHttpResponse from django.utils.encoding import escape_uri_path from wsgiref.util import FileWrapper def download_file(request, pk): item get_object_or_404(Resource, pkpk) file_path item.file.path response StreamingHttpResponse(FileWrapper(open(file_path, rb)), content_typeapplication/octet-stream) filename item.file.name.split(/)[-1] response[Content-Disposition] fattachment; filename*UTF-8{escape_uri_path(filename)} return response这里有个特别多新手踩的坑文件名如果含中文直接写filename中文.pdf在个别浏览器里会乱码甚至下载失败。推荐的做法是使用filename*UTF-8这种RFC 5987规范的写法配合escape_uri_path对文件名做URL编码。这样写虽然丑了一点但兼容性是最好的。增加下载次数这个统计逻辑也可以顺便做上每次下载时让计数加一item.download_count 1 item.save(update_fields[download_count])update_fields参数只更新指定的字段避免把整行数据都重新写一遍这也是一个值得养成的好习惯。6. 交作业前必须排查的5个高发问题6.1 学生作业里出现频率最高的坑这段时间我在帮同学排查代码的过程中遇到过不少问题。下面这个表格是我总结的第一次Django作业里出现频率最高的几个问题每一个都是我实际见到的真实案例不是凭空列出来的。症状常见原因解决办法No module named pymysql没安装PyMySQL或在错误环境里安装检查虚拟环境激活状态执行pip install pymysqlTable xxx doesnt exist忘记运行迁移或模型新增字段后没迁移先makemigrations再migrate确认迁移脚本已生成页面能开但图片/文件404MEDIA_URL和MEDIA_ROOT配置缺失或dev服务器没加载媒体路由在urls.py里引入static()并注册MEDIA路由admin后台找不到自己的模型应用没注册到INSTALLED_APPS或没在admin.py导入模型检查settings.py确认在admin.py执行admin.site.register(Resource)下载文件名中文乱码filename中文.pdf写法兼容性差改用filename*UTF-8并URL编码文件名数据库中文变成问号MySQL库表字符集不是utf8mb4建库时指定DEFAULT CHARACTER SET utf8mb4如果你遇到了表格里没提到的问题我还有一个很实用的排查思路把报错信息完整读一遍。Django的报错页其实已经做得非常友好会在Debug模式下直接显示出错文件、出错行数、出错上下文。很多同学一看到红色报错页就慌了直接把页面关了其实那是一个非常宝贵的信息源。我第一次接触Django时有超过一半的问题都是靠看报错页解决的。6.2 几个老师不细说但你一定要知道的细节交作业之前有几件事老师通常不会专门讲但会影响你的最终体验和评分。第一个是数据库的备份问题。作业提交以后老师要在他的电脑上跑你的项目。如果你用的是SQLite直接把项目拷过去就行如果是MySQL那你需要把数据库导出成SQL文件一并提交并提供详细的配置说明。我在settings.py里还会故意写清楚用户名、密码和数据库名并在README里附上建库语句方便老师快速还原环境。第二个容易忽略的细节是迁移文件也要跟着代码走。很多同学只把代码拷过去没有把migrations目录下的文件带上老师那边一跑migrate就提示找不到迁移记录。第一次作业阶段最好把整个项目目录完整复制过去不要自作主张删除任何文件。尤其是resource/migrations/这个目录非常重要。第三个细节是虚拟环境和依赖清单。交作业时建议附上一个requirements.txt就是在项目根目录执行pip freeze requirements.txt生成。老师拿到项目后创建一个新虚拟环境执行pip install -r requirements.txt就能一键安装所有依赖。这个习惯在真实团队协作中几乎是必备的第一次作业就养成受益很久。还要检查一下settings.py里DEBUG是不是保持True让老师能看到详细的报错页面方便他快速定位问题。当然如果你有能力把DEBUG改成False并处理静态文件那会是很大的加分项但第一次作业不着急容易踩坑。6.3 留言与经验一次作业沉淀下来的工具链最后分享一点工具层面的经验。做Django作业用的IDE我建议别用太精简的编辑器至少装一个能高亮Python和HTML的推荐VS Code配合Python扩展或者用PyCharm。PyCharm是专业IDE对Django项目的识别很到位而且自带数据库工具和终端第一次做作业用起来整体会很省心。VS Code则更轻量配置好之后写代码也很舒服。两者选一即可不用纠结太多。数据库客户端我推荐Navicat或者DBeaver用来可视化查看Django生成的表结构。我第一次做作业时就是靠Navicat确认migrate之后表是否真的建成功字段类型是否符合预期。这种双端确认的习惯帮我避免了很多由于误判造成的烦恼。说回作业本身。很多人觉得第一次Django作业只是完成任务但我个人觉得它更像一次与Web开发核心思维的正式见面。你会在里面第一次正式理解什么是请求与响应、什么是ORM、什么是模板渲染、什么是路由分发。这些概念往大了说就是后端开发的地基往小了说是后面学Django Rest Framework、做前后端分离项目的敲门砖。所以与其急着把代码写完交差不如多花点时间把每一条链路都走过一遍哪怕只是删掉一个对象、改一个字段类型、重新迁移一次都是非常珍贵的实感。你要是第一次作业刚好卡在某个报错上可以回看这篇里的排查思路大多数情况下问题都出在配置和迁移环节。代码这个东西写一遍和看一遍是完全不同的体验所以别怕报错把报错当成Django在帮你检查作业就好。这个系统后续还能扩展的地方也不少比如把列表改成带分页和搜索的前台页面、给后台增加富文本编辑器、把文件上传扩展成图片预览、用Django Rest Framework写成前后端分离的接口。我觉得做作业最好的路径是先跑通再优化最后扩展。第一次写完能跑起来你就已经赢了大多数同行者。
