企业官网建设流程全解析

每年到这个时间点，总有不少同学在毕设选题上纠结。选电商系统吧，烂大街；选图书管理吧，答辩老师看一眼就没兴趣。而“家居全屋定制系统”这个方向，结合了当下家居行业数字化转型的热点，业务逻辑足够丰富，技术实现上又能覆盖Django框架的大部分核心知识点，属于一个“既有得聊，又好落地”的题目。

这篇博文就围绕这个毕设项目，从选题拆解、技术选型、数据库设计、核心功能实现，到实战过程中容易踩的坑，一次性讲清楚。内容偏实操向，写代码、讲原理、给配置，适合正在做同类项目的同学参考，也适合打算用Django做Web开发入门的读者收藏。

1. 项目定位：这套“家居全屋定制系统”到底在解决什么问题

1.1 全屋定制业务的真实链路与系统切入点

做系统之前，先得搞清楚业务是怎么跑的。全屋定制不像普通电商那样“看中就下单”，它的完整链路是：线上浏览产品案例 → 预约设计师 → 上门量尺 → 出设计方案 → 报价确认 → 签订合同 → 工厂生产 → 配送安装 → 售后回访。

这里面的核心痛点是信息断链。销售在微信里聊的报价，和设计师出的方案经常对不上；客户的订单进入生产环节后，进度靠人工打电话去问；管理者想统计某个月的订单量、各类板材的使用占比，只能翻Excel。系统要解决的，就是把这些割裂的环节放在同一个平台上，让用户看得到、设计师改得动、管理员管得住。

所以这套系统的切入点不是做一个花哨的展示网站，而是围绕“预约、量尺、方案、报价、订单、进度”这条业务主链做数字化闭环。对毕设来说，这个业务宽度刚好合适：既有C端的注册登录、产品浏览，又有B端的订单审核、派单管理、进度更新，比单纯做个商城有延展性。

1.2 三类用户角色决定了模块划分

系统里的用户至少分成三类：普通用户（业主）、设计师、平台管理员。角色的不同决定了功能模块的划分方式。

普通用户关注的是：浏览家居风格案例、查看产品详情、提交预约量尺申请、查看方案和报价、下单、追踪订单进度。

设计师关注的是：接收分配的量尺任务、录入量尺数据、上传设计方案、调整报价明细、更新订单状态。

管理员关注的是：管理用户、审核商品和案例内容、分配量尺订单给指定设计师、查看经营数据（订单量、销售额、各状态订单数量）。

角色之间不是完全隔离的。比如设计师更新了方案，用户端能实时看到状态变化；管理员分配了量尺任务，设计师后台就多出一条待办。这个“角色操作引发另一角色可见变化”的联动，正是整个系统业务逻辑的核心，也是答辩时最能展开讲的部分。

1.3 为什么全屋定制比普通商城更适合做毕设

我的看法是，普通电商系统已经被做烂了，很难做出差异化。而全屋定制系统天然带几个特殊点：

第一，业务链路长，从浏览到售后有完整生命周期，展示在论文里可以画业务流程图。第二，报价逻辑有深度，不是简单的“单价乘数量”，而是按投影面积、展开面积、材料等级、五金件数量等组合计算，这比普通商品加购物车有技术含量。第三，行业背景新，家居行业这几年在讲数字化、整装、拎包入住，选题不容易撞车，答辩老师也更容易认可这个方向的价值。

2. 技术选型拆解：为什么Django能把这类系统做得又快又稳

2.1 Django自带的东西比你想象的多

选Django，最大的理由不是“课上教了这个”，而是它自带的组件契合这类业务系统，能省掉很多重复造轮子的时间。

Django默认就带后台管理Admin，只需要在admin.py里注册模型，几分钟就能得到一个能对用户、商品、订单做增删改查的管理后台，作为系统的“内部管理端”完全够用。它自带认证系统，注册、登录、登出、密码修改、权限分组，几行配置就能跑起来。它还自带表单验证、CSRF防护、分页、消息提示，这些看起来不起眼，但都是业务系统离不开的“地基”。

这些能力叠加起来，意味着开发者的主要精力可以放在业务逻辑上，而不是去实现“用户怎么登录”“表单怎么校验”这些基础能力。对毕设来说，这直接决定了你还有时间改bug、写论文、做PPT。

2.2 Django ORM处理订单、方案、商品关系的天然优势

全屋定制系统里数据关系复杂，比如：一个订单包含多个商品明细，每个明细关联一个产品；一个量尺记录关联一个订单和一个设计师；一个方案里可能选中了多个产品品类。这种多对一、多对多的关系模型，用Django的ORM处理起来非常自然。

比如定义好了外键，查询某个订单关联的全部商品明细时，一行“订单对象.明细对象_set.all()”就能拿到；需要反查某个用户的所有订单，也是同样的简写。ORM在背后帮我们完成了SQL的生成和结果集的映射，只要模型设计合理，90%的业务查询不需要手写SQL。

更重要的是，Django的ORM支持事务，这对订单创建这类“必须保证一致性”的操作很关键。下单时可能存在头表数据（订单）和明细表数据（订单商品）要同时写入的情况，一个操作失败满盘回滚，避免出现“订单保存了但明细丢了”这种脏数据。这部分在后期调试和论文写作中都是加分项。

2.3 技术栈的补充建议：数据库和前端怎么搭配

Django默认使用SQLite，对毕设来说，如果你的项目数据量不大，本地开发直接用SQLite完全没问题，部署也简单，就是一个文件。但有几个注意点：SQLite对并发写操作的锁处理较弱，如果演示时多个用户同时提交订单，偶尔会出现“database is locked”的报错；另外有些字段类型和MySQL有细微差别，比如布尔值存储方式不同。

如果想让项目显得更“企业级”，我建议切换成MySQL，开发和生产保持一致。操作不复杂，安装pymysql，在项目的init.py里加两行补丁，然后修改settings.py里的数据库配置就行。前端方面，纯Django模板语法加Bootstrap是性价比最高的方案，不需要前后端分离，开发速度快；如果自己Vue比较熟，也可以选择Django提供API接口、前端用Vue渲染的方案，但工作量会大不少，答辩时间紧的话不建议冒险。

3. 数据库设计与核心模型：先想清楚数据怎么串起来

3.1 用户模型：扩展Django内置User还是直接重写

设计数据库的第一步就是处理用户。Django内置的User模型已经带了用户名、密码、邮箱、姓名等字段，而且和认证系统、Admin后台深度绑定，能用就不要自己重写。但内置User只有普通字段，我们需要区分“普通用户”和“设计师”，这时候有两种做法。

第一种，通过一对一关联扩展用户信息表，这种方式不动Django的User，只建一张profile表跟User做一对一外键关联，里面放手机号、用户类型、所属设计师等级等额外字段，查询时通过“user.profile”访问。

第二种，用Django的AbstractUser重写User模型，在settings里配置AUTH_USER_MODEL指向自定义模型，加一个user_type字段，登录注册逻辑也多走一套自定义认证。

考虑到毕设的演示场景和少踩坑原则，我更推荐一对一扩展方案。它既保留了Django认证系统的完整能力，又不需要在一开始就定义好全部用户字段，后续要加字段随时在profile表里加。

3.2 商品与方案模型：把“定制”变成可计算的对象

家居全屋定制的商品不是“一个柜子卖多少钱”，而是“柜子的投影面积乘以单价，加上抽屉、五金件、特殊工艺的费用”。所以商品模型要同时满足展示和计价两种需求。

我的设计思路是这样的：建立一个产品分类表（如衣柜、橱柜、电视柜、榻榻米），再建产品表，产品表除了基本信息，还需要包含计价方式相关的字段，比如单价的单位、是否支持按投影面积计算、是否支持定制尺寸。

核心模型大致这样：

class ProductCategory(models.Model): name = models.CharField('分类名称', max_length=50) parent = models.ForeignKey('self', blank=True, null=True, on_delete=models.CASCADE, verbose_name='父级分类') sort = models.IntegerField('排序', default=0) class Meta: verbose_name = '产品分类' verbose_name_plural = verbose_name def __str__(self): return self.name class Product(models.Model): PAY_MODE_CHOICES = ( (1, '按件计价'), (2, '按投影面积计价'), (3, '按展开面积计价'), ) name = models.CharField('产品名称', max_length=100) category = models.ForeignKey(ProductCategory, on_delete=models.PROTECT, verbose_name='所属分类') cover = models.ImageField('封面图', upload_to='product/', blank=True) price = models.DecimalField('基准价', max_digits=10, decimal_places=2) pay_mode = models.SmallIntegerField('计价方式', choices=PAY_MODE_CHOICES, default=1) material = models.CharField('材质说明', max_length=200, blank=True) is_active = models.BooleanField('是否上架', default=True) created_at = models.DateTimeField('创建时间', auto_now_add=True)

这里有几个细节值得注意。外键用“on_delete=models.PROTECT”而不是默认的CASCADE，因为产品分类被删除时，不应该把整个商品全部连带删掉，而是应该禁止删除并提示先去处理商品，这在业务上更安全。机械Model字段用DecimalField不用FloatField，因为金额计算如果用浮点数，会出现0.1加0.2不等于0.3这类精度问题，而DecimalField精确到分，报价计算才不会出错。

3.3 订单模型与状态流转设计

订单是这套系统的核心，下单、支付、量尺、制作、安装、完成，每个环节都要有据可查，所以订单模型要带状态字段和订单编号。

class Order(models.Model): STATUS_CHOICES = ( (0, '待支付'), (1, '待分配量尺'), (2, '待上传方案'), (3, '方案待确认'), (4, '待生产'), (5, '安装中'), (6, '已完成'), (7, '已取消'), (8, '售后中'), ) order_no = models.CharField('订单编号', max_length=32, unique=True) user = models.ForeignKey(User, on_delete=models.CASCADE, verbose_name='下单用户') designer = models.ForeignKey(User, blank=True, null=True, on_delete=models.SET_NULL, related_name='designer_orders', verbose_name='负责设计师') status = models.SmallIntegerField('订单状态', choices=STATUS_CHOICES, default=0) total_amount = models.DecimalField('订单总金额', max_digits=12, decimal_places=2) address = models.CharField('收货地址', max_length=255) remark = models.CharField('用户备注', max_length=255, blank=True) created_at = models.DateTimeField('下单时间', auto_now_add=True) updated_at = models.DateTimeField('更新时间', auto_now=True)

订单编号不要用自增ID直接展示，因为自增ID会暴露订单量，而且位数不统一。我习惯用“当前日期+随机数”生成，规则可以是这样：取当天年月日再加6位随机数字，在创建订单时校验唯一性，冲突就重新生成。这个细节很小，但论文里可以写上“订单编号采用日期加随机数策略，保证高并发下不重复”，也算一个亮点。

订单状态字段用SmallIntegerField加choices，而不是存字符串，好处是有明确的数值顺序，后期做筛选和统计更方便。比如统计当前“待生产”状态的订单，一行过滤就能出来。

3.4 扩展模型：量尺记录与施工进度

订单不是下了就完了，接下来要到线下量尺，再出方案。这个环节在数据库里要有记录，不然订单状态流转就会变成“拍脑袋改状态”，没有数据支撑。

量尺记录表，关联订单和设计师，存量尺日期、量尺地址、房间尺寸数据、现场备注。设计师上传方案之后，方案文件、方案说明、报价明细，也要单独建表存。施工进度可以做成一个进度记录表，每完成一个阶段就插入一条记录，前端按时间线展示，用户就能看到订单走到哪一步了。

这几个扩展模型在论文的业务流程设计章节里作用很大，它们把“系统只管理订单信息”提升到了“系统管理整个服务流程”的维度，答辩时讲业务完整性就有底气了。

4. 核心业务功能实现：报价、购物车、权限与订单流转

4.1 在线报价：投影面积计价逻辑的实现

报价是全屋定制系统最核心的亮点功能，写明白这一块，答辩就已经成功了一半。

先理清计价规则。以一个衣柜为例，常见做法是投影面积计价：衣柜的宽乘以高得到投影面积，然后乘上单价，超出标配部分（抽屉、加长配件、特殊五金）再额外加钱。这套规则落到代码里，关键是“面积计算”和“附加项计算”分离，不要全塞到一个函数里。

我的实现思路是，建立一个报价对象，客户选择完产品、填写宽高尺寸、勾选附加项后，后台实时计算并返回总价。核心代码大概长这样：

def calc_cabinet_price(width, height, unit_price, addons_amount=0, rate=1.0): """ 按投影面积计算柜体价格 width: 宽度(米) height: 高度(米) unit_price: 套餐单价(元/平方米) addons_amount: 附加件总价 rate: 材料等级系数，如实木多层板为1.2，颗粒板为1.0 """ area = width * height base = area * unit_price * rate return round(base + addons_amount, 2)

这里有个容易忽略的点：尺寸单位。用户页面输入的一般是毫米，比如衣柜宽2400毫米，高2600毫米，如果不转换直接用，算出来的面积会大得离谱。所以前端输入毫米，后端先除以1000转成米再参与计算。这个单位转换的细节，是调试报价功能时最高频的bug来源，也是代码讲解时可以重点提的一个坑。

4.2 购物车与订单提交流程

购物车的实现有会话方案和数据库方案两种。会话方案用request.session存商品列表，简单快速，但用户换设备就丢；数据库方案建一张购物车表存用户和商品的关系，体验更好，也不会丢。

我倾向于数据库方案，因为毕业设计要展示的是“完整体验”，而且数据库方案在论文里能多画一张数据表，内容更充实。购物车表不复杂：关联用户、关联商品、记录数量、记录加入时间。加购和修改数量都是常规增删改查，不多说。

提交流程就需要认真设计了，关键点在于“事务”。因为创建订单时要同时写入订单主表和订单明细表，明细有多条时，任何一条写入失败都会导致数据对不上。

from django.db import transaction from django.utils import timezone @transaction.atomic def create_order(user, cart_items, address, remark): order_no = generate_order_no() total = sum(item.product.price * item.quantity for item in cart_items) order = Order.objects.create( order_no=order_no, user=user, total_amount=total, address=address, remark=remark, status=0 ) for item in cart_items: OrderItem.objects.create( order=order, product=item.product, quantity=item.quantity, price=item.product.price, subtotal=item.product.price * item.quantity ) item.delete() # 下单成功后清空购物车这些条目 return order

用“transaction.atomic”装饰器包住整个操作，任何一个环节出问题都会自动回滚。这个操作在文档里一定要写清楚，它是保证订单数据一致性的关键。

总价计算这里还有一个细节：涉及商品单价、订单明细单价、订单总金额，至少要三个字段都存一份。因为商品价格以后可能调整，但历史订单的单价不能跟着变。这就是所谓的“快照”思想，写论文时值得展开讲。

4.3 权限控制与状态流转的落地

Django的认证系统已经处理了“登录状态”这件事，但“不同角色能做什么”还需要自己控制。最简单的方案是装饰器加用户类型判断。

from functools import wraps from django.http import JsonResponse def require_role(*roles): def decorator(view_func): @wraps(view_func) def _wrapped(request, *args, **kwargs): if not request.user.is_authenticated: return JsonResponse({'code': 403, 'msg': '请先登录'}) if request.user.profile.user_type not in roles: return JsonResponse({'code': 403, 'msg': '无权操作'}) return view_func(request, *args, **kwargs) return _wrapped return decorator

这个装饰器用起来很顺手：设计师端接口标“@require_role(2)”，管理员端标“@require_role(3)”，普通操作标“@require_role(1, 2, 3)”。它比到处写if判断更清晰，也更方便后期维护。

订单状态流转要遵循一个原则：状态只能按顺序流转，不能跳着改，更不能倒着退。比如“待分配量尺”只能变成“待上传方案”，不能直接变成“已完成”。我实现的方式是定义一个状态机映射表：

STATUS_FLOW = { 0: [1], # 待支付 -> 待分配量尺 1: [2], # 待分配量尺 -> 待上传方案 2: [3], # 待上传方案 -> 方案待确认 3: [4, 7], # 方案待确认 -> 待生产 / 已取消 4: [5], 5: [6], }

每次更新订单状态，先判断当前状态和目标状态的关系是否在映射表里，不在就直接拒绝。这样做能防止数据被随意篡改，也符合业务真实流程。答辩时如果老师问“用户能不能取消订单”，你就可以说：取消只允许在“方案待确认”之前操作，进入生产流程后订单不可自行取消，需要联系客服走售后流程，这里体现的正是业务上的控制逻辑。

5. 从0到1实操过程实录：环境搭建、项目生成与联调

5.1 创建项目与基础配置

按照毕业设计的常规路径，第一步是创建虚拟环境、安装Django。接着创建项目和应用，我建议把所有业务功能集中到一个应用里，比如叫“main”或者“app”，不要拆成五六个应用。毕设项目不是企业级微服务，拆得太细反而增加管理成本。

基础配置层面，重点关注这几个地方：

# settings.py 里需要调整的核心配置 INSTALLED_APPS = [ # ... 'django.contrib.humanize', # 模板里做数字格式化 'app', # 核心业务应用 ] # 数据库切换为 MySQL 时的配置 DATABASES = { 'default': { 'ENGINE': 'django.db.backends.mysql', 'NAME': 'home_decor', 'USER': 'root', 'PASSWORD': 'your_password', 'HOST': '127.0.0.1', 'PORT': '3306', 'OPTIONS': {'charset': 'utf8mb4'}, } } # 时区设置，建议保留本地时区而非 UTC TIME_ZONE = 'Asia/Shanghai' USE_TZ = True

时区这地方最容易踩坑。如果USE_TZ保持True不设置TIME_ZONE，Django创建的数据是UTC时间，和北京时间差8个小时，前端展示“下单时间”时会看到比实际时间晚8小时的诡异情况。我建议把TIME_ZONE设为“Asia/Shanghai”，时间显示就正常了。

5.2 模板与静态文件组织

前端页面的组织方式也有讲究。不要每个页面都写一套完整HTML，而是做一个基础模板，把公共部分（头部导航、页脚、CSS样式引用）抽出来，子页面通过模板继承重写中间的内容块。

Django的模板继承语法很简单，基础模板里写好“{% block content %}”，子页面用“{% extends 'base.html' %}”加“{% block content %}...{% endblock %}”填充自己的内容。这样首页、商品列表页、订单详情页的公共框架只写一遍，后面改导航栏只需要动一个文件。

静态文件（图片、CSS、JS）放在应用的static目录里，在模板中用“{% load static %}”加载。这里有一个我见过无数人卡住的问题：本地开发时改了CSS，浏览器刷新永远是旧样式。这不是代码错了，而是浏览器缓存了静态文件。解决办法是刷新时按住Ctrl+F5强制刷新，或者在CSS文件后面加版本参数，比如“style.css?v=20250101”。

5.3 管理后台定制：让Admin更好用

Django自带Admin后台是默认的管理端，但直接裸用体验很差。我建议花一点时间定制，主要是设置列表页展示的字段、可搜索字段和筛选器。

from django.contrib import admin from .models import Product, Order @admin.register(Product) class ProductAdmin(admin.ModelAdmin): list_display = ('name', 'category', 'price', 'pay_mode', 'is_active', 'created_at') list_filter = ('category', 'pay_mode', 'is_active') search_fields = ('name',) list_editable = ('is_active',) @admin.register(Order) class OrderAdmin(admin.ModelAdmin): list_display = ('order_no', 'user', 'status', 'total_amount', 'created_at') list_filter = ('status',) search_fields = ('order_no', 'user__username') date_hierarchy = 'created_at'

这里的“search_fields = ('order_no', 'user__username')”是Django Admin里的一个常用技巧，用双下划线跨表关联搜索用户名字段，注册的时候就可以直接按用户名找订单。这种“双下划线语法”不仅是Admin定制，在整个ORM查询里都通用，写论文时务必写进关键技术点。

6. 常见问题速查与避坑技巧

6.1 我见过最多人踩的坑

做这类系统，我用亲身经验总结出了一份高频问题速查表。每一个都对应过一次血泪调试经历，建议直接存下来备用。

表单CSRF那个问题尤其常见，很多同学第一次写注册页就卡在403上。记住一个原则：只要HTML表单的method是POST，就必须在form标签内部加“{% csrf_token %}”，这是Django默认开启的安全机制，也是面试官喜欢问的一个点。

6.2 查询性能优化：别让ORM拖垮首页

数据量不大的时候，ORM怎么写都很快，但到了答辩演示，如果商品表有几百条、订单表有几千条，不注重查询性能就可能出现列表页卡顿。

最常见的性能坑是“N+1查询”。比如在模板里循环显示订单列表，每显示一个订单还要通过外键去查一次用户名，页面加载一次可能触发几十次数据库查询。解决办法是在视图里用select_related（针对一对一、多对一外键）或者prefetch_related（针对多对多、反向查询）一次性把关联数据取出来。

# N+1 查询：每次循环都查一次用户 orders = Order.objects.all() # 优化后：一条SQL把订单和用户关联数据一起查出来 orders = Order.objects.select_related('user').all()

用“django-debug-toolbar”这个工具能看到页面执行了多少条SQL，把工具栏面板打开，再访问列表页，如果SQL条数超过列表条数，那基本就是N+1问题。这个工具放进去调试一遍，论文里还可以截图展示优化前后的查询次数对比，非常加分。

6.3 代码讲解与毕设文档如何配合

做毕业设计最怕的是“程序跑起来了，但讲不清楚”。代码讲解不要求一行一行念，关键是能把“为什么这样设计”讲明白。

我的建议是准备三块内容。第一，一个业务流程图，从用户下单到收货，把每一步对应到系统的哪个视图函数、哪个模型、哪个状态变化，都标出来。第二，一个模型关系图，画出User、Order、OrderItem、Product、ProductCategory之间的关系，讲清楚每个外键的用途。第三，准备2到3个核心函数的逐行讲解，推荐优先准备报价计算、下单事务、权限装饰器这三块。

文档写作上，重点写需求分析和数据库设计。需求分析里的用例图可以按角色画，用户能做什么、设计师能做什么、管理员能做什么，一一对应；数据库设计里要把表的字段写全，特别注明主外键、数据类型、是否为空、默认值。这些内容写充实了，论文主体自然就丰满了。

回到标题本身，“程序+文档+代码讲解”的模式其实是一个很好的学习路径：先跑通程序，再读文档理解设计，最后通过代码讲解深入细节。如果你是自己做毕设，也建议用同样的顺序推进，先实现核心流程，再完善文档，最后准备讲解，这样的产出才是完整可验收的。

最后说点实在的。做这种带业务流程的系统，最容易翻车的地方不是某个技术难点，而是业务逻辑没有闭环。下单之后状态不流转、设计师改了方案用户端没提示、管理员分配了任务设计师端看不到，这些问题在开发前期很难发现，等联调的时候才暴露就很被动。我的建议是先把订单状态流转图在纸上画出来，再动手写代码，哪里断了补哪里，系统跑通的那一刻，你会觉得这门课没白上。