企业官网建设流程全解析

每年到这个时间点，总能看到一批为毕业设计挠头的同学。Django＋校园网站这类题目几乎是计算机专业的高频选题，一方面是校园系统本身贴近学生生活、需求好理解；另一方面Django自带Admin后台、ORM、认证体系，用好了确实能在两个月内做出一套功能完整、能演示、能答辩的项目。这篇内容我不讲虚的，直接把"基于Django框架的多功能校园网站"从选题拆解到功能设计、数据库建模、核心代码编写、部署上线，整条链路梳理一遍，把我自己实际开发中踩过的坑和值得留意的细节都摊开讲。无论你是刚摸到Python门的新手，还是有一定基础但第一次做整站项目的老手，这篇内容都能帮你少走一段弯路，把毕业设计做成一个拿得出手的完整作品。

1. 项目的定位与整体设计思路

1.1 为什么选择Django做校园网站

做校园网站，技术选型通常有几种方案，Spring Boot、Django、Flask，甚至还有用PHP的。我个人在实际开发里的感受是：如果目标是快速做出功能完整、结构健壮、又方便扩展的系统，Django的性价比在同类框架里非常突出。

它最大的优势是"全家桶"式设计。你在第二周就需要用户登录注册、后台管理、数据库操作，Django的auth模块、contrib.admin、ORM在安装之后立刻能跑起来。对比Flask，Flask需要自己拼装一堆扩展，虽然灵活，但很多决定要做到后面才暴露问题；对比Spring Boot，Java体系的学习成本、环境配置成本都偏高，如果你本身不是Java方向，两周时间光是搞懂依赖注入和Spring Security就会消耗掉大量精力。校园网站需要的用户系统、权限控制、内容发布、数据交互，Django几乎都是开箱即用。

另一个容易被忽略的考虑点是Python生态对校园场景的契合度。比如很多学校要求做数据分析展示、词云、课程推荐等功能，用Python处理这类问题比Java要顺手得多。我在这个项目里接入了公告发布的富文本编辑器、活动报名、站内搜索，后续还加了简单的学生行为数据分析，全都在一个语言栈内完成，不用跨语言写一堆转换层。

1.2 多功能校园网站到底"多功能"在哪里

从题目上看是"多功能"，很多同学容易把功能堆得很散，每个模块都做一点点，最后答辩老师一问就露馅。我的建议是做一条主线上的多功功能，比如以"校园信息整合服务"为主线，延伸出用户中心、信息发布、互动交流、管理后台这几个板块，每个板块之间要有数据联系，而不是拼凑六个互不相干的小页面。

我当时把系统拆成了七个子模块，这里列出来做个参考：

• 用户系统：注册、登录、个人信息管理、头像上传、密码修改。
• 校园公告：公告发布、分类检索、详情查看、浏览量统计。
• 活动管理：活动发布、活动报名、报名人数实时统计、活动结束归档。
• 校园论坛（或留言墙）：发帖、回帖、点赞、个人帖子管理。
• 课程资料分享：文件上传、文件下载、资料分类、积分或者权限控制。
• 校园问答：简单的问题发布和回答采纳机制。
• 后台管理系统：基于Django Admin二次开发，也可以自己写一套管理页面。

你可以发现，这些功能都围绕"校园信息流通"这个核心需求展开，用户一次登录，所有模块通用，数据表之间通过外键或ManyToMany关联。这样的系统在答辩时逻辑清晰、画架构图也容易解释，同时开发量又在一个毕业生两个月的可控范围内。

1.3 整体框架的层级设计

确定功能之后就要想清楚代码目录怎么组织。一个常见的坏习惯是所有逻辑都往views.py里写，几百行一个文件，后面改一个功能像翻迷宫。我建议把系统按App拆分，Django本身就有app的概念，这是它管理模块最合理的方式。

我的目录结构大概是这样：

campus_website/ ├── manage.py ├── config/ # 项目配置（settings/urls/wsgi/asgi） ├── apps/ │ ├── users/ # 用户相关 │ ├── notices/ # 公告相关 │ ├── activities/ # 活动相关 │ ├── forum/ # 论坛相关 │ ├── resources/ # 资料分享相关 │ └── qa/ # 问答相关 ├── templates/ # 公共模板 ├── static/ # 静态资源 └── media/ # 用户上传文件

每个app内部再按models.py、views.py、urls.py、forms.py、admin.py分文件。这样写的好处是后期出问题时定位很快，比如论坛模块的"点赞数不更新"，直接进forum/views.py找对应视图，不用在全局文件里翻找几万行代码。

这里多说一句，config/settings.py里的INSTALLED_APPS一定要按功能组注册。Django的app划分不是随便建个文件夹，而是和数据库表、URL路由、模板目录强相关的。规划得好，你后面每加一个新功能就是"新建一个app＋注册＋写逻辑"的标准流程，开发速度会快很多。

2. 数据库建模与核心模块设计

2.1 从用户表开始的建模思路

Django自带的auth.User已经提供了用户名、密码、邮箱、权限组等字段，校园网站的场景一般不需要完全重写用户系统，最合理的做法是继承AbstractUser扩展一个UserProfile，把校园特有的信息放进去。

我当时的UserProfile设计是这个样子：

from django.contrib.auth.models import AbstractUser from django.db import models class User(AbstractUser): SEX_CHOICES = ( ('M', '男'), ('F', '女'), ('U', '保密'), ) student_id = models.CharField(max_length=20, unique=True, verbose_name="学号") real_name = models.CharField(max_length=30, verbose_name="真实姓名") phone = models.CharField(max_length=11, blank=True, verbose_name="手机号") avatar = models.ImageField(upload_to='avatars/%Y/%m/', default='avatars/default.png', verbose_name="头像") sex = models.CharField(max_length=1, choices=SEX_CHOICES, default='U', verbose_name="性别") major = models.CharField(max_length=50, blank=True, verbose_name="专业") grade = models.CharField(max_length=10, blank=True, verbose_name="年级") class Meta: verbose_name = "用户信息" verbose_name_plural = verbose_name def __str__(self): return f"{self.username}({self.student_id})"

设计时要注意两个点。第一，unique=True约束了学号不能重复，防止一个人注册多个账号；第二，upload_to里的%Y/%m/是动态生成年月目录，不然所有头像会堆在同一个文件夹里，文件多了之后就很难管理。实际运行中还需要在settings.py里配置好MEDIA_URL和MEDIA_ROOT，并且在主urls.py中用static()辅助路由处理媒体文件访问，很多新人只配了STATIC_URL就忘记配媒体目录，结果头像一直传不上去。

2.2 公告与活动模块的数据关联设计

公告模块比较简单，核心表就是公告本身外加一个分类表。但我建议一开始就把"浏览量统计"做进去，这样一个简单的字段就能让你的系统显得"有数据感"，答辩或者演示时也更有说服力。

活动模块是校园网站里比较显功能量的部分，我用了两张表来支撑：

class Activity(models.Model): title = models.CharField(max_length=100, verbose_name="活动标题") cover = models.ImageField(upload_to='activity/covers/', blank=True, verbose_name="活动封面") content = models.TextField(verbose_name="活动详情") location = models.CharField(max_length=100, verbose_name="活动地点") start_time = models.DateTimeField(verbose_name="开始时间") end_time = models.DateTimeField(verbose_name="结束时间") capacity = models.IntegerField(default=0, verbose_name="人数上限（0为不限）") publisher = models.ForeignKey('users.User', on_delete=models.CASCADE, verbose_name="发布人") created_at = models.DateTimeField(auto_now_add=True, verbose_name="发布时间") @property def current_count(self): return self.signups.filter(canceled=False).count() class ActivitySignup(models.Model): activity = models.ForeignKey(Activity, on_delete=models.CASCADE, related_name="signups", verbose_name="活动") user = models.ForeignKey('users.User', on_delete=models.CASCADE, verbose_name="报名用户") signup_time = models.DateTimeField(auto_now_add=True, verbose_name="报名时间") canceled = models.BooleanField(default=False, verbose_name="是否已取消")

这里有个容易踩坑的设计细节：为什么报名记录里要留一个canceled而不是直接删除记录？因为活动发布方需要看到"谁报名过、谁又取消了"，这属于活动管理里的统计数据。如果你直接delete()，数据就没了，后续想导出报名历史也没有依据。同样在Activity上我用了@property方法计算当前报名人数，而不是单独存一个冗余字段，这样可以避免并发场景下人数不同步的问题。当然如果你的系统要应对高并发抢课场景，那需要事务和锁，但毕业设计场景下这个写法已经完全够用。

另外注意related_name="signups"这个参数，很多人不写或者取一个不直观的名字。它决定了从Activity对象反查报名记录时用activity.signups还是activity.activitysignup_set，前者阅读代码时显然舒服得多，而且数据库查询时还能和prefetch_related配合减少SQL次数。

2.3 论坛、问答与好友关系的扩展设计

论坛是整个系统里最能体现"交互性"的部分。帖子表、评论表（回帖表）、点赞表是三个基本表。点赞我用了单独一张PostLike表来记录用户和帖子之间的多对多关系，并通过unique_together保证一个用户对同一帖子只能点赞一次。

如果你做校园社区，还想加"添加好友"功能，可以用Django的ManyToManyField自关联实现：

class User(User): friends = models.ManyToManyField( 'self', symmetrical=True, blank=True, related_name='friend_set', verbose_name="好友" )

symmetrical=True表示好友关系是双向的，A是B的好友，B自动就是A的好友。这里有一个十分隐蔽的坑：related_name不能和默认的反向名称user_set冲突，我建议显式指定为friend_set，避免后续在模板里调用关系时出现歧义。此外如果以后想做好友申请、同意/拒绝流程，就需要改成中间表模型，而不是直接用ManyToManyField，这个扩展点可以先在答辩PPT里埋个伏笔。

数据库建模是毕业设计的基础，我的体会是"先想清楚关系再写代码"。不要边写代码边改表，后面数据一多，migrate就没那么轻松了。最好在前期画清楚ER图，这就够用了。

3. 关键功能实现与常见坑位拆解

3.1 用户认证与会话安全

Django自带的认证系统可以省掉很多工作，但也别直接裸用，有几个地方需要自定义。第一个是登录视图，默认的LoginView虽然能用，但如果你想在登录成功后跳转到不同页面（比如管理员跳到后台、普通用户跳到首页），需要重写get_success_url或者传next参数。

第二个是注册的校验逻辑。校园网站的注册通常需要学号，你可以在forms.py里写一个UserRegisterForm，对学号格式进行校验，再检查是否已经存在：

from django import forms from .models import User class UserRegisterForm(forms.ModelForm): password = forms.CharField(widget=forms.PasswordInput, label="密码") confirm_password = forms.CharField(widget=forms.PasswordInput, label="确认密码") class Meta: model = User fields = ['username', 'student_id', 'real_name', 'password'] def clean_student_id(self): student_id = self.cleaned_data.get('student_id') if User.objects.filter(student_id=student_id).exists(): raise forms.ValidationError("该学号已注册") return student_id def clean(self): cleaned_data = super().clean() password = cleaned_data.get("password") confirm_password = cleaned_data.get("confirm_password") if password != confirm_password: raise forms.ValidationError("两次密码输入不一致")

这里提醒一个大多数人容易漏掉的问题：Django表单的clean_xxx方法是在字段级别校验后执行的，想要校验跨字段的逻辑，必须写在clean()里，也就是我处理两次密码一致性的地方。另外像这种"学号已注册"的校验绝对不能只写在前端JavaScript里，后端必须再校验一次，否则绕过前端直接发POST请求就能注册重复数据。我在真实项目里就见过这种情况，只做了前端校验，后期数据表里出现几十条重复学号的脏数据，非常难处理。

3.2 公告发布中的富文本编辑器接入

校园网站的公告和活动详情如果只是纯文本，页面会显得很丑。推荐接入富文本编辑器，我实际用的是wangEditor，也是搜热词里常见的组合。wangEditor是中国开发者做的开源项目，中文文档友好，集成到Django里不复杂。

步骤大致为：

1. 在模板里引入wangEditor的JS和CSS（可以本地化，也可以CDN）。
2. 在需要富文本编辑的页面上初始化编辑器，把textarea作为隐藏字段承载HTML内容。
3. 在Django的views.py中，对提交的HTML内容进行过滤和清洗，防止XSS攻击。
4. 展示时使用|safe过滤器输出。

接入富文本不难，难的是安全处理。如果不做任何清洗，用户在编辑器里塞一段<script>代码，提交后存进数据库，其他用户一打开公告页面就会执行这段脚本，这是经典的XSS漏洞。我的方案是用bleach库对HTML做白名单过滤，只允许p、b、strong、img、a等安全标签：

import bleach def clean_content(html): allowed_tags = ['p', 'br', 'strong', 'b', 'em', 'i', 'u', 'img', 'a', 'ul', 'ol', 'li', 'h2', 'h3', 'blockquote'] allowed_attrs = { 'a': ['href', 'title', 'target'], 'img': ['src', 'alt', 'width', 'height'], } return bleach.clean(html, tags=allowed_tags, attributes=allowed_attrs, strip=True)

答辩老师常常会问"你怎么保证网站安全"，你能说出这个清洗逻辑，得分就会明显好过只会说"我加了登录功能"的同学。

3.3 ORM查询优化与删除对象时的教训

很多同学写Django ORM，数据量小的时候感觉不到问题，到了论坛帖子列表页，越写越卡，原因往往是N+1查询。比如页面上要显示每一篇帖子的作者名、评论数、点赞数，如果循环遍历查询，列表有50条帖子就会多出几十次数据库查询。解决办法是：

posts = Post.objects.select_related('author').prefetch_related('comments', 'likes')

select_related用于外键关系，prefetch_related用于反向关系和ManyToMany关系。这两个方法我的理解是：前者是SQL的JOIN，一次性把关联表的数据取出来；后者是先查主表再查关联表，然后在Python内存里做关联。两者都用上之后，论坛列表页的数据库查询次数能少一个数量级。我在实际开发里专门用Django Debug Toolbar观察过这个查询次数，优化前是80多次，优化后是3次，页面的响应时间肉眼可见地变快。

关于删除对象，热词里面出现了"django执行查询-删除对象"，这确实是个高频场景。删除看起来简单：Object.objects.filter(id=1).delete()，但里面有几个需要警惕的地方。第一，删除有外键关联的对象时，on_delete参数决定了子表数据会跟着删除（CASCADE）、设置为空（SET_NULL）还是保护级报错（PROTECT）。我建议根据业务谨慎选择，比如删除一个活动时，报名记录要不要一并清除？如果你需要留存数据分析，就不要用CASCADE，而是给活动加一个is_active字段做软删除。

软删除的写法很简单：

class Activity(models.Model): is_active = models.BooleanField(default=True, verbose_name="是否有效") def delete(self, using=None, keep_parents=False): self.is_active = False self.save()

重写delete()方法后，所有调用activity.delete()的地方都不会真正删除数据，而只是把标记位置为False。查询时默认过滤掉：

Activity.objects.filter(is_active=True)

这个方案对毕业设计来说足够优雅，答辩的时候还能顺势讲出"逻辑删除与物理删除的区别"，属于典型加分项。

3.4 URL反向解析与路由组织

热词里有"django reverse resolve"关键词，这其实是Django一个特别核心却又经常被忽视的机制。简单说，URL反向解析就是通过视图函数的名字来获取对应的URL路径，而不是硬编码URL。比如：

from django.urls import reverse # 在视图或模板中 url = reverse('activities:detail', args=[activity.id])

模板里对应写成{% url 'activities:detail' activity.id %}。我在项目里给每个app的URL都加了命名空间，比如activities、notices、forum。一旦URL路径变了，只要name不变，全站链接依然有效。这个习惯在我后来重构系统时帮了大忙，前端模板里几乎没有硬编码的/activity/12/这种路径，全部通过url反向生成。

面试题里经常出现的resolve则用于反向解析，比如在中间件里根据请求URL找到对应的视图函数名，可以用来做权限记录。这个功能在我后面做操作日志时用到了，算是实用场景。

3.5 文件上传、图片处理的细节

校园网站里难免有上传文件、图片的需求，比如课程资料、用户头像、活动封面。除了前面说的配置好MEDIA_URL和MEDIA_ROOT，还需要注意三个方面。

第一个是文件类型校验。Django表单里可以用FileExtensionValidator，但更好的做法是校验MIME类型，因为攻击者可以改后缀名绕过。我在课程资料分享模块里写了这样一个校验方法：

def validate_file_type(upload): allowed_types = ['application/pdf', 'application/msword', 'application/vnd.openxmlformats-officedocument.wordprocessingml.document'] if upload.content_type not in allowed_types: raise forms.ValidationError("不支持的文件类型")

第二个是图片尺寸控制。头像如果原图直接存储，用户传一张5MB的图片，整个页面加载会非常慢。我用Pillow配合ImageField在保存时做压缩处理，具体可以在models.py里重写save()方法：

from PIL import Image from io import BytesIO from django.core.files.base import ContentFile def save(self, *args, **kwargs): if self.avatar and hasattr(self.avatar, 'path'): try: img = Image.open(self.avatar.path) if img.height > 300 or img.width > 300: img.thumbnail((300, 300)) output = BytesIO() img.save(output, format='JPEG', quality=85) self.avatar = ContentFile(output.getvalue(), name=self.avatar.name) except Exception: pass super().save(*args, **kwargs)

第三个是下载时的文件名处理。Django的FileResponse默认会用存储的文件名，但如果你希望用户下载时看到的文件名是"高等数学课件.pdf"，需要显式设置Content-Disposition头。这个细节很多教程不会讲，但实际操作中老师测试下载功能时经常会点击中文文件名的文件，处理不好就会出现乱码。

3.6 分页、搜索与页面控件的实现

校园网站的信息量会逐渐增长，公告几十条之后不做分页就会显得很没章法。Django有现成的Paginator类，我在项目里封装了一个简单的分页组件，放在utils.py里：

from django.core.paginator import Paginator, PageNotAnInteger, EmptyPage def paginate(request, queryset, per_page=10): paginator = Paginator(queryset, per_page) page = request.GET.get('page', 1) try: objects = paginator.page(page) except PageNotAnInteger: objects = paginator.page(1) except EmptyPage: objects = paginator.page(paginator.num_pages) return objects

配合模板里的上一页/下一页按钮，以及页码列表，这个功能就能在多个模块复用了。搜索的话也尽量抽象成通用方法，Django的Q对象可以做多字段模糊搜索，比如：

from django.db.models import Q keyword = request.GET.get('keyword', '') if keyword: notices = notices.filter(Q(title__icontains=keyword) | Q(content__icontains=keyword))

注意icontains是不区分大小写的模糊匹配，如果字段是中文内容则和contains没有区别，但对英文检索更友好。如果你想把搜索范围扩大，加一个全文搜索的SearchVector也不是不行，但毕业设计用Q对象已经够了，别把简单的事情搞复杂。

4. 后台管理、前端页面与系统部署

4.1 用Django Admin还是自己写后台

Django自带的Admin后台功能很强，注册好模型之后，增删改查基本零成本。如果你对代码能力有一定自信，或者想做出更有个人风格的后台页面，也可以从Admin扩展到完全自定义的管理界面。

我的建议是：先用Admin做数据管理，同时再单独写一个控制台首页，展示系统统计数据（用户总数、公告数、活动报名数、最新注册用户等），这部分可以用图表库，比如ECharts，展示为一目了然的卡片和图表。答辩的时候展示这个"数据分析面板"，会比一上来就打开Django Admin默认界面有冲击力得多。

在Admin里注册模型时，也可以做很多定制：

from django.contrib import admin from .models import Activity, ActivitySignup @admin.register(Activity) class ActivityAdmin(admin.ModelAdmin): list_display = ('title', 'location', 'start_time', 'publisher', 'created_at') list_filter = ('start_time',) search_fields = ('title', 'content') date_hierarchy = 'created_at' list_per_page = 20

设置list_display之后，后台列表页能直接看到关键列，不用点进详情。对于活动报名记录，还可以让管理端的草稿、公告等模型都注册到Admin里，方便调试数据。

4.2 前端页面的快速构建方式

很多同学不是前端专业出身，硬写CSS会非常痛苦。我的经验是用Bootstrap或者LayUI这类现成UI框架。Bootstrap生态最全，文档丰富，网上模板也多；LayUI是国产框架，界面风格更贴近一些教育系统的传统审美，而且它自带很多后台管理模板，非常适合做校园网站这种偏内网风格的系统。

我前端布局是：首页放学校简介轮播图、最新公告、热门活动、最新帖子四个区域；每个功能模块用卡片列表呈现；详情页采用"左侧正文＋右侧相关信息"的经典两栏布局；后台管理用LayUI的admin模板。这样做两到三周就能把所有页面的成型版本做出来，省下来的时间全部投入功能逻辑和Bug修复，比从零手写样式高效得多。

响应式布局值得注意。现在很多评委老师会直接用手机打开网站演示，如果页面在手机上错位严重，印象分会受影响。Bootstrap的栅格系统天然支持响应式，LayUI的栅格也同理。做移动端适配时至少保证：导航栏折叠成汉堡菜单、图片自适应宽度、表格在窄屏下可以横向滚动。

4.3 项目部署：从本机到服务器

部署是毕业设计里另一个常见难点。热词里出现了"宝塔部署django"、"麒麟"等关键词，说明不少同学都选择用宝塔面板把自己写的网站放到云服务器上跑。

我的部署链路是这样的：

# 1. 在服务器上创建虚拟环境 python3 -m venv venv source venv/bin/activate # 2. 安装依赖 pip install django gunicorn mysqlclient # 或者 pymysql pip install -r requirements.txt # 3. 收集静态文件 python manage.py collectstatic # 4. 启动迁移 python manage.py migrate

数据库我建议用MySQL而不是SQLite，虽然SQLite零配置很方便，但服务器部署、并发读写、面试时被问"为什么不用MySQL"都比较被动。安装MySQL后，Django连接MySQL还需要在settings.py里配置好DATABASES，如果用pymysql，别忘在__init__.py里加：

import pymysql pymysql.install_as_MySQLdb()

在服务器上跑开发服务器runserver是绝对不能用于生产环境的，需要有一个WSGI服务器。我用的是Gunicorn，配置很简单：

gunicorn config.wsgi:application --bind 0.0.0.0:8000

然后再配Nginx做反向代理，Nginx负责处理静态文件和转发请求给Gunicorn。Nginx的配置文件大致是这样：

server { listen 80; server_name your_domain_or_ip; client_max_body_size 20M; location /static/ { alias /path/to/project/static/; } location /media/ { alias /path/to/project/media/; } location / { proxy_pass http://127.0.0.1:8000; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } }

这里有个细节：client_max_body_size如果不设置，默认是1MB，上传超过1MB的文件直接被Nginx拦截，前端会显示413 Request Entity Too Large。我第一次部署时就踩了这个坑，活动封面稍微大一点就传不上去，排查了很久才发现是Nginx的限制。

关于麒麟系统或其他Linux发行版，Django部署的底层逻辑基本一致，无非是Python版本、包管理命令稍有差异。在一个全新的Linux服务器上，建议先把Python版本确认好，再装好pip、venv、nginx，然后照着上面的步骤走。Django对Python版本比较敏感，建议项目开发时就用Python 3.9或3.10，这样可以避免后期环境问题。

4.4 上线前必须做的几件安全检查

很多同学把网站部署上线后就直接交差了，其实还有几项安全设置是上线前必须检查的：

• 把settings.py里的DEBUG改成False。如果DEBUG是True，一旦页面报错就会把完整堆栈和配置信息暴露给访问者，这是很危险的。
• 设置ALLOWED_HOSTS，只允许你指定的域名或IP访问。
• 强制HTTPS（有条件的话）。毕业设计如果只有IP没有域名，可以先跳过，但要知道这个点。
• 给Admin路径改个复杂一点的名字，比如把/admin/改成/campus-admin-panel/，避免被扫描工具直接爆破默认路径。
• 关闭注册接口的开放权限，或者加入验证码。我用的是简单的图形验证码，防止机器人刷注册。

Django的CSRF保护默认是开启的，模板里的所有POST表单都必须带{% csrf_token %}，这个不要漏，漏了表单提交会报403。如果你在前后端分离场景用了DRF，则要用JWT等方式处理认证，但毕业设计的传统服务端渲染场景下，Django的session加CSRF就足够了。

5. 常见问题排查与避坑经验实录

5.1 开发期必装的调试工具

排查问题最怕瞎猜。我第一次做Django项目时，遇到Bug就print，有时候打印出来的还不对，后来学会了用Django Debug Toolbar和Django Extensions。

• django-debug-toolbar：页面侧边栏会显示当前请求的SQL查询列表、查询耗时、模板渲染时间、配置信息，优化ORM时它是唯一标准。
• django-extensions：提供了shell_plus命令，进入命令行时自动导入所有模型，做数据操作测试非常方便。配合print_sql选项，可以在脚本运行过程中把每一条SQL都打印出来，定位N+1问题特别好使。

如果你遇到"页面能打开但数据不对"的问题，优先怀疑ORM查询逻辑，用query属性打印SQL就能看到实际去了哪张表、加上了什么条件。

5.2 常见报错和生产经验速查表

我把写这个项目时遇到的高频报错整理成了一张速查表，方便对照排查：

这张表基本覆盖了开发期间80%的报错场景。遇到报错时，先看最后一行或者回溯栈里自己写的代码行，再对照这张表找方向，大部分问题能在几分钟内定位。

5.3 答辩前性能优化与演示准备

答辩时最尴尬的场面就是现场演示时白屏、转圈、报错。我的建议是答辩前一晚不要改代码，只做两台设备的实机演示测试。如果在笔记本上跑runserver，提前把本地数据库和媒体文件整理好，用干净的数据去演示。

以下几个点是我自己踩过或者看别人踩过的坑：

• 演示时不要现场演示"注册新用户"，因为可能因为网络问题或者表单校验卡住，提前准备几个测试账号，直接登录进入系统。
• 演示上传文件功能时，提前准备一个几百KB的小图片和一个小PDF，大文件上传容易在答辩现场网络环境下卡住。
• 如果部署在服务器上，确认服务器带宽和内存足够，Django项目如果配置太低，首次启动和访问大页面会比较慢，建议服务器至少2核4G。
• 提前把备份数据库的命令写好，答辩前一天做一次数据库备份，避免当天操作失误损失数据。

答辩老师的提问通常会集中在"为什么选这个技术方案""数据库表之间的关系""安全方面做了哪些工作""这个项目还能怎么扩展"。这四类问题在这篇文章里其实都已经覆盖了。提前把这些问题的答案梳理一下，尤其是"还能怎么扩展"，可以结合校园网站的现状，比如接入支付、对接统一身份认证、增加消息通知推送、使用Celery做异步任务等。说出这些扩展点，会让老师觉得你对整个系统有完整的认知，而不只是照着教程敲了一遍代码。

6. 写在最后的一些心里话

做毕业设计这件事，说难也难，说简单也简单。难的是你需要在有限时间内完成需求分析、系统设计、编码、测试、文档撰写、答辩准备这一整套流程；简单的是选对了技术栈和项目方向之后，每天按计划推进一个小功能，几周时间坚持下来，系统就会像积木一样慢慢成型。我在做这个Django校园网站的过程中，最大的体会是"先把数据库设计做扎实，后面全是体力活，数据库做得烂，后面全是返工活"。如果你还停留在"功能不知道怎么拆、表不知道建几张"的阶段，不妨打开MySQL或SQLite，找一个下午把那几张核心表的结构画出来，再开始写代码，进度反而会快得多。

另外一点想说的是，毕业设计不是要做什么惊天动地的创新，而是要把一个完整的软件工程过程走下来。能清楚讲出"我为什么要用Django""用户表为什么这么设计""部署时为什么需要Nginx和Gunicorn"这些问题的答案，你的答辩就已经成功了一大半。希望这篇内容能帮你在Django校园网站这条路上省下一些不必要的绕路时间，做出一份能安心放进学生时代作品集的完整体验。最后再分享一个小技巧：在写完项目的当天，把整个项目的文件结构、核心表结构、所有URL路由打印出来贴在墙上或者放进答辩PPT的附录里，这会变成你临场应答时最可靠的地图。