尧图网站建设 
Django写毕业设计这件事说难不难说简单也真不简单。尤其是产品订单管理系统这种经典题目每年都有大量计算机相关专业的学生在选需求量巨大网上却很难找到一份真正能跑通、能讲清楚、能应付答辩的完整源码。我之前带过不少学弟学妹做类似项目自己也完整开发过这套基于Django的产品订单管理系统顺手把完整源码整理了出来编号28794。这篇文章不打算写成那种枯燥的课程设计报告而是想从一个实际开发者的角度把整个项目从选题思路、技术选型、功能设计、数据库建模、核心代码实现到部署运行、常见坑位排查、答辩准备一条线全部捋清楚。无论你是完全没接触过Django的小白还是已经有基础但卡在某个环节的老手这篇文章都能给你一张可以直接照着走的地图。1. 项目整体设计与选题思路拆解1.1 为什么毕业设计要选“产品订单管理系统”每到毕业季选题永远是第一道坎。很多同学在“图书管理系统”“学生管理系统”“网上商城”这些经典题目之间反复纠结但我个人强烈推荐产品订单管理系统。原因很简单这个题目业务逻辑清晰、功能边界明确、技术覆盖全面而且非常好演示。产品订单管理系统本质上就是一个轻量级的进销存核心模块它涉及到用户、商品、订单、订单详情这几个核心实体几乎串联起了Web开发的所有基础知识点。你需要做登录注册就会用到Django自带的认证系统你需要做商品列表和搜索就会接触到ORM查询和模板渲染你需要做下单流程就会涉及到事务处理、外键关联、状态字段的变更你需要做后台管理Django Admin直接给你省掉一大半体力活。这一个题目做完你基本就把Django的核心功能全部过了一遍答辩的时候无论老师从哪个角度问你都有东西可讲。而且这类系统的演示效果非常好。你可以在后台添加几个产品设置库存和价格然后从前台注册一个用户下单、支付、查看订单状态整个流程走下来逻辑自洽演示画面充实老师一眼就能看懂你做的是什么不需要过多的解释。1.2 技术选型为什么是Django而不是Flask或Spring Boot先说说技术栈的核心选择。产品订单管理系统可以用很多框架来做PHP可以用LaravelJava可以用Spring BootPython呢主流就是Django和Flask两个选择。Flask的优势是轻量灵活但正因为它太灵活对于毕业设计来说反而是一种负担。用户登录怎么做、表单验证怎么做、ORM用哪个、目录结构怎么组织一切都得自己来选自己来配。我见过太多用Flask写毕业设计的同学前期搭环境就花了两个星期最后代码风格千奇百怪自己都理不清。Django则完全相反。它是一个重框架把Web开发中绝大部分通用的东西都替你做好了。自带Admin后台、自带ORM、自带认证系统、自带表单处理、自带模板引擎甚至连分页、消息提示、CSRF防护这些细节都已经给你实现好了。你只需要关注业务逻辑本身把产品、订单这些核心模型设计好剩下的基础设施它全包了。用一个生活化的类比来说Flask像是给你一堆积木让你自己搭房子Django则是给你一套已经通水通电的毛坯房你只需要刷墙和买家具就行了。对于毕业设计这种以展示业务逻辑为主的场景Django明显是效率最高、容错率最低的选择。1.3 系统的功能模块划分整个产品订单管理系统我按照业务域拆分成三大模块用户端、管理端、数据层支撑。用户端面向普通注册用户包含注册登录、产品浏览、关键词搜索、产品详情查看、加入购物车、订单提交、订单支付模拟、个人订单历史查询、个人信息维护这些功能。这一部分是系统的主体答辩演示时绝大部分操作都在这里完成。管理端则是面向系统管理员的。我直接把Django自带的Admin后台改造扩展成了管理界面管理员可以在这里完成产品的新增上下架、库存调整、价格修改、订单状态审核、用户管理这些操作。使用Django Admin的好处是几乎零成本就能获得一个完整的管理后台而且它的UI是现成的你不用花时间写增删改查页面写代码的时间可以集中到业务流程上。数据层是整个系统的地基。产品表、用户表、订单表、订单项表、分类表共同构成了系统的数据核心。这里面的字段设计、关系设计是整篇代码里最考验基本功的部分也是答辩时最容易深挖的区域。2. 系统核心功能详解与数据库设计2.1 用户认证与权限控制是怎么做的用户部分我直接基于Django内置的User模型做了扩展而不是自己新建一张用户表。这个选择非常重要因为django.contrib.auth已经实现了注册、登录、密码哈希、Session管理、登录状态校验这一整套机制你不需要重复造轮子。具体做法是创建一个UserProfile模型通过OneToOneField和一系统自带的User关联用来保存手机号、收货地址、注册时间等额外信息。注意这里的关联关系只能用OneToOneField而不能用ForeignKey原因是一对一关系保证了一个User只能对应一条扩展信息用外键的话可能会出现一个用户多条扩展记录的数据脏状态。权限控制方面普通用户和管理员的区别我并没有做太复杂的RBAC权限表而是通过Django自带的is_staff字段来判断。用户端页面里所有需要登录才能访问的视图函数都加上了login_required装饰器这样未登录用户访问订单页面时会被自动重定向到登录页。Admin后台本身只对is_staffTrue的用户开放这就实现了用户和管理员在入口处的天然隔离。这里还要提到一个很多新手会踩的坑密码存储。如果你自己写登录逻辑绝对不要用MD5这种散列算法直接存密码一定要用Django默认的PBKDF2算法。Django的create_user方法会自动帮你做密码哈希和加盐处理你要是手贱用User.objects.create(passwordxxx)这种方式去创建用户密码就会变成明文存进去不仅不安全而且登录时永远验证不过因为Django的authenticate方法会对输入的密码再做一次哈希去比对。2.2 产品与分类的数据建模产品表是整个系统的核心表字段设计直接决定了后面功能的开发难度。我的产品模型包含以下关键字段name产品名称CharField最大长度100加db_indexTrue索引因为产品搜索是按名称模糊匹配的category外键关联分类表on_deletemodels.CASCADE分类删除时该分类下的产品一并删除price价格字段这里必须用DecimalField而不是FloatField因为浮点数在计算机中无法精确表示会出现0.10.2不等于0.3的问题订单金额计算是敏感数据绝不能有精度损失stock库存数量IntegerField默认0image产品图片我用的是ImageField需要配置MEDIA_ROOT和MEDIA_URLstatus上下架状态BooleanField用True/False表示上架/下架sales销量字段每次下单成功后累加用于排序展示description产品描述TextFieldcreated_at创建时间DateTimeField(auto_now_addTrue)分类表比较简单就是name和parent自关联外键实现了一级分类和二级分类的树形结构。不过说实话如果你们毕设要求不高分类做成一个扁平结构也完全够用不必过度设计。这里有个非常关键的细节price字段我用了max_digits10, decimal_places2很多新手在定义价格时喜欢用FloatField或者IntegerField前者精度丢失后者无法表示小数价格都会在后续计算时出问题。2.3 订单与订单项的设计为什么会话级的购物车不够用订单部分是这个系统的重头戏也是整个设计中最能体现专业度的地方。我用了两张表来完成订单数据存储主表Order和从表OrderItem。Order表字段设计如下order_no订单编号CharField用时间戳加随机数的方式生成保证唯一性展示给用户看的是一个像20240614153000123456这样的编号user外键关联用户on_deletemodels.CASCADEtotal_amount订单总金额DecimalFieldstatus订单状态IntegerField加了choices参数用数字标识状态是我特别推荐的做法。状态定义如下状态值含义说明0待付款订单已创建但未完成支付1待发货已付款等待管理员处理2已发货管理员已发货3已完成用户确认收货流程完结4已取消用户取消或超时未付款自动取消用数字存储状态而不是字符串在后续写filter(status1)这种查询时会非常方便而且如果要扩展新状态只需要增加一个数字映射就够了不需要改表结构。OrderItem表则保存订单快照信息关联到Order主表的外键、关联产品的ID、购买时的产品名称、购买时的单价、购买数量。为什么要多存一份“购买时的产品名称和单价”因为商品信息是易变的今天你下单时商品卖100块明天管理员改成120块你查看历史订单时如果直接去关联产品表读价格读到的是改了之后的价格这显然不符合业务逻辑。所以订单项里必须冗余一份商品名称和单价的快照这才是正规电商系统的做法。购物车我一开始用的是Session存列表后来发现Session存购物车有问题用户退出登录或者清理浏览器缓存购物车就空了。后来我改成了数据库存储新建了一个CartItem模型这样购物车数据是持久的用户体验好得多。但如果你为了省事Session方案也不是不能交差具体情况看你们老师对功能完整度的要求。3. 实操过程从环境搭建到核心代码实现3.1 开发环境准备与项目初始化先说环境。我本机用的是Python 3.10Django版本用的是3.2 LTS为什么不用Django 4.x或者5.x因为3.2是长期支持版本稳定性最好网上遇到的坑基本都能搜到解决方案。你如果用最新的Django 5.0很多第三方库和教程还没有完全跟上遇到环境兼容问题不容易排查。反正毕业设计用的技术栈只要confirm能够完成功能即可没必要盲目追求新版本。创建项目的完整命令流程如下# 创建虚拟环境这个习惯一定要养成 python -m venv venv # 激活虚拟环境Windows venv\Scripts\activate # 激活虚拟环境Mac/Linux source venv/bin/activate # 安装Django pip install django3.2 # 创建项目 django-admin startproject order_system # 进入项目目录 cd order_system # 创建应用 python manage.py startapp product python manage.py startapp order python manage.py startapp user这里我强烈建议按照业务边界拆分App不要把所有代码都堆在一个views.py里。产品相关的放product应用订单相关的放order应用用户相关的放user应用。这样后期维护代码时定位问题非常快也符合Django的哲学。创建完App之后记得去settings.py里的INSTALLED_APPS注册这三个应用然后配置数据库、静态文件、媒体文件这几项# settings.py 核心配置 INSTALLED_APPS [ django.contrib.admin, django.contrib.auth, django.contrib.contenttypes, django.contrib.sessions, django.contrib.messages, django.contrib.staticfiles, product, order, user, ] # 这里我用的是SQLite毕业设计完全够用 DATABASES { default: { ENGINE: django.db.backends.sqlite3, NAME: BASE_DIR / db.sqlite3, } } # 媒体文件产品图片配置 MEDIA_URL /media/ MEDIA_ROOT BASE_DIR / media # 登录跳转配置 LOGIN_URL /user/login/ LOGIN_REDIRECT_URL /3.2 核心代码实现产品列表到下单全链路产品列表页的逻辑非常简单就是一个普通的ORM查询加分页。关键代码在product/views.pyfrom django.core.paginator import Paginator from django.shortcuts import render from .models import Product, Category def product_list(request): # 获取当前选中的分类ID默认是None category_id request.GET.get(category) keyword request.GET.get(keyword, ).strip() products Product.objects.filter(statusTrue) # 只显示上架商品 # 分类筛选 if category_id: products products.filter(category_idcategory_id) # 关键词搜索 if keyword: products products.filter(name__icontainskeyword) # 按销量排序让卖得好的排前面 products products.order_by(-sales) # 分页每页12个商品 paginator Paginator(products, 12) page_number request.GET.get(page) page_obj paginator.get_page(page_number) categories Category.objects.all() return render(request, product_list.html, { page_obj: page_obj, categories: categories, current_category: category_id, keyword: keyword, })这里需要注意name__icontains这个写法i表示忽略大小写contains表示模糊查询翻译成SQL就是WHERE name LIKE %keyword%。下单流程是整个系统最核心的部分也是最容易出bug的地方。我建议你按照我下面这个顺序来写# order/views.py 下单逻辑 from django.shortcuts import get_object_or_404, redirect from django.contrib.auth.decorators import login_required from django.db import transaction from django.utils import timezone from .models import Order, OrderItem, CartItem from product.models import Product import random login_required def create_order(request): if request.method POST: # 读取当前用户的购物车 cart_items CartItem.objects.filter(userrequest.user) # 判断购物车是否为空 if not cart_items.exists(): return redirect(/cart/) # 计算总价 total_amount sum([item.product.price * item.quantity for item in cart_items]) # 创建订单主表记录 with transaction.atomic(): order Order.objects.create( order_nogenerate_order_no(), userrequest.user, total_amounttotal_amount, status0, # 待付款 ) # 创建订单项并更新库存 for item in cart_items: product item.product # 并发场景下防止超卖使用F表达式原子更新 from django.db.models import F result Product.objects.filter( idproduct.id, stock__gteitem.quantity ).update(stockF(stock) - item.quantity) # 如果库存不够抛出异常回滚整个事务 if result 0: raise Exception(f商品 {product.name} 库存不足) OrderItem.objects.create( orderorder, productproduct, product_nameproduct.name, priceproduct.price, quantityitem.quantity, ) # 清空购物车 cart_items.delete() return redirect(/order/success/ str(order.id) /) return redirect(/cart/)这个下单逻辑里有几个非常讲究的设计点我详细解释一下。第一我使用了transaction.atomic()包裹整个创建订单的过程。这意味着订单主表、订单项、库存扣减要么全部成功要么全部失败。想象一个场景用户下单创建了订单但扣库存时发现库存不够了如果你没有事务订单表里就会残留一条错误订单记录库存没有扣成功但钱已经“下”出去了这显然是数据不一致的严重bug。第二扣库存我用了F表达式。很多新手是这样写扣库存的product.stock - item.quantity product.save()这种写法在并发场景下会出大问题。两个用户同时下单A用户读到库存是10B用户也读到库存是10A扣减后保存为8B扣减后保存为8最终库存就错了。F表达式则是在数据库层面执行原子操作等价于UPDATE product SET stock stock - 1 WHERE id 1 AND stock 1这样就不会出现超卖。第三在Product.objects.filter(idproduct.id, stock__gteitem.quantity).update()中stock__gteitem.quantity这个条件保证了库存充足才允许扣减如果库存不够update返回0我直接抛异常让事务回滚完成了超卖保护。3.3 订单状态流转与列表展示订单状态流转就是在用户和管理员操作时更新status字段。用户端可以执行的操作是付款把状态从0改成1、取消把状态从0改成4、确认收货把状态从2改成3。管理端可以执行的操作是发货把状态从1改成2。这个状态机其实非常简单但要注意在视图函数里加状态校验防止用户跳过中间状态乱改login_required def pay_order(request, order_id): order get_object_or_404(Order, idorder_id, userrequest.user) # 只有待付款状态的订单才能支付 if order.status 0: order.status 1 order.pay_time timezone.now() order.save() # 这里模拟支付流程实际项目会接入第三方支付接口 return redirect(/order/detail/ str(order.id) /)有人可能会觉得奇怪支付这么重要的环节怎么会“模拟”这里需要说明一下毕业设计里接入真实的微信支付或支付宝支付需要企业资质和备案域名学生个人是没有办法申请到的。所以绝大多数毕设都是做支付模拟即点击付款按钮直接改变订单状态为已支付然后在答辩时说明“实际项目中这里会替换为调用支付网关”。如果老师要求更好看的效果可以在付款页面做个二维码图片的展示、支付倒计时之类的界面效果但底层逻辑还是状态更新因为在沙箱环境里调通真实的支付接口相对耗时投入产出比不高。订单列表页要特别注意查询性能。因为订单表要和OrderItem关联查询出来展示如果不做优化会有N1查询问题。正确做法是使用Django ORM的select_related和prefetch_related# 订单列表select_related 一次性join出关联的用户信息 orders Order.objects.filter(userrequest.user).select_related(user).order_by(-created_at) # 订单详情prefetch_related 一次性查出关联的订单项 order Order.objects.filter(idorder_id).prefetch_related(order_items).first()select_related适用于一对一和多对一关系它通过JOIN查询把关联数据一次性取出来prefetch_related适用于多对多和一对多关系它通过额外的查询把关联数据一次性全部取出来。如果不用这两个优化你在模板里循环展示订单项时每显示一条都要发一次SQL查询100条订单就要查101次数据库页面加载速度会非常慢。这种性能细节在答辩时如果被老师问起来你能答出所以然来绝对是加分项。3.4 Admin管理后台的定制Admin后台是Django给了毕业设计的大礼包一定要善用。我的做法是在各App的admin.py里自定义列表展示字段让后台管理变得直观好用# product/admin.py from django.contrib import admin from .models import Product, Category admin.register(Product) class ProductAdmin(admin.ModelAdmin): # 列表页显示的字段 list_display [name, category, price, stock, sales, status, created_at] # 可搜索的字段 search_fields [name] # 右侧过滤器 list_filter [category, status] # 可编辑的字段避免误点进入编辑页 list_editable [price, stock, status] # 分页 list_per_page 20这里有个实用的小技巧list_editable里放的字段不能同时出现在list_display的第一个字段因为第一个字段默认是链接入口所以我通常在list_display第一位放name作为链接然后把price、stock、status这几个需要频繁修改的字段设为列表可直接编辑。这样管理员在后台列表页就能直接修改商品价格和库存不需要每次都进入编辑页面。4. 高频问题排查清单与避坑实录4.1 数据库迁移相关的问题我在开发过程中遇到的最初级的坑是修改模型后忘了执行迁移命令结果查询时报错no such column或者Admin后台打不开。Django的迁移机制是模型 - 生成迁移文件 - 应用到数据库三个步骤每次修改完模型都必须执行python manage.py makemigrations python manage.py migrate第一个命令是根据模型变化生成新的迁移文件第二个命令是把这些变更真正应用到数据库。如果你新增了字段但没迁移Django运行时会报OperationalError: no such column: product_product.created_at如果你忘了注册App就执行迁移系统会提示App product could not be found。这里还要提醒一个常见的坑如果你在模型里新增了一个字段且设置了default值或允许为空nullTrue、blankTruemakemigrations的时候Django会提示你选择设置默认值或退出这个交互式提示会让很多新手不知所措。正确做法是在命令行直接指定一次性的默认值python manage.py makemigrations # 出现提示时输入 1 然后回车再输入默认值例如 0最后再确认 python manage.py migrate如果你实在不想交互式输入也可以在模型字段里直接写好default0这样迁移过程就不会有交互提示了。4.2 静态文件和图片404问题产品图片加载不出来是开发阶段非常高频的问题。这里有两个层面要排查。开发阶段你需要确保settings.py里设置了正确的媒体文件路径参考前文配置并且在项目的urls.py里加上静态文件服务from django.conf import settings from django.conf.urls.static import static urlpatterns [ # ... 你的其他路由 ] # 只有DEBUG模式下才会由Django直接提供媒体文件服务 if settings.DEBUG: urlpatterns static(settings.MEDIA_URL, document_rootsettings.MEDIA_ROOT)如果你用的是Django 3.2及以上还需要在settings.py里加一个STATICFILES_DIRS配置否则自定义的静态文件可能找不到STATIC_URL /static/ STATICFILES_DIRS [BASE_DIR / static]图片上传之后访问不到90%的情况是上面这段static()没有加上或者MEDIA_ROOT和MEDIA_URL配反了。4.3 登录状态闪断与CSRF验证失败CSRF验证失败是Django新手最常见的报错之一现象是你提交表单时报CSRF verification failed. Request aborted.。这是因为Django出于安全考虑要求所有POST请求必须携带CSRF令牌。要解决这个问题你只需要在页面模板里的form标签内加上{% csrf_token %}这个模板标签会渲染一个隐藏的csrfmiddlewaretoken字段提交表单时Django会验证它。阿里P6级的说法是Django通过这个机制防止跨站请求伪造攻击就是防止第三方网站伪造你的身份提交有害请求。你自己开发时最容易犯的错误是写API接口或AJAX提交时忘了带上CSRF Token。用jQuery的.ajax或axios提交时需要从csrftokenCookie中读取Token并放到请求头里否则同样会报CSRF错误。4.4 时区时间差问题很多同学部署完项目之后发现订单时间显示和本地时间差了8个小时。这个问题出在settings.py里的时区配置上。Django默认使用UTC时间你需要在settings.py中改成TIME_ZONE Asia/Shanghai USE_TZ True如果设置了USE_TZ TrueDjango会在存入数据库时使用UTC时间展示时自动转换为TIME_ZONE指定的时区。如果你在代码里要用datetime.now()获取当前时间在有USE_TZ的情况下必须改用django.utils.timezone.now()或者timezone.localtime()来获取本地时间否则你拿到的时间跟数据库里的时间对不上。4.5 购物车与订单数量不一致的问题还有一类问题也很常见购物车里明明有商品下单时却提示加车为空或者订单生成后订单项比购物车里少。这类问题通常是你忘记在商品详情页把商品加入购物车时检查库存或者在修改购物车数量时没有同步校验。我的建议是加入购物车时就做一次完整校验商品是否存在、是否上架、库存是否充足。代码逻辑如下def add_to_cart(request, product_id): product get_object_or_404(Product, idproduct_id, statusTrue) quantity int(request.POST.get(quantity, 1)) # 校验库存 if quantity product.stock: # 库存不足返回提示 return redirect(/product/ str(product.id) /) # 检查购物车中是否已有该商品 cart_item, created CartItem.objects.get_or_create( userrequest.user, productproduct, defaults{quantity: quantity} ) if not created: # 如果购物车已有该商品数量累加但也不能超过库存 new_quantity cart_item.quantity quantity if new_quantity product.stock: new_quantity product.stock cart_item.quantity new_quantity cart_item.save() return redirect(/cart/)5. 项目部署与源码使用建议5.1 本地运行与打包拿到源码之后很多同学第一反应是双击python manage.py runserver结果报错一大片。我这里把标准的运行流程写清楚你照着做就不会出问题# 1. 解压源码包进入项目根目录包含 manage.py 文件的目录 # 2. 创建并激活虚拟环境强烈推荐 python -m venv venv venv\Scripts\activate # Windows source venv/bin/activate # Mac/Linux # 3. 安装依赖requirements.txt 里列出了所有第三方库 pip install -r requirements.txt # 4. 生成数据库 python manage.py migrate # 5. 创建管理员账号用于登录Admin后台 python manage.py createsuperuser # 6. 启动开发服务器 python manage.py runserver然后浏览器打开http://127.0.0.1:8000/就能看到系统首页了。Admin后台地址是http://127.0.0.1:8000/admin/用你刚创建的管理员账号登录即可。这里要注意Django的runserver只是开发服务器它不适合用于生产环境性能极低且没有并发处理能力。如果答辩时需要部署到服务器上给老师远程演示建议使用gunicornLinux或waitressWindows配合nginx做反向代理但这属于锦上添花绝大部分学校的毕业答辩只需要本地运行加屏幕演示就够了。5.2 给管理员的初始数据初始化系统刚迁移完数据库后你进后台会发现所有数据表都是空的没有任何分类和商品。为了方便答辩演示我建议你在后台先手动录入一些演示数据或者写一个初始化脚本python manage.py shell然后执行以下Python代码from product.models import Category, Product from django.contrib.auth.models import User # 创建分类 phone Category.objects.create(name手机数码) clothes Category.objects.create(name服装服饰) food Category.objects.create(name食品生鲜) # 创建商品 Product.objects.create( name小米14 Ultra 5G手机, categoryphone, price5999.00, stock50, statusTrue, sales120, description徕卡光学镜头骁龙8 Gen3旗舰平台2K超视感屏 ) Product.objects.create( name联想拯救者Y9000P, categoryphone, price8999.00, stock20, statusTrue, sales85, descriptionRTX4060显卡第13代酷睿i9处理器电竞屏 ) # 更多商品自行补充...商品图片字段是ImageField你可以通过Admin后台直接上传本地图片也可以写代码时用defaultproduct/default.jpg为产品指定默认图片把一张默认图放到media/product/目录下即可。5.3 源码结构讲解老师问你这几个文件时怎么答源码拿到手之后你至少要能说清楚以下这几个核心文件的作用manage.pyDjango项目的入口文件所有命令行操作都从这里进入order_system/settings.py项目的核心配置包括数据库、App注册、模板、静态文件等order_system/urls.py根路由文件把URL地址映射到对应的视图函数product/models.py产品相关的数据模型定义order/models.py订单相关的数据模型是整个系统最核心的部分order/views.py订单相关的业务逻辑包括下单、支付、取消等templates/所有HTML模板文件Django模板语言在这里发挥作用B站和CSDN上有很多讲Django项目源码的教程但如果你打算用这份源码去答辩我强烈建议你把核心代码自己抄一遍或者逐行理解一遍不要想着“我拿到源码就不管了”。因为你永远猜不到答辩老师会问你什么问题比如“订单状态字段是什么类型”“扣库存时并发怎么处理”“为什么订单项里要冗余商品名称和价格”。这几个问题我在上面的文章里都给出了答案你只要认真读过这篇文章回答起来就不会卡壳。6. 答辩演示脚本与加分技巧6.1 演示流程怎么安排最容易让老师看懂答辩现场经常出现一种尴尬情况同学演示了10分钟老师还是没看明白系统是干嘛的。问题就出在没有按业务流程来演示而是东点一下西点一下像无头苍蝇。我建议的演示流程是“讲故事式”的第一步先打开系统首页介绍我做的是一套产品订单管理系统主要解决线上商品展示、用户下单、订单管理的问题。第二步注册一个新账号或者用已有的演示账号登录告诉大家我现在是一个普通用户。然后从首页搜索商品、点击进入商品详情页把商品加入购物车再去看一眼购物车列表确认数量无误。第三步点击去结算下单生成订单此刻强调一下订单状态是待付款。然后演示支付刷新订单状态让它变成待发货。第四步切换到管理员身份演示时提前在浏览器开好另一个隐身窗口登录Admin后台说明我作为管理员可以对商品进行管理可以查看到新订单然后帮用户发货状态变成已发货。第五步切回用户视角演示用户看到订单状态变化点击确认收货订单完成。整个流程走下来老师对系统的印象会非常深刻因为业务闭环是完整的每个状态变化都看得清清楚楚。再结合前面的源码讲解至少能拿到一个不错的分数。6.2 答辩高频问题与回答参考我根据以往经验整理了7个最高频的问题你们可以提前准备Q1为什么选Django这个框架顺着前文的方法来回答Django是一个高度集成的Web框架它自带ORM、Admin后台、认证系统、表单处理机制可以让开发者把主要精力集中在业务逻辑上同时Django的MVT架构清晰非常适合这类管理系统的快速开发。Python的简洁语法也加快了开发效率。Q2订单状态为什么用数字而不是字符串方便存储和比较状态是可枚举的有限集合用数字加choices映射更规范同时数据库存储数字的空间开销更小查询效率更高。如果后续要加新状态只需在映射表里增加一项不需要修改数据库结构。Q3库存和订单的一致性怎么保证使用Django的transaction.atomic()开启数据库事务把订单创建和库存扣减放在一个事务里扣库存时使用F表达式加stock__gte条件做原子操作防止并发下超卖。Q4密码安全是怎么实现的Django自带的认证系统使用PBKDF2加盐哈希算法存储密码登录验证时调用authenticate方法完成密码比对不存储明文密码。Q5购物车数据存在哪里为什么我最终选择了存数据库这样用户退出登录后再次登录购物车数据依然存在同时数据库购物车可以很好地和订单系统集成下单时直接读取数据库里的加车数据生成订单。Q6如何防止用户绕过登录直接访问订单页面所有需要登录才能访问的视图函数都加上了login_required装饰器未登录用户会被重定向到登录页。同时Django中间件还会校验CSRF Token防止跨站请求伪造。Q7项目的扩展性怎么样目前的架构预留了扩展空间如果要增加支付模块可以在订单的pay_time和transaction_id字段上继续扩展对接第三方支付接口如果要增加商品评论功能可以新建一张评论表关联产品和用户如果要增加消息通知可以在订单状态变更时发送消息到用户的站内信表。6.3 原创性与定制化建议往年有很多同学的毕业论文会被评阅老师质疑雷同其实源于源码和论文整体相似度太高。所以拿到源码之后我强烈建议你做以下几件事来提升原创度第一改UI。Django模板的HTML和CSS样式是你可以自由改的随便找个开源UI框架比如Bootstrap或者Tailwind把页面重写一遍视觉效果就会完全不同。你不需要多精通前端就是用现成组件替换原有样式就行。第二加一个功能模块。比如我上面的系统里没有商品评论功能你可以加一个“产品评价”模块用户对买过的订单里每个商品写评价也可以加一个“数据统计”用图表展示销售趋势。新增一个模块在论文里很好写同时也代表你确实理解了代码结构。第三改数据库字段。比如给产品表加个brand品牌字段或者给订单表加个remark备注字段。字段级别的改动很安全但能有效提升差异性。7. 最后的经验之谈做完这个项目我最大的感受是毕业设计其实考验的不是技术难度而是工程组织和业务理解能力。产品订单管理系统这个题目之所以经典就是因为它把面向对象建模、数据一致性、用户交互、状态流转这些都串了起来让你在做一个完整系统的过程中把Web开发的核心能力补齐。我开发这套系统的过程中踩过的坑包括但不限于忘记迁移数据库导致字段找不到、下单时忘记开启事务导致脏数据、直接改product.stock导致并发库存不对、模板里忘了csrf_token导致表单提交失败、时区没配好导致时间差8小时。这些坑我在文章里全部记录了下来你照着避坑至少能省两到三天的调试时间。如果你拿到源码后卡在环境配置我建议你先看requirements.txt这个文件里写明了所有依赖库和版本号照着安装就不会报缺包数据库迁移和创建超级管理员的操作一定要做很多同学跳过这两步直接runserver结果打开网页一脸懵。最后再说一句源码里的代码结构我是按照企业级开发习惯组织的你如果能在论文里把每个模块的设计思路、表结构设计、核心算法描述清楚答辩通过率会很高。希望这篇分享能帮你们少走弯路。 基于Django的产品订单管理系统设计与实现全程解析
Django写毕业设计这件事说难不难说简单也真不简单。尤其是产品订单管理系统这种经典题目每年都有大量计算机相关专业的学生在选需求量巨大网上却很难找到一份真正能跑通、能讲清楚、能应付答辩的完整源码。我之前带过不少学弟学妹做类似项目自己也完整开发过这套基于Django的产品订单管理系统顺手把完整源码整理了出来编号28794。这篇文章不打算写成那种枯燥的课程设计报告而是想从一个实际开发者的角度把整个项目从选题思路、技术选型、功能设计、数据库建模、核心代码实现到部署运行、常见坑位排查、答辩准备一条线全部捋清楚。无论你是完全没接触过Django的小白还是已经有基础但卡在某个环节的老手这篇文章都能给你一张可以直接照着走的地图。1. 项目整体设计与选题思路拆解1.1 为什么毕业设计要选“产品订单管理系统”每到毕业季选题永远是第一道坎。很多同学在“图书管理系统”“学生管理系统”“网上商城”这些经典题目之间反复纠结但我个人强烈推荐产品订单管理系统。原因很简单这个题目业务逻辑清晰、功能边界明确、技术覆盖全面而且非常好演示。产品订单管理系统本质上就是一个轻量级的进销存核心模块它涉及到用户、商品、订单、订单详情这几个核心实体几乎串联起了Web开发的所有基础知识点。你需要做登录注册就会用到Django自带的认证系统你需要做商品列表和搜索就会接触到ORM查询和模板渲染你需要做下单流程就会涉及到事务处理、外键关联、状态字段的变更你需要做后台管理Django Admin直接给你省掉一大半体力活。这一个题目做完你基本就把Django的核心功能全部过了一遍答辩的时候无论老师从哪个角度问你都有东西可讲。而且这类系统的演示效果非常好。你可以在后台添加几个产品设置库存和价格然后从前台注册一个用户下单、支付、查看订单状态整个流程走下来逻辑自洽演示画面充实老师一眼就能看懂你做的是什么不需要过多的解释。1.2 技术选型为什么是Django而不是Flask或Spring Boot先说说技术栈的核心选择。产品订单管理系统可以用很多框架来做PHP可以用LaravelJava可以用Spring BootPython呢主流就是Django和Flask两个选择。Flask的优势是轻量灵活但正因为它太灵活对于毕业设计来说反而是一种负担。用户登录怎么做、表单验证怎么做、ORM用哪个、目录结构怎么组织一切都得自己来选自己来配。我见过太多用Flask写毕业设计的同学前期搭环境就花了两个星期最后代码风格千奇百怪自己都理不清。Django则完全相反。它是一个重框架把Web开发中绝大部分通用的东西都替你做好了。自带Admin后台、自带ORM、自带认证系统、自带表单处理、自带模板引擎甚至连分页、消息提示、CSRF防护这些细节都已经给你实现好了。你只需要关注业务逻辑本身把产品、订单这些核心模型设计好剩下的基础设施它全包了。用一个生活化的类比来说Flask像是给你一堆积木让你自己搭房子Django则是给你一套已经通水通电的毛坯房你只需要刷墙和买家具就行了。对于毕业设计这种以展示业务逻辑为主的场景Django明显是效率最高、容错率最低的选择。1.3 系统的功能模块划分整个产品订单管理系统我按照业务域拆分成三大模块用户端、管理端、数据层支撑。用户端面向普通注册用户包含注册登录、产品浏览、关键词搜索、产品详情查看、加入购物车、订单提交、订单支付模拟、个人订单历史查询、个人信息维护这些功能。这一部分是系统的主体答辩演示时绝大部分操作都在这里完成。管理端则是面向系统管理员的。我直接把Django自带的Admin后台改造扩展成了管理界面管理员可以在这里完成产品的新增上下架、库存调整、价格修改、订单状态审核、用户管理这些操作。使用Django Admin的好处是几乎零成本就能获得一个完整的管理后台而且它的UI是现成的你不用花时间写增删改查页面写代码的时间可以集中到业务流程上。数据层是整个系统的地基。产品表、用户表、订单表、订单项表、分类表共同构成了系统的数据核心。这里面的字段设计、关系设计是整篇代码里最考验基本功的部分也是答辩时最容易深挖的区域。2. 系统核心功能详解与数据库设计2.1 用户认证与权限控制是怎么做的用户部分我直接基于Django内置的User模型做了扩展而不是自己新建一张用户表。这个选择非常重要因为django.contrib.auth已经实现了注册、登录、密码哈希、Session管理、登录状态校验这一整套机制你不需要重复造轮子。具体做法是创建一个UserProfile模型通过OneToOneField和一系统自带的User关联用来保存手机号、收货地址、注册时间等额外信息。注意这里的关联关系只能用OneToOneField而不能用ForeignKey原因是一对一关系保证了一个User只能对应一条扩展信息用外键的话可能会出现一个用户多条扩展记录的数据脏状态。权限控制方面普通用户和管理员的区别我并没有做太复杂的RBAC权限表而是通过Django自带的is_staff字段来判断。用户端页面里所有需要登录才能访问的视图函数都加上了login_required装饰器这样未登录用户访问订单页面时会被自动重定向到登录页。Admin后台本身只对is_staffTrue的用户开放这就实现了用户和管理员在入口处的天然隔离。这里还要提到一个很多新手会踩的坑密码存储。如果你自己写登录逻辑绝对不要用MD5这种散列算法直接存密码一定要用Django默认的PBKDF2算法。Django的create_user方法会自动帮你做密码哈希和加盐处理你要是手贱用User.objects.create(passwordxxx)这种方式去创建用户密码就会变成明文存进去不仅不安全而且登录时永远验证不过因为Django的authenticate方法会对输入的密码再做一次哈希去比对。2.2 产品与分类的数据建模产品表是整个系统的核心表字段设计直接决定了后面功能的开发难度。我的产品模型包含以下关键字段name产品名称CharField最大长度100加db_indexTrue索引因为产品搜索是按名称模糊匹配的category外键关联分类表on_deletemodels.CASCADE分类删除时该分类下的产品一并删除price价格字段这里必须用DecimalField而不是FloatField因为浮点数在计算机中无法精确表示会出现0.10.2不等于0.3的问题订单金额计算是敏感数据绝不能有精度损失stock库存数量IntegerField默认0image产品图片我用的是ImageField需要配置MEDIA_ROOT和MEDIA_URLstatus上下架状态BooleanField用True/False表示上架/下架sales销量字段每次下单成功后累加用于排序展示description产品描述TextFieldcreated_at创建时间DateTimeField(auto_now_addTrue)分类表比较简单就是name和parent自关联外键实现了一级分类和二级分类的树形结构。不过说实话如果你们毕设要求不高分类做成一个扁平结构也完全够用不必过度设计。这里有个非常关键的细节price字段我用了max_digits10, decimal_places2很多新手在定义价格时喜欢用FloatField或者IntegerField前者精度丢失后者无法表示小数价格都会在后续计算时出问题。2.3 订单与订单项的设计为什么会话级的购物车不够用订单部分是这个系统的重头戏也是整个设计中最能体现专业度的地方。我用了两张表来完成订单数据存储主表Order和从表OrderItem。Order表字段设计如下order_no订单编号CharField用时间戳加随机数的方式生成保证唯一性展示给用户看的是一个像20240614153000123456这样的编号user外键关联用户on_deletemodels.CASCADEtotal_amount订单总金额DecimalFieldstatus订单状态IntegerField加了choices参数用数字标识状态是我特别推荐的做法。状态定义如下状态值含义说明0待付款订单已创建但未完成支付1待发货已付款等待管理员处理2已发货管理员已发货3已完成用户确认收货流程完结4已取消用户取消或超时未付款自动取消用数字存储状态而不是字符串在后续写filter(status1)这种查询时会非常方便而且如果要扩展新状态只需要增加一个数字映射就够了不需要改表结构。OrderItem表则保存订单快照信息关联到Order主表的外键、关联产品的ID、购买时的产品名称、购买时的单价、购买数量。为什么要多存一份“购买时的产品名称和单价”因为商品信息是易变的今天你下单时商品卖100块明天管理员改成120块你查看历史订单时如果直接去关联产品表读价格读到的是改了之后的价格这显然不符合业务逻辑。所以订单项里必须冗余一份商品名称和单价的快照这才是正规电商系统的做法。购物车我一开始用的是Session存列表后来发现Session存购物车有问题用户退出登录或者清理浏览器缓存购物车就空了。后来我改成了数据库存储新建了一个CartItem模型这样购物车数据是持久的用户体验好得多。但如果你为了省事Session方案也不是不能交差具体情况看你们老师对功能完整度的要求。3. 实操过程从环境搭建到核心代码实现3.1 开发环境准备与项目初始化先说环境。我本机用的是Python 3.10Django版本用的是3.2 LTS为什么不用Django 4.x或者5.x因为3.2是长期支持版本稳定性最好网上遇到的坑基本都能搜到解决方案。你如果用最新的Django 5.0很多第三方库和教程还没有完全跟上遇到环境兼容问题不容易排查。反正毕业设计用的技术栈只要confirm能够完成功能即可没必要盲目追求新版本。创建项目的完整命令流程如下# 创建虚拟环境这个习惯一定要养成 python -m venv venv # 激活虚拟环境Windows venv\Scripts\activate # 激活虚拟环境Mac/Linux source venv/bin/activate # 安装Django pip install django3.2 # 创建项目 django-admin startproject order_system # 进入项目目录 cd order_system # 创建应用 python manage.py startapp product python manage.py startapp order python manage.py startapp user这里我强烈建议按照业务边界拆分App不要把所有代码都堆在一个views.py里。产品相关的放product应用订单相关的放order应用用户相关的放user应用。这样后期维护代码时定位问题非常快也符合Django的哲学。创建完App之后记得去settings.py里的INSTALLED_APPS注册这三个应用然后配置数据库、静态文件、媒体文件这几项# settings.py 核心配置 INSTALLED_APPS [ django.contrib.admin, django.contrib.auth, django.contrib.contenttypes, django.contrib.sessions, django.contrib.messages, django.contrib.staticfiles, product, order, user, ] # 这里我用的是SQLite毕业设计完全够用 DATABASES { default: { ENGINE: django.db.backends.sqlite3, NAME: BASE_DIR / db.sqlite3, } } # 媒体文件产品图片配置 MEDIA_URL /media/ MEDIA_ROOT BASE_DIR / media # 登录跳转配置 LOGIN_URL /user/login/ LOGIN_REDIRECT_URL /3.2 核心代码实现产品列表到下单全链路产品列表页的逻辑非常简单就是一个普通的ORM查询加分页。关键代码在product/views.pyfrom django.core.paginator import Paginator from django.shortcuts import render from .models import Product, Category def product_list(request): # 获取当前选中的分类ID默认是None category_id request.GET.get(category) keyword request.GET.get(keyword, ).strip() products Product.objects.filter(statusTrue) # 只显示上架商品 # 分类筛选 if category_id: products products.filter(category_idcategory_id) # 关键词搜索 if keyword: products products.filter(name__icontainskeyword) # 按销量排序让卖得好的排前面 products products.order_by(-sales) # 分页每页12个商品 paginator Paginator(products, 12) page_number request.GET.get(page) page_obj paginator.get_page(page_number) categories Category.objects.all() return render(request, product_list.html, { page_obj: page_obj, categories: categories, current_category: category_id, keyword: keyword, })这里需要注意name__icontains这个写法i表示忽略大小写contains表示模糊查询翻译成SQL就是WHERE name LIKE %keyword%。下单流程是整个系统最核心的部分也是最容易出bug的地方。我建议你按照我下面这个顺序来写# order/views.py 下单逻辑 from django.shortcuts import get_object_or_404, redirect from django.contrib.auth.decorators import login_required from django.db import transaction from django.utils import timezone from .models import Order, OrderItem, CartItem from product.models import Product import random login_required def create_order(request): if request.method POST: # 读取当前用户的购物车 cart_items CartItem.objects.filter(userrequest.user) # 判断购物车是否为空 if not cart_items.exists(): return redirect(/cart/) # 计算总价 total_amount sum([item.product.price * item.quantity for item in cart_items]) # 创建订单主表记录 with transaction.atomic(): order Order.objects.create( order_nogenerate_order_no(), userrequest.user, total_amounttotal_amount, status0, # 待付款 ) # 创建订单项并更新库存 for item in cart_items: product item.product # 并发场景下防止超卖使用F表达式原子更新 from django.db.models import F result Product.objects.filter( idproduct.id, stock__gteitem.quantity ).update(stockF(stock) - item.quantity) # 如果库存不够抛出异常回滚整个事务 if result 0: raise Exception(f商品 {product.name} 库存不足) OrderItem.objects.create( orderorder, productproduct, product_nameproduct.name, priceproduct.price, quantityitem.quantity, ) # 清空购物车 cart_items.delete() return redirect(/order/success/ str(order.id) /) return redirect(/cart/)这个下单逻辑里有几个非常讲究的设计点我详细解释一下。第一我使用了transaction.atomic()包裹整个创建订单的过程。这意味着订单主表、订单项、库存扣减要么全部成功要么全部失败。想象一个场景用户下单创建了订单但扣库存时发现库存不够了如果你没有事务订单表里就会残留一条错误订单记录库存没有扣成功但钱已经“下”出去了这显然是数据不一致的严重bug。第二扣库存我用了F表达式。很多新手是这样写扣库存的product.stock - item.quantity product.save()这种写法在并发场景下会出大问题。两个用户同时下单A用户读到库存是10B用户也读到库存是10A扣减后保存为8B扣减后保存为8最终库存就错了。F表达式则是在数据库层面执行原子操作等价于UPDATE product SET stock stock - 1 WHERE id 1 AND stock 1这样就不会出现超卖。第三在Product.objects.filter(idproduct.id, stock__gteitem.quantity).update()中stock__gteitem.quantity这个条件保证了库存充足才允许扣减如果库存不够update返回0我直接抛异常让事务回滚完成了超卖保护。3.3 订单状态流转与列表展示订单状态流转就是在用户和管理员操作时更新status字段。用户端可以执行的操作是付款把状态从0改成1、取消把状态从0改成4、确认收货把状态从2改成3。管理端可以执行的操作是发货把状态从1改成2。这个状态机其实非常简单但要注意在视图函数里加状态校验防止用户跳过中间状态乱改login_required def pay_order(request, order_id): order get_object_or_404(Order, idorder_id, userrequest.user) # 只有待付款状态的订单才能支付 if order.status 0: order.status 1 order.pay_time timezone.now() order.save() # 这里模拟支付流程实际项目会接入第三方支付接口 return redirect(/order/detail/ str(order.id) /)有人可能会觉得奇怪支付这么重要的环节怎么会“模拟”这里需要说明一下毕业设计里接入真实的微信支付或支付宝支付需要企业资质和备案域名学生个人是没有办法申请到的。所以绝大多数毕设都是做支付模拟即点击付款按钮直接改变订单状态为已支付然后在答辩时说明“实际项目中这里会替换为调用支付网关”。如果老师要求更好看的效果可以在付款页面做个二维码图片的展示、支付倒计时之类的界面效果但底层逻辑还是状态更新因为在沙箱环境里调通真实的支付接口相对耗时投入产出比不高。订单列表页要特别注意查询性能。因为订单表要和OrderItem关联查询出来展示如果不做优化会有N1查询问题。正确做法是使用Django ORM的select_related和prefetch_related# 订单列表select_related 一次性join出关联的用户信息 orders Order.objects.filter(userrequest.user).select_related(user).order_by(-created_at) # 订单详情prefetch_related 一次性查出关联的订单项 order Order.objects.filter(idorder_id).prefetch_related(order_items).first()select_related适用于一对一和多对一关系它通过JOIN查询把关联数据一次性取出来prefetch_related适用于多对多和一对多关系它通过额外的查询把关联数据一次性全部取出来。如果不用这两个优化你在模板里循环展示订单项时每显示一条都要发一次SQL查询100条订单就要查101次数据库页面加载速度会非常慢。这种性能细节在答辩时如果被老师问起来你能答出所以然来绝对是加分项。3.4 Admin管理后台的定制Admin后台是Django给了毕业设计的大礼包一定要善用。我的做法是在各App的admin.py里自定义列表展示字段让后台管理变得直观好用# product/admin.py from django.contrib import admin from .models import Product, Category admin.register(Product) class ProductAdmin(admin.ModelAdmin): # 列表页显示的字段 list_display [name, category, price, stock, sales, status, created_at] # 可搜索的字段 search_fields [name] # 右侧过滤器 list_filter [category, status] # 可编辑的字段避免误点进入编辑页 list_editable [price, stock, status] # 分页 list_per_page 20这里有个实用的小技巧list_editable里放的字段不能同时出现在list_display的第一个字段因为第一个字段默认是链接入口所以我通常在list_display第一位放name作为链接然后把price、stock、status这几个需要频繁修改的字段设为列表可直接编辑。这样管理员在后台列表页就能直接修改商品价格和库存不需要每次都进入编辑页面。4. 高频问题排查清单与避坑实录4.1 数据库迁移相关的问题我在开发过程中遇到的最初级的坑是修改模型后忘了执行迁移命令结果查询时报错no such column或者Admin后台打不开。Django的迁移机制是模型 - 生成迁移文件 - 应用到数据库三个步骤每次修改完模型都必须执行python manage.py makemigrations python manage.py migrate第一个命令是根据模型变化生成新的迁移文件第二个命令是把这些变更真正应用到数据库。如果你新增了字段但没迁移Django运行时会报OperationalError: no such column: product_product.created_at如果你忘了注册App就执行迁移系统会提示App product could not be found。这里还要提醒一个常见的坑如果你在模型里新增了一个字段且设置了default值或允许为空nullTrue、blankTruemakemigrations的时候Django会提示你选择设置默认值或退出这个交互式提示会让很多新手不知所措。正确做法是在命令行直接指定一次性的默认值python manage.py makemigrations # 出现提示时输入 1 然后回车再输入默认值例如 0最后再确认 python manage.py migrate如果你实在不想交互式输入也可以在模型字段里直接写好default0这样迁移过程就不会有交互提示了。4.2 静态文件和图片404问题产品图片加载不出来是开发阶段非常高频的问题。这里有两个层面要排查。开发阶段你需要确保settings.py里设置了正确的媒体文件路径参考前文配置并且在项目的urls.py里加上静态文件服务from django.conf import settings from django.conf.urls.static import static urlpatterns [ # ... 你的其他路由 ] # 只有DEBUG模式下才会由Django直接提供媒体文件服务 if settings.DEBUG: urlpatterns static(settings.MEDIA_URL, document_rootsettings.MEDIA_ROOT)如果你用的是Django 3.2及以上还需要在settings.py里加一个STATICFILES_DIRS配置否则自定义的静态文件可能找不到STATIC_URL /static/ STATICFILES_DIRS [BASE_DIR / static]图片上传之后访问不到90%的情况是上面这段static()没有加上或者MEDIA_ROOT和MEDIA_URL配反了。4.3 登录状态闪断与CSRF验证失败CSRF验证失败是Django新手最常见的报错之一现象是你提交表单时报CSRF verification failed. Request aborted.。这是因为Django出于安全考虑要求所有POST请求必须携带CSRF令牌。要解决这个问题你只需要在页面模板里的form标签内加上{% csrf_token %}这个模板标签会渲染一个隐藏的csrfmiddlewaretoken字段提交表单时Django会验证它。阿里P6级的说法是Django通过这个机制防止跨站请求伪造攻击就是防止第三方网站伪造你的身份提交有害请求。你自己开发时最容易犯的错误是写API接口或AJAX提交时忘了带上CSRF Token。用jQuery的.ajax或axios提交时需要从csrftokenCookie中读取Token并放到请求头里否则同样会报CSRF错误。4.4 时区时间差问题很多同学部署完项目之后发现订单时间显示和本地时间差了8个小时。这个问题出在settings.py里的时区配置上。Django默认使用UTC时间你需要在settings.py中改成TIME_ZONE Asia/Shanghai USE_TZ True如果设置了USE_TZ TrueDjango会在存入数据库时使用UTC时间展示时自动转换为TIME_ZONE指定的时区。如果你在代码里要用datetime.now()获取当前时间在有USE_TZ的情况下必须改用django.utils.timezone.now()或者timezone.localtime()来获取本地时间否则你拿到的时间跟数据库里的时间对不上。4.5 购物车与订单数量不一致的问题还有一类问题也很常见购物车里明明有商品下单时却提示加车为空或者订单生成后订单项比购物车里少。这类问题通常是你忘记在商品详情页把商品加入购物车时检查库存或者在修改购物车数量时没有同步校验。我的建议是加入购物车时就做一次完整校验商品是否存在、是否上架、库存是否充足。代码逻辑如下def add_to_cart(request, product_id): product get_object_or_404(Product, idproduct_id, statusTrue) quantity int(request.POST.get(quantity, 1)) # 校验库存 if quantity product.stock: # 库存不足返回提示 return redirect(/product/ str(product.id) /) # 检查购物车中是否已有该商品 cart_item, created CartItem.objects.get_or_create( userrequest.user, productproduct, defaults{quantity: quantity} ) if not created: # 如果购物车已有该商品数量累加但也不能超过库存 new_quantity cart_item.quantity quantity if new_quantity product.stock: new_quantity product.stock cart_item.quantity new_quantity cart_item.save() return redirect(/cart/)5. 项目部署与源码使用建议5.1 本地运行与打包拿到源码之后很多同学第一反应是双击python manage.py runserver结果报错一大片。我这里把标准的运行流程写清楚你照着做就不会出问题# 1. 解压源码包进入项目根目录包含 manage.py 文件的目录 # 2. 创建并激活虚拟环境强烈推荐 python -m venv venv venv\Scripts\activate # Windows source venv/bin/activate # Mac/Linux # 3. 安装依赖requirements.txt 里列出了所有第三方库 pip install -r requirements.txt # 4. 生成数据库 python manage.py migrate # 5. 创建管理员账号用于登录Admin后台 python manage.py createsuperuser # 6. 启动开发服务器 python manage.py runserver然后浏览器打开http://127.0.0.1:8000/就能看到系统首页了。Admin后台地址是http://127.0.0.1:8000/admin/用你刚创建的管理员账号登录即可。这里要注意Django的runserver只是开发服务器它不适合用于生产环境性能极低且没有并发处理能力。如果答辩时需要部署到服务器上给老师远程演示建议使用gunicornLinux或waitressWindows配合nginx做反向代理但这属于锦上添花绝大部分学校的毕业答辩只需要本地运行加屏幕演示就够了。5.2 给管理员的初始数据初始化系统刚迁移完数据库后你进后台会发现所有数据表都是空的没有任何分类和商品。为了方便答辩演示我建议你在后台先手动录入一些演示数据或者写一个初始化脚本python manage.py shell然后执行以下Python代码from product.models import Category, Product from django.contrib.auth.models import User # 创建分类 phone Category.objects.create(name手机数码) clothes Category.objects.create(name服装服饰) food Category.objects.create(name食品生鲜) # 创建商品 Product.objects.create( name小米14 Ultra 5G手机, categoryphone, price5999.00, stock50, statusTrue, sales120, description徕卡光学镜头骁龙8 Gen3旗舰平台2K超视感屏 ) Product.objects.create( name联想拯救者Y9000P, categoryphone, price8999.00, stock20, statusTrue, sales85, descriptionRTX4060显卡第13代酷睿i9处理器电竞屏 ) # 更多商品自行补充...商品图片字段是ImageField你可以通过Admin后台直接上传本地图片也可以写代码时用defaultproduct/default.jpg为产品指定默认图片把一张默认图放到media/product/目录下即可。5.3 源码结构讲解老师问你这几个文件时怎么答源码拿到手之后你至少要能说清楚以下这几个核心文件的作用manage.pyDjango项目的入口文件所有命令行操作都从这里进入order_system/settings.py项目的核心配置包括数据库、App注册、模板、静态文件等order_system/urls.py根路由文件把URL地址映射到对应的视图函数product/models.py产品相关的数据模型定义order/models.py订单相关的数据模型是整个系统最核心的部分order/views.py订单相关的业务逻辑包括下单、支付、取消等templates/所有HTML模板文件Django模板语言在这里发挥作用B站和CSDN上有很多讲Django项目源码的教程但如果你打算用这份源码去答辩我强烈建议你把核心代码自己抄一遍或者逐行理解一遍不要想着“我拿到源码就不管了”。因为你永远猜不到答辩老师会问你什么问题比如“订单状态字段是什么类型”“扣库存时并发怎么处理”“为什么订单项里要冗余商品名称和价格”。这几个问题我在上面的文章里都给出了答案你只要认真读过这篇文章回答起来就不会卡壳。6. 答辩演示脚本与加分技巧6.1 演示流程怎么安排最容易让老师看懂答辩现场经常出现一种尴尬情况同学演示了10分钟老师还是没看明白系统是干嘛的。问题就出在没有按业务流程来演示而是东点一下西点一下像无头苍蝇。我建议的演示流程是“讲故事式”的第一步先打开系统首页介绍我做的是一套产品订单管理系统主要解决线上商品展示、用户下单、订单管理的问题。第二步注册一个新账号或者用已有的演示账号登录告诉大家我现在是一个普通用户。然后从首页搜索商品、点击进入商品详情页把商品加入购物车再去看一眼购物车列表确认数量无误。第三步点击去结算下单生成订单此刻强调一下订单状态是待付款。然后演示支付刷新订单状态让它变成待发货。第四步切换到管理员身份演示时提前在浏览器开好另一个隐身窗口登录Admin后台说明我作为管理员可以对商品进行管理可以查看到新订单然后帮用户发货状态变成已发货。第五步切回用户视角演示用户看到订单状态变化点击确认收货订单完成。整个流程走下来老师对系统的印象会非常深刻因为业务闭环是完整的每个状态变化都看得清清楚楚。再结合前面的源码讲解至少能拿到一个不错的分数。6.2 答辩高频问题与回答参考我根据以往经验整理了7个最高频的问题你们可以提前准备Q1为什么选Django这个框架顺着前文的方法来回答Django是一个高度集成的Web框架它自带ORM、Admin后台、认证系统、表单处理机制可以让开发者把主要精力集中在业务逻辑上同时Django的MVT架构清晰非常适合这类管理系统的快速开发。Python的简洁语法也加快了开发效率。Q2订单状态为什么用数字而不是字符串方便存储和比较状态是可枚举的有限集合用数字加choices映射更规范同时数据库存储数字的空间开销更小查询效率更高。如果后续要加新状态只需在映射表里增加一项不需要修改数据库结构。Q3库存和订单的一致性怎么保证使用Django的transaction.atomic()开启数据库事务把订单创建和库存扣减放在一个事务里扣库存时使用F表达式加stock__gte条件做原子操作防止并发下超卖。Q4密码安全是怎么实现的Django自带的认证系统使用PBKDF2加盐哈希算法存储密码登录验证时调用authenticate方法完成密码比对不存储明文密码。Q5购物车数据存在哪里为什么我最终选择了存数据库这样用户退出登录后再次登录购物车数据依然存在同时数据库购物车可以很好地和订单系统集成下单时直接读取数据库里的加车数据生成订单。Q6如何防止用户绕过登录直接访问订单页面所有需要登录才能访问的视图函数都加上了login_required装饰器未登录用户会被重定向到登录页。同时Django中间件还会校验CSRF Token防止跨站请求伪造。Q7项目的扩展性怎么样目前的架构预留了扩展空间如果要增加支付模块可以在订单的pay_time和transaction_id字段上继续扩展对接第三方支付接口如果要增加商品评论功能可以新建一张评论表关联产品和用户如果要增加消息通知可以在订单状态变更时发送消息到用户的站内信表。6.3 原创性与定制化建议往年有很多同学的毕业论文会被评阅老师质疑雷同其实源于源码和论文整体相似度太高。所以拿到源码之后我强烈建议你做以下几件事来提升原创度第一改UI。Django模板的HTML和CSS样式是你可以自由改的随便找个开源UI框架比如Bootstrap或者Tailwind把页面重写一遍视觉效果就会完全不同。你不需要多精通前端就是用现成组件替换原有样式就行。第二加一个功能模块。比如我上面的系统里没有商品评论功能你可以加一个“产品评价”模块用户对买过的订单里每个商品写评价也可以加一个“数据统计”用图表展示销售趋势。新增一个模块在论文里很好写同时也代表你确实理解了代码结构。第三改数据库字段。比如给产品表加个brand品牌字段或者给订单表加个remark备注字段。字段级别的改动很安全但能有效提升差异性。7. 最后的经验之谈做完这个项目我最大的感受是毕业设计其实考验的不是技术难度而是工程组织和业务理解能力。产品订单管理系统这个题目之所以经典就是因为它把面向对象建模、数据一致性、用户交互、状态流转这些都串了起来让你在做一个完整系统的过程中把Web开发的核心能力补齐。我开发这套系统的过程中踩过的坑包括但不限于忘记迁移数据库导致字段找不到、下单时忘记开启事务导致脏数据、直接改product.stock导致并发库存不对、模板里忘了csrf_token导致表单提交失败、时区没配好导致时间差8小时。这些坑我在文章里全部记录了下来你照着避坑至少能省两到三天的调试时间。如果你拿到源码后卡在环境配置我建议你先看requirements.txt这个文件里写明了所有依赖库和版本号照着安装就不会报缺包数据库迁移和创建超级管理员的操作一定要做很多同学跳过这两步直接runserver结果打开网页一脸懵。最后再说一句源码里的代码结构我是按照企业级开发习惯组织的你如果能在论文里把每个模块的设计思路、表结构设计、核心算法描述清楚答辩通过率会很高。希望这篇分享能帮你们少走弯路。