企业官网建设流程全解析

这两年计算机毕设的选题风向其实很明确：要么蹭AI，要么拼业务完整度。

蹭AI的翻车率其实不低，模型调不好、显卡不够、答辩时候现场演示翻车，场面相当难看。反而是那种业务逻辑清晰、模块扎实、技术栈经典的传统Web系统，更容易拿高分。今天分享的这套基于Django的家居全屋定制系统，就是典型的"业务完整度高+技术栈稳妥"的毕设项目，而且正好赶上了家居行业的数字化风口，在答辩时很容易讲出价值感。

我帮人改过不少毕设代码，也带过一些小朋友从头写完整项目，可以负责任地说：这个题目拿来做毕设，性价比非常高。一是Django的开发效率足够让一个人在三到四个月内交付完整系统；二是家居全屋定制这个业务场景包含用户端、管理端、方案管理、报价计算、订单流转、支付对接等多个模块，素材足够撑起一篇像样的毕业论文；三是它的业务逻辑既有一定复杂度（定制报价不是简单的价格乘数量），又不至于难到无法驾驭，特别适合计算机科学与技术、软件工程、信息管理这类专业的同学。

这篇博文我会把这套系统的设计与实现从头到尾拆开讲，包括选型理由、业务建模、核心模块的代码逻辑、部署上线的坑、以及拿到源码之后怎么快速改成自己的项目，尽量说人话，让你能真正看懂而不是只停留在"能跑"的层面。

1. 为什么选"Django+全屋定制"这个组合做毕设

1.1 毕设选题的普遍误区与这套选题的优势

计算机毕设选题最常见的三个误区我见得太多：选题太空、选题太泛、选题太旧。

"基于Web的在线购物系统"这种题，做了十年了，答辩老师看一眼题目就知道你要写什么，除非UI和功能做得特别出彩，否则就是及格分。而"基于深度学习的花卉识别系统"这种题，听起来高级，但很多同学最后只是调了个现成模型，连训练集怎么划分都说不清楚，一问就露馅。

家居全屋定制系统卡在中间，位置刚刚好。

它的业务复杂度够：全屋定制不是普通电商那样"选商品→下单→付款"就结束了。它涉及到户型选择、空间分类（客厅/卧室/厨房/卫生间）、定制方案、材料品牌、面积或延米计算、报价规则、订单状态流转这些环节，业务层次是丰富的。

它的实现难度可控：这套系统本质上是经典的MVC架构Web应用，核心是CRUD加一点业务逻辑，任何学过数据库和Web开发的同学都能理解。即使你平时Django用得不多，花一两周熟悉MTV模式后也完全能上手。

更重要的是，它有一个很现实的答辩优势："家居全屋定制"本身就是一个真实的行业场景。答辩的时候老师问"你这个系统解决了什么问题"，你能很自然地讲清楚——传统定制家居的报价过程混乱、方案沟通成本高、订单状态不透明，系统用数字化方式把方案配置和报价计算规范化了。这比"我实现了一个电商网站"要高级得多。

1.2 Django给毕设项目带来的确定性

我经常跟人讲一个观点：毕设选技术栈，确定性和可交付性比炫技重要一百倍。

你选Spring Boot不是不行，但Java体系的配置和部署对很多同学来说是个隐形成本。你选Flask也行，但Flask太自由，什么都得自己拼，做到后面容易代码结构混乱。Django的好处是它把很多"决定"替你做好了：ORM不用你写SQL、Admin后台开箱即用、表单处理有Form组件、用户认证是内置的、模板系统现成的。

这个特性对毕设项目来说太重要了。因为你不是在写生产级系统，你是在有限时间内交付一个能演示、能答辩、代码能讲清楚的系统。Django的"约定优于配置"让你把精力放在业务逻辑上，而不是纠结路由该怎么写、数据库连接池怎么配。

另外，Django的ORM对学生特别友好。你定义好models.py，执行makemigrations和migrate，表就建好了。这比手写SQL + JDBC那套流程爽太多。答辩的时候你还可以诚实地说"我用ORM而不是裸SQL，是为了可维护性和安全性，避免SQL注入"，这本身就是个加分点。

1.3 家居全屋定制场景对毕设的加成

再往深说一层，为什么是"家居全屋定制"，而不是"零食商城"或者"二手交易平台"？

因为全屋定制这个场景天然包含了"参数化报价"这个功能点，而这是普通电商系统没有的。

普通电商的商品价格是固定的，加购物车只是乘法。但全屋定制的计价方式和计价单位是多样的：橱柜按"延米"算，衣柜按"投影面积"算，榻榻米按"展开面积"算，不同的板材品牌单价不同，可能还有套餐一口价。这就需要系统设计一个可扩展的报价引擎，而不是写死价格字段。

这个设计点在论文里可以单独开一个章节，在答辩的时候也是一个很好的"讲故事"素材。老师一听"报价规则可配置"，就知道你不是在做一个玩具项目，而是真的在思考业务怎么落地。

2. 全屋定制系统先理清业务模型，再谈代码

2.1 用户端看什么、管理端管什么

拿到一套毕设源码，第一件事永远不是跑起来看效果，而是理清业务角色和功能边界。这套系统的角色很清晰，就两类：普通用户（业主/访客）和超级管理员。

用户端承载的是一套完整的"浏览→咨询→下单"链路，核心功能我用表格理了一下：

这里特别说一下"问卷推荐"这个小设计，很多同类毕设里是没有的。它本质上是表单收集用户偏好（比如装修风格、预算区间、家庭成员数量），后端根据规则匹配数据库中已有的户型和套餐，按匹配度排序展示。功能不复杂，但非常像真实家居平台的交互体验，也让系统的智能化程度有了一点点可讲的资本。

管理端走的是Django自带Admin的深度改造加自定义页面。管理员要干的事包括：维护商品分类、录入和维护商品信息、接收用户提交的定制订单、更新订单处理进度、处理留言板中的用户反馈。这一大坨用Django Admin可以覆盖80%的需求，剩下20%涉及业务流程控制的，用自定义视图补齐。

2.2 商城表结构设计中的核心取舍

数据库设计是毕设的重头戏，也是最容易在答辩时被追问的部分。这套系统涉及的核心表大概有九张：分类表（Category）、商品表（Product）、用户表（User）、轮播图表（Banner）、用户留言表（Message）、预约信息表（Appointment）、订单表（Orders）、订单商品项表（OrderItem）、问卷调查表（Question）。

有几张表的设计我想单独拿出来说说，因为它们决定了你后期写代码的轻松程度。

第一张是Product表。这张表的字段除了常规的name、price、img、sales之外，还有一个cate_id外键和is_delete字段。cate_id用来关联分类，这在电商系统里是常识，不用多说。关键是is_delete这个字段，它做的是逻辑删除而不是物理删除。毕设项目里我很推荐这个做法，原因很简单：逻辑删除不会破坏订单对商品的引用，万一误删了还能从Admin里恢复，演示起来也安全——你不会希望在答辩现场不小心点了个删除按钮，把商品从数据库里连根拔掉。

第二张是User表。这张表复用的是Django自带的auth.User模型，再通过关联一个UserProfile（或者直接扩展字段）来存手机号、地址等额外信息。这里有一个新手很容易踩的坑，就是不要直接在原User表上改字段，而是用OneToOneField去关联扩展。因为Django内置的认证逻辑对User表的结构是有预期的，你乱加必填字段，注册、登录、Admin都可能连锁报错。

第三张是Orders表。这张表的设计我特别想强调一个字段：order_number（订单编号）。很多学生做订单表直接用自增id当订单号，这个问题平时用着没事，但你写论文画数据库ER图的时候会很尴尬，而且答辩老师往往会问"为什么不单独设一个订单号"。建议的做法是在订单创建时生成一个时间戳加随机数的字符串作为订单号，既好看，又能避免id泄露业务量。

至于Orders和OrderItem为什么分开两张表，这是标准的"主表-子表"结构。Orders存订单层面的信息（订单号、用户、总价、状态、创建时间），OrderItem存每一件定制的内容（关联哪个商品、单价、数量、小计）。这个结构不是谁拍脑袋定的，是因为同一个订单下会有多个不同的定制项，而且每个定制项的价格和数量都不一样，必须拆开存。

2.3 状态流转是订单模块的灵魂

订单状态这玩意儿，很多毕设只做了两个字段值：未支付/已支付。但在全屋定制这个场景里，订单从创建到完结的路径要长得多。

这套系统的订单状态链大致是这样的：已下单 → 已处理 → 已完成。更细一点，还可以拆成"待付款""待发货""已发货""已完成""已取消"。状态一般用一个整数字段存储，0代表待处理，1代表已处理，2代表已完成，配合一个status_display的方法动态显示中文状态。

我的建议是，如果你要在这个基础上扩展，不要零零散散用if判断去写状态逻辑，而是把状态的转移集中管理。比如在一个订单工具模块里定义好所有允许的"当前状态→下一状态"对照关系，这样代码更清楚，答辩时也更容易讲"订单流程控制"。

3. 核心代码模块拆解：样板间、方案与报价计算

3.1 商品（户型/套餐）管理模块是怎么组织起来的

先看目录结构，这是你拿到代码后第一个要搞懂的东西。Django项目的常规布局是：项目根目录下有一个project目录（settings.py所在的目录）和一个app目录（如果业务复杂，往往按功能拆分多个app）。这套系统的app组织并不复杂，核心业务基本集中在主应用里。

商品管理的底层是Category和Product两张表。Category是分类表，字段就两个——name和cate_sn（分类编号）。Product表承担了所有商品属性的存储：标题（title）、分类外键（cate）、价格（price）、单位（unit）、图片（img）、销量（sales）、简介（intro）、正文详情（content）、是否删除（is_delete）。注意这里有一个细节，字段用的是title而不是name，这在模板渲染里更友好，URL传参读起来也更顺。

商品的增删改查有两套入口。一套是Django Admin后台，适合管理员操作；另一套是写一个自定义的shop_list视图处理列表展示和筛选。列表页的逻辑其实就两大块：查询商品列表、判断页面上下文的登录状态。查询时按点击率/销量排序，过滤掉is_delete=True的商品，分页展示。每页数量一般设为8或12，配一个Paginator对象，模板里用for循环渲染卡片式商品块。

这里有一个生产实践中才见得到的坑，我单独提醒一句：图片字段img不要只存一个文件名，要保存完整的图片路径，比如product/20240401/xxx.jpg。因为项目部署的时候，资源文件可能放在媒体目录的不同层级，如果你只存了文件名，会很容易出现模板里图片加载不出来的问题。处理办法很笨但有效——在模板里拼静态文件路径，或者更省事一点，在保存的时候就把完整路径拼接好。

3.2 报价计算的实现逻辑，以及为什么不能只用float

问答式推荐模块的实现逻辑，核心是收集用户的五个问题答案：您的姓名？您的户型面积？预算区间？喜欢哪种风格？房屋类型？后端在question视图里接收POST提交，把答案存入Question表，再根据户型面积和预算区间从商品表里筛选出匹配的商品推荐给用户。

这一段的代码逻辑很直白：获取form数据 → 构建Question对象 → save()入库 → 根据面积和预算查商品 → 返回推荐上下文渲染模板。你要注意的反而是一个隐藏的技术细节：表单入库前要做字段校验。比如面积必须是数字、预算区间必须是下拉框里的合法选项。Django的forms.Form或者forms.ModelForm天然支持这些校验，你直接在form里定义字段类型就行，不要自己在视图里手写一堆if去判断。

再来看定制订单的报价逻辑。用户从购物车或者商品详情页发起定制，系统生成一个订单确认页，把用户之前选的商品、数量、款式配置汇总，动态计算出一个总价。

这里的报价计算绝对不能用float直接做加法乘法。我在带人改代码的时候，见过太多人栽在金额精度上：两个看起来应该相等的价格，用float算完差那么几分钱，而且还没法解释。涉及金额计算，请一律用decimal.Decimal。你在models里定义价格字段时也应该用DecimalField(max_digits=8, decimal_places=2)，这样从数据库到计算体系，全部走定点数，不会有精度漂移。

报价的另一个重点是单位。全屋定制的商品单位不是千篇一律的"件"，有的是"平方米"、有的是"延米"、"套"、"个"。价格字段是死的，但单位是活的。系统里统一用Product.unit字段存单位，前端模板里在价格后面直接渲染单位字符串，这样就做到了显示层的统一。

3.3 订单从创建到完成的流转控制

订单创建是整个系统里最复杂的一个视图，它要做的事情可不止是INSERT一条记录。

订单创建流程大致是：从商品详情页/购物车页POST过来 → 视图接收商品id、数量、用户id → 读取商品信息计算单价和小计 → 判断用户是否登录 → 未登录跳转登录页，已登录则渲染订单确认页 → 用户确认后提交，生成Orders主记录和OrderItem子记录 → 返回订单成功页。

这套流程里有两个容易忽略的点。

第一个是数量校验。用户在页面上填的定制数量理论上不能为负，不能为0，库存不足（如果设计库存的话）要提示。很多毕设代码图省事，直接request.POST.get("num")转int就去用了，前端改个参数就能塞个负数进来，虽然毕设不会被攻击，但答辩老师问到"你做了哪些安全处理"的时候，你能答出"做了数值合法性校验"总比支支吾吾强。

第二个是关联信息闭环。订单创建成功后，Orders表里的user字段关联登录用户id，OrderItem表里的order关联Orders主键，goods关联商品id。这三角关系只要断一环，订单列表页就算不出正确数据。错误排查的时候，优先看这三张表的关联字段是否都有值。

订单取消的逻辑也要单独理一下。取消操作一般只允许在未处理状态进行，一旦管理员已经开始处理订单，就不能取消了。代码实现上，就是先根据订单id取出订单，判断status是否等于0，等于0就置为已取消，否则提示"当前状态不可取消"。这个限制逻辑是业务性的，不是技术性的，但恰恰是这种细节最能体现你理解业务规则。答辩时你主动讲一句"我限制了取消订单的时机"，老师会觉得你考虑问题很周全。

3.4 用户认证与权限控制的坑，以及怎么绕过去

用户认证这块，Django自带auth系统做了90%的活，你只需要写两个视图：register和login。

register视图的逻辑是：接收用户名、密码、邮箱/手机号 → 用authenticate校验用户名是否已存在 → 存在则返回错误提示 → 不存在就调用User.objects.create_user创建用户 → 保存后重定向到登录页。注意一定要用create_user而不是create，create不会对密码做哈希处理，密码会以明文存进数据库，这要是被答辩老师发现了就是送命题。

login视图的逻辑是：POST过来 → authenticate(username=..., password=...)校验 → 校验通过就login(request, user)写session → 重定向到首页 → 校验失败就返回"用户名或密码错误"。这里要特别提醒一点，登录视图里不要自己写session的读写逻辑，Django已经封装好了，自己写反而容易弄丢session密钥，导致登录状态一闪即逝。

权限控制主要在模板层实现。首页和部分页面顶部会显示"登录/注册"或"欢迎你，xxx"，这个用Django模板自带的{% if request.user.is_authenticated %}即可。订单操作相关的视图，加上login_required装饰器，保证未登录用户无法访问。这些做法都很常规，但构成了一个完整的前后端权限闭环，答辩时值得单独提。

Admin后端的权限控制更简单——Django自带用户/用户组/权限三级体系，管理员可以被限制只能操作特定模型。你可以开启Admin，创建一个"运营人员"用户组，只给它商品和分类的管理权限，不给删除订单和修改用户信息的权限。这套RBAC（基于角色的访问控制）模型写在论文里也是个亮点。

4. 前端展示、后台管理与部署上线的实操细节

4.1 模板继承与静态资源的组织方式

前端这块，这套系统用的是Django模板 + Bootstrap，没有上前后端分离。很多人觉得不上Vue就Low了，其实完全不是。对于毕设系统，前后端不分离有它巨大的优势：你没有跨域问题、没有Token鉴权问题、没有单独的前端构建流程，数据直接通过模板上下文渲染到HTML里，逻辑什么时候读数据、什么时候展示数据，一眼就能看得懂。答辩的时候老师顺着模板往下追，也更容易理解整个数据流。

模板的组织方式，推荐用Django的模板继承机制。base.html放公共的导航栏、页头、页脚、JS引用，子模板通过{% extends "base.html" %}和{% block content %}来填充内容。这样你不用在每一个页面重复写那几百行的导航代码，后期想改导航菜单，改一个文件就全部生效了，维护成本低到可以忽略。

静态资源的存放位置也很关键。settings.py里要配置STATIC_URL和STATICFILES_DIRS，把项目里的static目录告诉Django。图片上传后的存储路径，通过MEDIA_URL和MEDIA_ROOT来处理。这两个配置不做好，本地跑起来图片全部404，相当影响演示效果。

4.2 Django Admin的定制化改造：不只是"能用"

Django Admin是毕设项目里的"外挂"，它让你几乎白拿一个后台管理系统，但你要是不改造它，就白白浪费了这个亮点。

改造可以从三个角度入手。

第一是list_display。默认Admin列表只显示模型的__str__返回值，非常单调。你在admin.ModelAdmin子类里配置list_display = ("title", "price", "sales", "cate")，列表页立刻变成一张规范的表格。再加一个list_filter和search_fields，管理员就能按分类筛选、按商品名搜索。

第二是fieldsets。表单页默认把所有字段竖着排一遍，看起来很乱。用fieldsets可以把字段分组，商品基础信息一组、价格库存一组、描述内容一组，后台看起来专业得多。

第三是inlines。Orders和OrderItem是主表和子表的关系，在Orders的Admin管理页里可以通过inlines直接内联编辑OrderItem，这样后台查一个订单就能同时看到它的全部定制明细，不用跳转来跳转去。

这些改造每个只要几行代码，但对后台体验的提升是肉眼可见的。论文里截两张改造前后对比图，能直接给你的系统设计加分。

4.3 本地跑通、局域网演示与上线发布的流程

毕设验收的时候，最尴尬的情况就是你带着笔记本去教室，结果数据库连不上或者静态文件全挂了。提前把部署流程捋顺，能省掉这种尴尬。

本地运行只需要三步：装好Python和Django → 在项目根目录执行python manage.py makemigrations和migrate建表 → python manage.py runserver启动开发服务器，浏览器访问127.0.0.1:8000。如果页面样式丢了，百分之九十是STATIC_URL配置问题；如果数据库表对不上，就检查一下有没有把别人数据库文件直接拷过来了，建议还是migrate重建。

如果想在答辩现场用手机或者另一台电脑访问，可以让runserver监听0.0.0.0:8000，然后局域网内用http://你的IP:8000访问。注意Windows防火墙可能拦截8000端口，临时关一下防火墙或者加一条入站规则就行。

正式部署上线，推荐用nginx + gunicorn + Django这套经典组合，数据库用SQLite就可以（毕设级别完全够用）。一个容易踩的坑是：DEBUG=False之后，Django不再帮你处理静态文件，必须用python manage.py collectstatic把静态文件收集到指定目录，再配nginx的alias指向它。这一步忘了，线上页面会白板，但本地一切正常，排查起来特别费时间。

5. 一套完整毕设源码的构成，以及"一条龙"到底包含什么

5.1 除了代码，你还会拿到哪些东西

标题里写了"程序+文档+代码讲解+一条龙定制"，这后面勾连着的是一个很多人没想明白的问题：毕设源码价值不在源码本身，而在于你拿到之后能多快地用起来。

程序部分，当然是完整的Django项目目录，包括所有的models、views、urls、templates、static、admin配置，以及数据库文件和详细的部署说明。有一个很实在的建议：拿到代码后第一件事不是去读每个文件，而是按README把项目跑起来，然后完整走一遍用户从注册到下单的流程。只有你亲手操作过每一个按钮，你才知道系统哪里是亮点、哪里可能被老师追问。

文档部分，一般包括开题报告（或者任务书）、毕业论文、答辩PPT这三个最重要的东西。论文的结构通常是：绪论 → 相关技术介绍 → 需求分析 → 系统设计 → 系统实现 → 系统测试 → 总结与展望。你可以把它当作"骨架+示例内容"，然后按自己的话改一遍，加一些你自己的理解和截图。千万不要直接交原封不动的版本，哪怕改个标题、换个措辞，风险都小很多。

代码讲解部分，通常是录制好的视频或者一对一的语音讲解，把项目的核心代码逐段讲清楚。这个的价值在于：答辩的时候老师问"这段代码什么意思"，你能用自己的话讲出来。只有真懂了，才扛得住追问。所以我一直建议，拿到讲解视频之后不要只收藏，找一个下午过一遍，把关键模块（比如订单创建、报价计算）的代码逻辑记在本子上。

一条龙定制就是售后了。比如你拿到源码之后，发现有个页面显示不对、想加一个新闻公告模块、想改系统名称或者Logo、或者论文排版需要调整，直接找作者做定制修改。这个对时间紧或者动手能力弱的同学是最实用的兜底方案。

5.2 拿到源码后，建议按照什么顺序吃透它

我自己拆过很多套毕设源码，总结了一个"五步走"的阅读路径，分享出来你可以参考。

第一步，先跑通系统。按README部署，注册一个账号，模拟管理员和用户两个角色各走一遍完整流程，记录下系统的所有页面和功能点，心里有个"功能清单"。

第二步，读数据库。打开数据库文件或者对着models.py，把每张表的字段用途梳理一遍，画一张ER图。你不需要画得多专业，但至少要知道哪张表和哪张表有关联。答辩时如果老师让你画表关系，你能在黑板上画个大概，这就是底气。

第三步，读核心业务流程的代码。从urls.py开始，找到订单创建那条链路对应的视图函数，一行行看下去，搞清楚每个变量、每个判断条件。不要全读，全读会累死，只读核心的。

第四步，读Admin配置。把admin.py里注册的每个模型和定制选项过一遍，想想为什么要这么配。

第五步，把代码和论文对应起来。论文里每个功能模块的截图，你都要找到对应的代码位置。这样答辩时你说"这个功能在光棍视图里实现，具体逻辑是xxx"，而不是"这个功能在那个系统里能实现"，效果完全不一样。

5.3 一条龙服务里你最容易忽略的实用内容

很多人以为"一条龙"就是代码能跑就行，其实这里面的信息差大得很。

源码包里除了Django项目代码，一般还包含以下实用内容：PyCharm的专业版设置说明、Python虚拟环境配置指引、图片素材包、以及演示用的账号密码（管理员账号admin / admin123之类）。这些基础素材看起来不起眼，实际上对你快速搭建演示环境非常有帮助。

特别多同学还会忽略的一点是：数据库里的初始数据。很多系统跑起来是空表，连个商品都没有，演示的时候先得手动录入一大堆数据，非常浪费时间。好的源码包会预置一批商品分类、商品数据和用户数据，跑起来首页就是饱满的，直接可以演示。你在验收源码的时候，一定要确认这一点，这是实战经验。

6. 我在做类似项目时踩过的坑，以及答辩前的最后准备

6.1 几个一定会遇到的工程化问题

做这个项目的过程里，有几个坑属于"不踩不足以谈人生"的级别，我提前给你排掉。

迁移（migration）层面的坑：Django的models改了字段之后，如果有人直接把修改后的数据库文件发给你，最容易出现migration不一致。遇到"Table XXX already exists"或者字段对不上的报错，别慌，把旧的数据库文件删掉再重新migrate，或者用python manage.py makemigrations --merge合并迁移文件。本地开发阶段，删库重来是最快的解决办法，但要确保你删的不是正式数据。

图片上传路径的坑：商品图片上传后，如果页面图片不显示，首要排查的是MEDIA_URL和模板里的src路径是否拼接正确。Django官方推荐在模板里用{{ product.img.url }}而不是自己拼路径，这样能和MEDIA_ROOT自动对齐。一个常见错误是src="/media/{{ product.img }}"，前面多写了斜杠或者丢了一层目录，导致路径变成绝对地址找不到文件。

时区和时间格式的坑：settings.py里的TIME_ZONE和USE_TZ如果不配置好，订单创建时间会跟本地时间差八个小时。毕设级别建议TIME_ZONE = 'Asia/Shanghai'、USE_TZ = False，简单粗暴不折腾。

还有一个小技巧：在开发阶段，尽量打开settings.py里的django-debug-toolbar（如果有的话）。它能直接显示每个页面执行了多少条SQL，哪些操作造成了N+1查询。答辩的时候你说"我优化了ORM查询，消除了N+1问题"——就这一句话，比很多空话描述都加分。

6.2 答辩之前，你至少要会答的八个问题

这几年的答辩现场，老师其实不会问特别偏的问题，翻来覆去就问那几个。我帮你整理了一份高频问题清单，每个都最好用两三句话说清楚。

系统用的什么框架，为什么选它？——Django，MTV架构，自带ORM和Admin后台，开发效率高，安全性好，自带防护SQL注入和XSS的机制。

数据库有几张表，关系是什么？——说清楚至少8张表，重点描述Orders和OrderItem的主外键关系，以及商品和分类的多对一关系。

订单状态是怎么流转的？——讲清楚"已下单→已处理→已完成"的判定条件和取消订单的限制逻辑。

报价是怎么计算的？——强调DecimalField防精度丢失，价格和数量从商品表读取，采用字段内计算模式。

用户权限怎么控制的？——前端的is_authenticated模板判断加上后端的login_required装饰器，Admin端用Django自带的RBAC模型。

商品图片存在哪里，为什么能显示？——讲MEDIA_ROOT存储、模板中用url属性渲染路径。

系统有哪些安全措施？——ORM防SQL注入、表单校验、密码哈希存储、登录状态用Django session。

系统的不足和可扩展方向？——可以答"当前是单体应用，后续可以拆分为前后端分离架构，引入Redis缓存热点商品数据"。注意，这个问题不要回避，人人都知道毕设有不足，坦诚讲出来反而加印象分。

6.3 最后再讲几句掏心窝的话

做毕设这件事，本质上是让你完整走一遍"需求分析→设计→编码→测试→交付"的流程。通过一套家装定制系统，你顺便把Django这一整套东西练熟了，以后不管是找后端开发的工作，还是想自己接点小项目，都有底气。

我个人在拆解和重构同类项目的过程中体会最深的一点是：源码的价值不取决于代码量，而取决于你能不能讲清楚"为什么这么设计"。能讲清楚的代码，哪怕只有几千行，也是你的系统；讲不清楚的代码，哪怕跑得再流畅，答辩现场也会露馅。

所以拿到任何源码，都建议先建一个自己的知识地图：哪些模块可以直接用，哪些模块需要改成自己的风格，哪些模块你要重点研究准备答辩。把这个功课做到位了，这套源码才算真正成为你的东西。

如果后面在跑通项目、改功能或者写论文的时候卡住了，欢迎在评论区把你的问题抛出来。我尽量把我知道的都讲清楚，帮你少走点弯路。