企业官网建设流程全解析

毕业设计拿到一个“基于Django花卉商城系统”的题目，很多同学第一反应是慌，第二反应是套模板。说实话，商城类的毕设题目在计算机专业里出现频率极高，但正因为它常见，才更容易做得平庸，也更容易踩坑。这篇文章我打算把这类项目从选题定位、功能设计、数据库建模，到具体代码实现、本地运行、常见报错排查，再到最后毕设文档和答辩准备的完整链路，一次性讲清楚。内容是我带过好几轮模拟项目X（也就是这类“XX商城系统”）之后沉淀下来的实操经验，面向的是准备自己做、或者正在纠结怎么改别人源码的开发者，尤其是准备答辩的大四学生。你不需要有三年工作经验，只要能照着文章把每一步跑通，就足够产出一个能过审、能讲明白、能应付老师提问的完整系统。

1. 项目定位与选型思路：为什么是Django，为什么是花卉商城

1.1 选题背后的核心需求解析

先说最实际的问题：毕设题目那么多，为什么“花卉商城”这种电商类的题目常年霸榜？因为这类题目几乎覆盖了一门软件工程课程要求的全部知识点：前端页面交互、后端业务逻辑、数据库设计、用户认证、权限管理、文件上传、订单状态流转，甚至还可以扩展支付接口和数据分析。对学生来说，它既不会像“基于神经网络的情感分析”那样需要深厚的数学基础，也不会像“操作系统内核设计”那样难以落地，是一个一眼能看懂、三天能上手、一个月能打磨完毕的中间难度项目。

但“花卉商城”这类题目有个隐藏难点，就是业务完整度。很多同学以为商城就是“商品列表 + 加入购物车 + 下单”，做完一演示，老师问一句“你的库存怎么扣减的？订单超时怎么办？用户下单后想取消怎么处理？”就直接懵了。所以这篇文章虽然标题写的是花卉商城，实际上是把电商业务里最核心的一套状态机和数据关系讲透，你换成本地生活服务、校园二手交易、甚至是二手书商城，逻辑是完全通用的。

1.2 技术选型：为什么选Django而不是Spring Boot、Flask、Node.js

我给学生的建议里，技术选型从来不是“哪个好”，而是“哪个能让你顺利毕业且学到真东西”。横向对比一下主流方案：

Django最让我推荐的点，不是功能多，而是该有的都有了：用户认证、Session管理、CSRF防护、ORM迁移、Admin数据后台，这些在Spring Boot里要一个个集成、配置的东西，在Django里是开箱即用的。对于基础不是那么扎实的同学，这意味着你可以把有限的时间花在核心业务逻辑上，而不是耗在环境配置和框架配置里。

至于“为什么是花卉商城”，除了选题热度高之外，还有一个很实际的考虑：商品主图、分类、详情页展示是电商系统里最考验前端功底的模块。花卉类商品颜色丰富、图片美观，页面设计好了非常出效果，在答辩演示时视觉冲击力很强，老师的第一印象就会好很多。做这种视觉型项目，千万不要选那种图片灰扑扑、页面空荡荡的选题。

2. 需求拆解与功能模块设计：先画图再写码

2.1 用户端与后台管理的功能边界

很多同学拿到项目就开始建表写代码，这是最大的忌讳。任何商城系统落到需求层面，先分清楚“谁能用什么功能”才是第一优先级。我一般习惯把整个系统拆成两个端、三条线：

• 用户端（前台商城）：面向普通浏览者/注册用户

  • 商品浏览：首页推荐、分类筛选、关键词搜索、商品详情
  • 用户操作：注册、登录、个人信息维护
  • 交易闭环：加入购物车、修改数量、删除商品、提交订单、模拟支付、取消订单、查看历史订单
  • 互动功能：收藏商品、加入收藏夹（可做加分项）

• 管理端（后台）：面向管理员/运营人员

  • 商品管理：商品的增删改查、上下架、库存调整、价格修改
  • 分类管理：商品分类的维护
  • 订单管理：查看订单列表、修改订单状态（发货/取消）
  • 用户管理：查看注册用户信息、禁用/启用账号

这三条线分别是商品流、订单流、用户流。把这三条线的数据流转画清楚，你的数据库模型就已经完成一半了。

我建议在动手写代码之前，花半天时间用纸笔画出两个图：一是功能模块图（MindManager或手绘都行），二是订单状态流转图。尤其是后者，订单在什么时候能取消、什么时候能支付、什么时候能发货、什么时候算完成，这个状态机是你整个项目最核心的逻辑闭环。很多同学挂在答辩上的问题就是订单状态混乱：订单已发货了还能取消，已支付了还能改价，这些都是状态机没设计清楚导致的。

2.2 数据库模型设计：五张核心表撑起整个系统

Django的ORM模型是直接对应数据库表的。商城系统的表结构可以有很多版本，但核心关系是相对固定的。我以最常见的实现方案为例，你得清楚以下五张核心表：

用户表（User）

• 直接使用Django内置的django.contrib.auth.models.User扩展，不要自己重新造轮子
• 扩展一个Profile模型或直接在User上增加手机号、收货地址、头像等字段

商品分类表（Category）

• 字段：名称、父级分类（自关联）、排序、是否显示
• 商品分类通常是二级结构，比如“鲜切花”下面再分“玫瑰”“百合”

商品表（Flower/Product）

• 字段：名称、所属分类、价格、库存、销量、主图、描述、状态（上架/下架）
• 外键关联Category
• 注意：价格字段用DecimalField，不要用FloatField，浮点运算会出精度问题

购物车表（Cart）

• 字段：所属用户、所属商品、数量、添加时间
• 唯一性约束：一个用户和一种商品的组合只允许存在一条记录

订单表（Order）和订单明细表（OrderItem）

• 这是整个系统最关键的两张表，采用“主从表”结构：Order记录订单整体信息（订单号、用户、总金额、状态、创建时间、收货信息），OrderItem记录订单里的每一件商品（属于哪个订单、哪个商品、单价、数量）
• 为什么不用一张表？因为一张表没法表达“一个订单包含多样商品”的业务逻辑

更多扩展（可选加分项）

• 收藏表（Favorite）、轮播图表（Banner）、地址表（Address）、评论表（Comment）

数据库建模这里，Django的models.py写法有一个非常实用的技巧：所有外键字段用on_delete=models.CASCADE还是SET_NULL，一定想清楚再定。比如商品分类被删除后，商品怎么办？如果分类删除后商品也想跟着删，用CASCADE；如果不想让商品被误删，在Category删除前先做判断，或者用SET_NULL配合null=True。我在实际项目里，分类表一般用PROTECT，有商品关联时禁止删除分类，提示管理员先处理商品。

3. 核心功能实现与代码拆解：照着写就能跑的方案

3.1 用户注册登录与个人中心

用户认证这块，Django内置的认证系统已经非常完善。我在项目里通常采用username + email + password的注册方式，给User扩展一个Profile表存昵称、手机号和默认收货地址。

关键代码示例（models.py扩展用户）：

from django.contrib.auth.models import User from django.db import models class Profile(models.Model): user = models.OneToOneField(User, on_delete=models.CASCADE, related_name='profile') phone = models.CharField(max_length=11, blank=True, verbose_name='手机号') address = models.CharField(max_length=255, blank=True, verbose_name='默认收货地址') avatar = models.ImageField(upload_to='avatars/', blank=True, null=True, verbose_name='头像') def __str__(self): return self.user.username

注册逻辑要注意几个细节：密码加密（Django自动处理，不用操心）、用户名唯一性校验、密码二次确认、登录后跳转回原页面。这里分享一个实际面试/答辩里经常被问到的小知识点：Django的authenticate()验证时，如果用户设置了is_active=False，会默认验证失败。这在做“管理员禁用用户”功能时非常有用，不用额外写逻辑。

视图函数（views.py）关键逻辑：

from django.contrib.auth import authenticate, login from django.shortcuts import render, redirect def register_view(request): if request.method == 'POST': username = request.POST.get('username') password = request.POST.get('password') confirm_password = request.POST.get('confirm_password') if password != confirm_password: return render(request, 'register.html', {'error': '两次密码不一致'}) if User.objects.filter(username=username).exists(): return render(request, 'register.html', {'error': '用户名已被注册'}) # 这里用User.objects.create_user而不是create，前者会自动加密密码 user = User.objects.create_user(username=username, password=password) login(request, user) return redirect('mall:home') return render(request, 'register.html')

重要提醒：创建用户时一定要用create_user()而不是create()。这是新手最常见的问题之一，用create()存的是明文密码，登录时无论如何都验证不过去，而且这种项目拿到答辩现场会非常丢人。

3.2 商品展示：首页、列表页、详情页

商品展示说白了就是一个“读多写少”的模块。核心逻辑全在查询条件上，但这里面有几个可以让项目档次明显提升的细节：

• 首页：推荐位设计。不要简单地把所有商品铺出来，可以做“新品上架”“热销排行”两个推荐位，分别按创建倒序和销量倒序取前N条数据
• 列表页：分类过滤 + 关键词搜索 + 排序（按销量、价格升降序）
• 详情页：多图展示、库存显示（库存为0显示“缺货”而不是“加入购物车”按钮）

列表页的视图函数（views.py）示例：

from django.shortcuts import render, get_object_or_404 from django.core.paginator import Paginator from .models import Flower, Category def product_list(request, category_id=None): products = Flower.objects.filter(status=True) # 只显示上架商品 if category_id: category = get_object_or_404(Category, id=category_id) # 当前分类下的所有商品（包含子分类） child_ids = Category.objects.filter(parent=category).values_list('id', flat=True) products = products.filter(category__in=[category_id] + list(child_ids)) keyword = request.GET.get('q', '') if keyword: products = products.filter(name__icontains=keyword) sort = request.GET.get('sort', 'default') if sort == 'price_asc': products = products.order_by('price') elif sort == 'price_desc': products = products.order_by('-price') elif sort == 'sales': products = products.order_by('-sales') paginator = Paginator(products, 12) page_number = request.GET.get('page') page_obj = paginator.get_page(page_number) return render(request, 'mall/product_list.html', { 'page_obj': page_obj, 'category': category if category_id else None, 'keyword': keyword, 'sort': sort, })

这里有一个非常值得注意的点：列表页一定要做分页。商城数据少的时候看不出差别，但答辩时老师大概率会问“数据量增大到一万条、十万条时你的项目怎么优化？”如果你已经做了分页，再回答“分页 + 数据库索引”，这就是一个非常清晰的加分回答。很多同学的项目里商品一共就十几条，还在前端一次性渲染全部数据，这种问题被问到就非常被动。

3.3 购物车与订单流程：最核心的业务闭环

购物车和订单是整个系统技术含量最高的部分，也是答辩提问最多的地方。先把业务逻辑理清楚。

购物车：

• 加购：如果该用户购物车里已有这件商品，数量累加；否则新增一条记录
• 修改数量：前端传数量，后端校验库存够不够
• 删除/清空

购物车视图函数（views.py）示例：

import json from django.http import JsonResponse from django.contrib.auth.decorators import login_required from .models import Cart, Flower @login_required def add_to_cart(request, product_id): product = get_object_or_404(Flower, id=product_id, status=True) if not product.is_available(): # 自定义方法：检查库存>0 return JsonResponse({'success': False, 'message': '商品已缺货'}) cart_item, created = Cart.objects.get_or_create( user=request.user, product=product, defaults={'quantity': 1} ) if not created: cart_item.quantity += 1 cart_item.save() return JsonResponse({'success': True, 'message': '已加入购物车', 'count': cart_item.quantity})

订单提交的逻辑链条要理清楚：

1. 从前端接收购物车里选中的商品ID列表、收货地址
2. 后端重新从数据库读取购物车记录（永远不要信任前端传过来的价格和总金额）
3. 计算总价时要用当前数据库里的商品价格，防止用户修改前端页面后以低价下单
4. 校验库存是否足够，如果库存不足，该商品返回错误提示
5. 创建Order主表记录，状态设为待付款
6. 把购物车记录转成OrderItem明细，同时扣减库存
7. 删除购物车记录
8. 跳转到收银台页面（模拟支付）

下单逻辑我建议单独写一个事务，因为创建订单、扣库存、清购物车这三个操作必须是原子性的，任何一个失败都应该整体回滚。Django里用transaction.atomic()包裹即可，这也是老师非常喜欢问的点——“你的项目里哪里用了事务？为什么用？”能回答上来就直接展示了数据库基本功。

订单确认视图（views.py）示例：

from django.db import transaction from django.contrib.auth.decorators import login_required from django.shortcuts import render, redirect from django.http import JsonResponse from .models import Order, OrderItem, Cart @login_required def create_order(request): if request.method != 'POST': return JsonResponse({'success': False, 'message': '非法请求'}) cart_ids = request.POST.getlist('cart_ids') address = request.POST.get('address', '') if not cart_ids or not address: return JsonResponse({'success': False, 'message': '请选择商品并填写收货地址'}) cart_items = Cart.objects.filter(id__in=cart_ids, user=request.user) if not cart_items.exists(): return JsonResponse({'success': False, 'message': '购物车为空'}) try: with transaction.atomic(): total_amount = 0 # 加行锁，防止并发超卖（select_for_update） for item in cart_items.select_for_update(): if item.quantity > item.product.stock: return JsonResponse({'success': False, 'message': f'{item.product.name} 库存不足'}) order = Order.objects.create( user=request.user, order_no=generate_order_no(), # 自定义订单号生成函数 total_amount=0, status='pending', address=address ) for item in cart_items: OrderItem.objects.create( order=order, product=item.product, product_name=item.product.name, price=item.product.price, quantity=item.quantity ) # 扣减库存 item.product.stock -= item.quantity item.product.sales += item.quantity item.product.save() order.total_amount += item.product.price * item.quantity order.save() cart_items.delete() # 清空已下单的购物车记录 except Exception: return JsonResponse({'success': False, 'message': '下单失败，请重试'}) return JsonResponse({'success': True, 'order_id': order.id, 'message': '下单成功'})

这段代码里有几个值得在答辩时展开讲的点：select_for_update()是加了数据库行锁，解决并发下单超卖问题；OrderItem冗余了product_name和price字段，因为商品可能改价甚至删除，订单明细必须保存下单时刻的快照。这些细节都是区分“会抄代码”和“懂业务”的关键。

3.4 订单状态机与模拟支付

一个完整的商城，订单状态至少应当是：待付款 → 待发货 → 待收货 → 已完成，外加两个旁路：已取消和已关闭。

• 用户下单后状态为pending
• 在收银台点击“模拟支付”，调用一个模拟支付接口，把订单状态改为paid（待发货）
• 管理员在后台订单管理里点击“发货”，订单状态改为shipped
• 用户在前台点击“确认收货”，订单状态改为completed

这个状态流转，后台管理页面基本就是一组按钮配合一个状态字段做条件渲染。具体实现时我会在Order模型里加几个方法：

class Order(models.Model): STATUS_CHOICES = [ ('pending', '待付款'), ('paid', '待发货'), ('shipped', '待收货'), ('completed', '已完成'), ('cancelled', '已取消'), ('closed', '已关闭'), ] # 订单状态变更方法 def cancel(self): if self.status in ['pending', 'paid']: # 返还库存 for item in self.items.all(): item.product.stock += item.quantity item.product.save() self.status = 'cancelled' self.save()

库存返还这个逻辑很多人容易漏掉：用户下单扣了库存，但他取消了订单，库存不还回去，系统就出现“货没了但单也没了”的荒谬状态。这个小功能，写好了就是答辩时一个很漂亮的业务完整度展示。

4. 开发环境搭建与本地运行指南：从零到能跑的完整步骤

4.1 环境版本选择与安装配置

这个项目我推荐一套经过大量验证的稳定组合，照着装不会出兼容性问题：

• Python 3.10或3.9（3.12也能跑，但个别依赖配置麻烦一些）
• Django 4.2 LTS（长期支持版本，生态稳定，教程资料最多）
• MySQL 5.7 / 8.0 或 SQLite（本地开发强烈建议MySQL，提交文档时说明部署环境；如果嫌麻烦就用SQLite先跑通）
• 前端：Django模板 + Bootstrap 5 + JQuery（不要引入过于复杂的前后端分离方案，会增加答辩负担）

安装过程直接用pip即可：

# 创建并激活虚拟环境 python -m venv venv # Windows: venv\Scripts\activate # macOS/Linux: source venv/bin/activate # 安装依赖 pip install django==4.2 mysqlclient # 创建Django项目与应用 django-admin startproject config . python manage.py startapp mall python manage.py startapp usercenter

4.2 settings.py配置：连接数据库与注册应用

数据库推荐MySQL时，settings.py配置如下：

DATABASES = { 'default': { 'ENGINE': 'django.db.backends.mysql', 'NAME': 'flower_shop', 'USER': 'root', 'PASSWORD': 'your_password', 'HOST': '127.0.0.1', 'PORT': '3306', 'OPTIONS': { 'charset': 'utf8mb4', }, } }

然后依次执行：

python manage.py makemigrations python manage.py migrate python manage.py createsuperuser python manage.py runserver

提示：如果迁移时报ModuleNotFoundError: No module named 'MySQLdb'，说明mysqlclient没装成功。Windows装mysqlclient经常失败，解决方案是用pip install pymysql，然后在config/__init__.py里加上两行代码：

import pymysql pymysql.install_as_MySQLdb()

这行代码的作用是把PyMySQL伪装成MySQLdb，Django就能直接使用了。

4.3 图片上传与静态资源路径配置

商品的基本字段（名称、价格、库存、描述）都好配，最容易出问题的是图片。Django中图片上传依赖Pillow库，记得提前安装：

pip install Pillow

MEDIA配置是很多同学忽略的重点：

import os MEDIA_URL = '/media/' MEDIA_ROOT = os.path.join(BASE_DIR, 'media') STATIC_URL = '/static/' STATICFILES_DIRS = [ os.path.join(BASE_DIR, 'static'), ]

同时，需要在config/urls.py里补上media的服务（开发环境下使用）：

from django.conf import settings from django.conf.urls.static import static urlpatterns = [ # ... 其他路径 ] if settings.DEBUG: urlpatterns += static(settings.MEDIA_URL, document_root=settings.MEDIA_ROOT)

这一步漏掉的话，后台管理里虽然能上传图片，但前台页面全部显示裂图。很多同学问我为什么图片显示不出来，十有八九就是这里没配置。

5. 常见问题排查与避坑记录：真实调试经验分享

5.1 高频报错与解决方案速查表

这一节是我在辅导过程中真实遇到的最高频问题，直接按场景整理，遇到了按图索骥就可以解决。

5.2 逻辑层面最容易翻车的三个细节

第一个坑：订单总金额在提交时没有重新计算。前端的金额可以显示，但后端提交订单时绝对不能信任前端传来的金额数据。我见过有同学把总价放在表单的hidden字段里传过去，这是非常严重的安全漏洞，用户用浏览器的开发者工具改一下属性值，就能用1分钱下单。所有金额计算必须在后端根据数据库价格实时算。

第二个坑：购物车和订单的商品数量没有和库存联动。很多同学只在商品详情页做了“库存不足不能加购”的判断，但用户在购物车里把数量改成9999怎么办？下单的时候又忘了校验，直接生成了一张超过库存的订单。正确做法是：加购校验一次、购物车改数量校验一次、提交订单时再校验一次，三次校验全部通过才能继续。这个“层层校验”的思路放在答辩里讲，就是一个非常完整的业务安全性体现。

第三个坑：取消订单后库存没有返还。这个前面已经提过，再强调一次：凡是订单状态从“已支付/待发货”变成“已取消”，对应的商品库存必须加回来，销量必须减掉，否则库存数据会越跑越失真。我见过做校园二手交易项目的同学，因为忽略了这个逻辑，系统里的库存数据跑到负数，演示的时候直接被老师抓包。

5.3 一条龙定制里的代码讲解应该怎么听才有效

标题里提到的“一条龙定制”，本质上是购买源码之后，由作者把系统给你跑通、把代码给你讲明白，甚至帮你整理文档和指导答辩。这里我想给所有打算买源码的同学几个建议。

第一，代码讲解一定要听，不要只看文档。文档写得再细，也不可能覆盖到老师随意追问的任何一个角度。你要重点听作者讲三个东西：数据库表之间的关系（外键怎么关联的）、订单状态怎么流转的、登录认证是怎么实现的。这三个问题听懂了，你的答辩就已经成功了一半。

第二，拿到源码第一件事不是看代码，而是先跑起来。先配环境、迁移数据库、创建管理员账号、上传几张商品图，把系统完整跑通一次。再看代码，理解起来会事半功倍，因为你已经知道“每一步操作背后能产生什么结果”。

第三，规划好每个功能在答辩时的“演示脚本”。比如演示注册登录，别从头开始填表单，提前准备好账号密码，演示时几秒钟就进去。演示购物车和下单时，提前确认库存充足、图片正常。这些小细节能让你在台上极度从容。

6. 毕设文档整理、代码讲解与答辩准备的进阶建议

6.1 论文/设计文档结构怎么搭

大多数学校的毕设文档都遵循“绪论 - 相关技术 - 需求分析 - 系统设计 - 系统实现 - 系统测试 - 总结”的标准结构。基于这个项目，每一章的内容填充可以这样规划：

• 绪论：写花卉电商的发展背景、传统花店转型线上需求，但注意别写成百科词条，一定要落脚到“我为什么要做这个系统”
• 相关技术：介绍Python、Django、MySQL、Bootstrap。这一章要避免大段抄官方文档，每介绍一个技术，加一句“在本系统中用于实现XXX功能”
• 需求分析：画用例图，把用户和管理员的两种角色在系统里能干的每一件事列清楚
• 系统设计：画系统架构图和数据库ER图。这一章是得分大头，数据库表结构要写清楚每个字段的含义、类型和约束
• 系统实现：按功能模块逐一贴关键代码并解释逻辑，重点讲清订单模块和购物车模块的实现细节
• 系统测试：用测试用例表罗列功能测试用例，包括正常流程和异常流程（比如库存不足、密码错误）

不过文档写作有个很容易踩的坑：不要贴整段大代码。老师看了会觉得你是从源码复制过来的。正确姿势是只贴关键片段（比如transaction.atomic()包裹的订单提交函数），配合一大段解释文字，说明这段代码实现了什么、用了什么技术、解决了什么问题。

6.2 答辩演示脚本与高频问题预演

答辩演示的系统准备，核心就是稳。别在台上演示功能时才发现图片挂了、数据库没启动、账号登不进去。我习惯让学生在答辩前做一轮“六步走”演示彩排：

1. 登录前台账号，演示商品列表、分类筛选、关键词搜索
2. 点进商品详情，加入购物车，然后去购物车页面修改数量、删除
3. 提交订单、模拟支付，到“我的订单”里看到订单状态更新成待发货
4. 切到后台管理账号，找到这笔订单，点击发货
5. 切回前台，刷新订单状态，点击确认收货
6. 在后台添加一个新商品，做一次商品上下架展示

整个过程控制在8-10分钟，语速中等，每切换一个页面，嘴里说一句“这里是XXX功能，实现了XXX逻辑”，非常加分。

至于老师会追问哪些问题，高频的就那几个：

• “为什么选用Django？”（答开发效率高、内置认证/ORM/后台、适合中小型业务快速落地）
• “数据库表之间是什么关系？”（答商品和分类是多对一，订单和订单明细是一对多，用户和购物车是一对多）
• “并发下如何防止超卖？”（答事务 +select_for_update()行锁）
• “密码是怎么加密存储的？”（答Django内置PBKDF2算法，create_user()自动处理）
• “前端页面数据是怎么渲染的？”（答Django模板语法，{{ }}渲染变量、{% for %}循环，配合Bootstrap做布局）

这些问题平时自己在项目里跑过、想过，回答起来就非常流畅。

6.3 项目上线与后续扩展建议

如果还有余力，或者在简历上想把这段经历写得更有竞争力，可以做几个低成本但高价值的扩展：

• 接入真实的第三方支付SDK：把模拟支付接口替换成沙箱环境下的真实支付流程，简历上可以写“已对接第三方支付沙箱环境”
• 增加简单的数据统计看板：在管理后台加一个首页统计页面，展示今日订单数、销售额、热销商品Top5，图表可以用ECharts，这个功能对答辩展示效果提升非常明显
• 用Redis做缓存：把首页推荐位、商品分类列表这些高频读取的数据缓存起来，答“性能优化”的问题时就有了实际案例

我个人做这类项目最大的体会是：别把“毕设”当成一个交作业的任务，而是当成第一个能完整体现你工程能力的作品。把用户注册登录、商品展示、购物车、订单、后台管理这一整套电商闭环亲手跑通，你对Web开发的理解会瞬间从“会写函数”升级到“会设计系统”。很多说毕设没东西写、简历没项目放的同学，问题往往不是能力不够，而是把一个本该认真打磨的项目草草糊弄过去了。

最后分享一个实用小技巧：每天改完代码，记得用python manage.py makemigrations和python manage.py migrate把数据库变更同步一下，然后跑一遍核心流程（登录、加购、下单）确保没改坏。这个习惯看似简单，但能让你在最后交项目的前一天晚上避免“改了代码，数据库没迁移，演示时直接白屏”的惨剧。做毕设这件事，稳比快重要得多。