简介一套面向毕业设计或课程设计的酒店预订管理系统资源基于Python、Django与Vue.js开发采用前后端分离的B/S架构。前端涵盖首页、客房详情、订单中心、用户中心后端涵盖总览、订单、客房、房间分类、标签、评论、用户、运营、日志、系统信息等模块可作为计算机专业学生理解完整业务闭环与前后端协作的参考项目。压缩包共391个文件约33.19MB包括32个Python后端源码、28个Vue前端组件、49个TypeScript文件及JavaScript、JSON、Markdown等配置文档另有上百张JPEG/PNG/SVG图片资源用于界面预览与素材参考。目前已有249人浏览/学习该资源适合正在准备毕业设计、课程设计或想了解酒店预订系统实现思路的开发者。通过源码目录可清晰区分server后端与web前端辅以部署运行说明和依赖清单能帮助学习者快速搭建环境、核对功能模块与二次开发。1. 基于pythondjangovue做酒店预订系统这是一条能跑的毕业设计路线每年毕业季都会看到不少同学抱着“基于python的酒店预订网站”这类题目无从下手。这个题目的本质不是写一个网页而是要用django把房间、订单、用户这些业务模型管起来再用vue把选房、下单、管理这些页面搭出来前后端通过JSON接口对话。它覆盖面广但门槛不高正好卡在课程设计和真实项目之间。适合谁有Python基础但没做过完整web项目的同学也适合要快速交付、拿源码改一改就能演示的人。先说结论这套系统做好有三件事必须过——数据模型设计、接口约定、联调排错。本篇按这个顺序讲从选型到落地到演示前检查每段都能直接照着做。2. 技术选型与架构拆解为什么是djangovue数据从选房到下单怎么走2.1 为什么是 pythondjangovue三件事各管什么先讲职责划分。Django负责“数据与业务规则”——房间有哪些、几号到几号能不能订、价格怎么算、订单状态怎么流转这些写在model和view里Vue负责“人机交互”——房间列表怎么展示、日期选择器长什么样、订单提交后跳哪个页面这些写在component和router里Python是串起这一切的语言层Django本身跑在Python上业务逻辑、工具脚本、数据初始化全用它写。再看为什么不是别的组合。常见对比对象是Spring Boot Vue和Flask Vue。Spring Boot在Java生态里成熟但毕设周期短Java的构建链和部署比Python重Flask轻但ORM、Admin、迁移、认证这些“开箱即用”的东西都要自己拼做到后面会发现时间和踩坑成本更高。Django把这些内置了外加djangorestframework补上API层是最省力的路径。答辩时被问“为什么选这套”答案就是Django管数据模型和业务规则Vue管交互Python做胶水三者各司其职复杂度可控。Django内置的Admin后台在酒店预订里可以当“管理端原型”但真正展示时我用vue另做管理页因为Admin的交互风格明显不是“系统管理”的样子。2.2 前后端分离架构下的数据流从选房到下单走一遍我用文字描述一遍“用户从打开网站到下单成功”这条链路这是整个项目最重要的心智模型比任何架构图都直接。用户打开Vue页面页面挂载时通过axios向Django的URL发请求Django的URLconf把请求路由到对应的ViewView调用ORM去SQLite或MySQL里查房间数据经Serializer转成JSON返回Vue拿到JSON后渲染成房型卡片。下单时多一步Vue把房间id、入住日期、离店日期通过POST发给DjangoDjango在事务里校验房间状态、计算总价、创建订单然后把订单id和状态返回给页面。用户看到的“预订成功”在这个链路里是最后一步前面任何一环断了页面都只会停在转圈。到这里要有一张表开发时它就是“前后端契约”先定好两边各做各的方法路径入参出参用途GET/api/rooms/check_in, check_out, room_type可订房间列表首页/列表筛选GET/api/rooms/{id}/-房间详情详情页POST/api/orders/room, check_in, check_out订单对象提交订单GET/api/orders/-当前用户订单列表个人中心POST/api/orders/{id}/cancel/-订单状态取消订单POST/api/auth/register/username, password用户信息注册POST/api/auth/login/username, passwordtoken登录路径里/rooms/{id}的id是主键Vue的路由参数也叫id两边对齐就行接口一旦定了前端mock数据也可以按这个结构来。开发时我会先让后端把接口跑通、返回固定JSON前端先写在假数据上再切换成真实请求这样联调时出问题能很快定位是后端逻辑还是前端渲染。2.3 环境准备与项目骨架python、django、vue各自的安装注意点环境这步看起来简单实际是翻车高发区。Python版本差异、Node版本差异、包管理器混用都会导致后面代码报错。我的习惯是先各自建独立环境别把东西装到全局。# 后端Python虚拟环境 Django项目骨架 python -m venv venv source venv/bin/activate # Windows用 venv\Scripts\activate pip install django djangorestframework django-cors-headers django-admin startproject hotel_backend cd hotel_backend python manage.py startapp rooms python manage.py startapp ordersvenv把Python依赖隔离在当前目录避免和系统Python混在一起这里只装django、DRF和cors-headers分页、过滤、认证等用到再加不用一上来装一堆。startapp建两个应用rooms管房型与房间orders管订单用户用Django自带的User。参数说明venv的名字是约定俗成的装好后激活后续所有python、pip命令都在这个环境里跑换终端后第一件事就是激活它这是新手最容易漏的。前端侧对应命令# 前端Vite Vue3 工程 npm create vuelatest hotel_frontend # 选择Vue Router、Pinia其余默认 cd hotel_frontend npm install npm install axiosVite是目前Vue生态默认推荐启动快、配置简单比webpack适合课程设计创建时选上Vue Router和Pinia后面路由和状态管理直接有骨架。axios是HTTP库用来向Django发请求。注意Node版本建议用18以上如果电脑上node过旧vue create和install阶段会报unexpected需要先升级Node再建项目不建议跳过。提示新建前端工程后先跑npm run dev确认页面能开再往后写组件。不要一上来同时建两套架子两边一起报错时新手很难判断是谁的问题。3. Django后端落地建模、接口、登录权限一套写全3.1 酒店预订的核心模型设计Room、Order、User怎么建表建模是这套系统里最不该省时间的部分。表一错后面所有接口和页面都得跟着改。我做毕设级别的酒店预订时会建三块房型、房间、订单用户直接用Django自带User。# rooms/models.py from django.db import models class RoomType(models.Model): name models.CharField(max_length50, uniqueTrue, verbose_name房型名) price models.DecimalField(max_digits8, decimal_places2, verbose_name门市价) area models.IntegerField(verbose_name面积(平米)) bed models.CharField(max_length20, verbose_name床型) def __str__(self): return self.name class Room(models.Model): STATUS_CHOICES ( (available, 可订), (maintenance, 维修), ) room_type models.ForeignKey(RoomType, on_deletemodels.PROTECT, related_namerooms, verbose_name所属房型) room_number models.CharField(max_length10, uniqueTrue, verbose_name房间号) status models.CharField(max_length20, choicesSTATUS_CHOICES, defaultavailable, verbose_name房间状态) def __str__(self): return f{self.room_number}({self.room_type.name})# orders/models.py from django.db import models from django.conf import settings class Order(models.Model): STATUS_CHOICES ( (pending, 待支付), (paid, 已支付), (cancelled, 已取消), (completed, 已完成), ) user models.ForeignKey(settings.AUTH_USER_MODEL, on_deletemodels.CASCADE, related_nameorders, verbose_name下单用户) room models.ForeignKey(rooms.Room, on_deletemodels.PROTECT, related_nameorders, verbose_name房间) check_in models.DateField(verbose_name入住日期) check_out models.DateField(verbose_name离店日期) nights models.IntegerField(verbose_name入住晚数) total_price models.DecimalField(max_digits10, decimal_places2, verbose_name订单总价) status models.CharField(max_length20, choicesSTATUS_CHOICES, defaultpending, verbose_name订单状态) created_at models.DateTimeField(auto_now_addTrue, verbose_name创建时间) def __str__(self): return fOrder#{self.id} {self.room.room_number}这两段为什么要这样设计得说清楚。价格用DecimalField不用FloatField浮点数在Python里做金额运算会出0.10.2这类精度问题展示时是小事一旦算错结算金额就很致命DecimalField精确到分配合decimal_places2计算总额时用Decimal而不是float。房型价格放RoomType而不放Room同一个房型有多间房价格跟着房型走改价格只改一处Room只记录房间号、状态和属于哪个房型。Order里放room外键而不是room_type真实订房是订某一间具体的房虽然前端通常按房型展示但后端要以具体房间为粒度做库存和冲突判断。on_deletemodels.PROTECT订单引用的房间不允许直接删防止把历史订单数据搞没这是我踩过的坑默认CASCADE在删房型时会把订单一起删掉。模型写好后执行迁移python manage.py makemigrations python manage.py migratemakemigrations自动生成迁移文件migrate真正建表settings.py的INSTALLED_APPS里要注册rooms和orders漏了会报“No installed app”相关错误。3.2 用DRF把房间查询和下单接口写出来序列化器与视图模型定好后接口层用DRF写。序列化器定义接口的入参和出参格式视图决定业务规则。# rooms/serializers.py from rest_framework import serializers from .models import Room, RoomType class RoomListSerializer(serializers.ModelSerializer): room_type_name serializers.CharField(sourceroom_type.name, read_onlyTrue) price serializers.DecimalField(sourceroom_type.price, max_digits8, decimal_places2, read_onlyTrue) class Meta: model Room fields [id, room_number, room_type, room_type_name, price, status]# rooms/views.py from rest_framework import viewsets from django.db.models import Q from .models import Room from .serializers import RoomListSerializer from orders.models import Order class RoomViewSet(viewsets.ReadOnlyModelViewSet): queryset Room.objects.select_related(room_type).filter(statusavailable) serializer_class RoomListSerializer def get_queryset(self): qs super().get_queryset() check_in self.request.query_params.get(check_in) check_out self.request.query_params.get(check_out) room_type self.request.query_params.get(room_type) # 日期筛选有冲突订单的房间直接排除 if check_in and check_out: conflict_ids Order.objects.filter( Q(check_in__ltcheck_out) Q(check_out__gtcheck_in), status__in[pending, paid], ).values_list(room_id, flatTrue) qs qs.exclude(id__inconflict_ids) if room_type: qs qs.filter(room_type_idroom_type) return qs参数说明RoomViewSet继承ReadOnlyModelViewSet只允许查询不允许从接口改数据毕设里写这种保护是加分项。get_queryset里用Q对象做日期区间重叠判断核心逻辑是check_in小于对方离店、且check_out大于对方入住即区间有交集status限定pending和paid已取消的订单不占房。这里查出的Room列表就是可订房间。下单接口对应orders应用# orders/serializers.py from rest_framework import serializers from .models import Order class OrderCreateSerializer(serializers.ModelSerializer): class Meta: model Order fields [room, check_in, check_out]# orders/views.py from rest_framework import viewsets, permissions, serializers from datetime import date from django.db.models import Q from .models import Order from .serializers import OrderCreateSerializer class OrderViewSet(viewsets.ModelViewSet): serializer_class OrderCreateSerializer permission_classes [permissions.IsAuthenticated] def get_queryset(self): return Order.objects.filter(userself.request.user).order_by(-created_at) def perform_create(self, serializer): room serializer.validated_data[room] check_in serializer.validated_data[check_in] check_out serializer.validated_data[check_out] if check_in check_out: raise serializers.ValidationError({detail: 离店日期必须晚于入住日期}) conflict Order.objects.filter( roomroom, status__in[pending, paid], check_in__ltcheck_out, check_out__gtcheck_in, ).exists() if conflict: raise serializers.ValidationError({detail: 该房间在此时间段已被预订}) nights (check_out - check_in).days price room.room_type.price serializer.save(userself.request.user, nightsnights, total_pricenights * price, statuspending)perform_create里先做两个校验再保存订单。日期先后校验必做我在实际中见过用户把离店日期选在入住之前订单总额算出负数时间段冲突查询用exists()而不是查列表因为只需要知道“有没有”。订单落库时user从request.user传入不能信任前端传的user_id否则用户可以伪造身份给自己或他人下单。nights用两个日期相减total_price在服务端计算价格以服务端为准。注意这里没有用事务包整个方法因为整个perform_create里只有一个exists和一个save不涉及多个表的写操作事务在这里没有收益真正要防并发见第5章避坑的写法。3.3 登录注册与权限控制从django.contrib.auth到自定义Token权限这块毕设最容易做成“有登录框但没权限”——页面能进但管理接口谁都能调。我一般用djangorestframework-simplejwt它比Django的SessionAuth更适合前后端分离场景。pip install djangorestframework-simplejwt# hotel_backend/settings.py 摘录 INSTALLED_APPS [ # ... rest_framework, rest_framework_simplejwt, corsheaders, rooms, orders, ] REST_FRAMEWORK { DEFAULT_AUTHENTICATION_CLASSES: [ rest_framework_simplejwt.authentication.JWTAuthentication, ], }# hotel_backend/urls.py from django.urls import path, include from rest_framework.routers import DefaultRouter from rest_framework_simplejwt.views import TokenObtainPairView, TokenRefreshView from rooms.views import RoomViewSet from orders.views import OrderViewSet router DefaultRouter() router.register(rrooms, RoomViewSet, basenameroom) router.register(rorders, OrderViewSet, basenameorder) urlpatterns [ path(api/, include(router.urls)), path(api/auth/login/, TokenObtainPairView.as_view(), nametoken_obtain_pair), path(api/auth/refresh/, TokenRefreshView.as_view(), nametoken_refresh), ]JWT的思路是“登录拿token、请求带token”前端把token存本地每次请求在Authorization头带上Django侧通过JWTAuthentication自动解析token并识别用户。路由里用DefaultRouter注册rooms和orders/api/rooms/、/api/orders/自动生成。TokenObtainPairView是simplejwt提供的登录视图返回access和refresh两个tokenaccess有效期短refresh用于过期后续期。为什么要refresh和session不同JWT一旦签发无法主动失效所以access时效设短一些安全性更高。注册接口simplejwt没内置写一个简单视图# accounts/views.py from rest_framework import generics, permissions, serializers from django.contrib.auth.models import User from rest_framework.validators import UniqueValidator class RegisterSerializer(serializers.ModelSerializer): password serializers.CharField(write_onlyTrue, min_length6) class Meta: model User fields [username, password] extra_kwargs {username: {validators: [UniqueValidator(querysetUser.objects.all())]}} def create(self, validated_data): return User.objects.create_user(**validated_data) class RegisterView(generics.CreateAPIView): queryset User.objects.all() serializer_class RegisterSerializer permission_classes [permissions.AllowAny]用create_user而不是create是因为create_user会自动哈希密码直接create会把明文密码存库这是严重安全隐患。UniqueValidator保证用户名唯一注册重复用户名会返回400。注册成功后在urls里加path(api/auth/register/, RegisterView.as_view())。到这里后端闭环完成能注册、能登录、能查房、能下单。前端的问题从下一章开始。4. Vue前端对接路由、axios、页面组件如何咬住Django的接口4.1 用Vite把前端工程跑起来页面划分与路由参数设计前端不建议从零手写组件用Element Plus做UI是毕设里最稳的选择表格、日期选择器、弹窗都是现成的样式也整齐。先定页面拆四个前端页面加一个管理页——房间列表页、房间详情页、订单确认页、登录注册页、后台管理页。npm install element-plus路由设计里有一个核心点详情页一定带参数。Vue Router用动态片段传id// src/router/index.js import { createRouter, createWebHistory } from vue-router import RoomList from ../views/RoomList.vue import RoomDetail from ../views/RoomDetail.vue import OrderConfirm from ../views/OrderConfirm.vue import Login from ../views/Login.vue const routes [ { path: /, redirect: /rooms }, { path: /rooms, component: RoomList }, { path: /rooms/:id, component: RoomDetail, props: true }, { path: /order/confirm, component: OrderConfirm }, { path: /login, component: Login }, ] const router createRouter({ history: createWebHistory(), routes, }) export default router路由参数说明rooms/:id里的:id就是详情页拿到的roomId在模板里用useRoute().params.id读取。前端这个id不是房间号room_number而是后端Room表的主键id接口里/api/rooms/{id}/和它一一对应。props: true让路由参数直接注入组件props少一层样板代码如果组件里用组合式API就用useRoute读取。订单确认页不带参数因为下单时需要的room、日期都从上一页通过Pinia或query传过来我的习惯是把下单关键数据放Pinia刷新页面丢失时跳回详情页而不是塞进URL。4.2 用Axios封装API请求与Django对接的路径写法前端对接Django第一步是配一个统一的axios实例。到处直接写axios.get会有一个问题baseURL、token、错误提示逻辑全都重复而且换环境时改一片。我一般封装成单独模块// src/api/request.js import axios from axios const request axios.create({ baseURL: /api, // 走Vite proxy不写死http://127.0.0.1:8000 timeout: 10000, }) // 请求拦截器自动带JWT token request.interceptors.request.use((config) { const token localStorage.getItem(access_token) if (token) { config.headers.Authorization Bearer ${token} } return config }) // 响应拦截器统一处理401 request.interceptors.response.use( (response) response.data, (error) { if (error.response error.response.status 401) { localStorage.removeItem(access_token) window.location.href /login } return Promise.reject(error) } ) export default requestbaseURL写成/api配合Vite的proxy把请求转发到Django而不是直接写http://127.0.0.1:8000。原因浏览器向Vite开发服务器发请求Vite把/api开头转发到Django这样避免CORS生产构建时由nginx做同样转发前端代码不用改。拦截器部分请求拦截器把localStorage里的access_token放进Authorization头响应拦截器捕获401——token过期或未登录时清掉本地token跳转登录页。这是一个在毕设里很加分的小设计不是每个页面都写“未登录”而是统一处理。Vite proxy配置// vite.config.js export default { server: { proxy: { /api: { target: http://127.0.0.1:8000, changeOrigin: true, }, }, }, }target指向Django开发服务器地址Django runserver默认8000端口如果改了端口这里要同步changeOrigin: true把请求头里的Host改成target域名避免Django的ALLOWED_HOSTS校验报400。开发阶段配好proxyDjango侧其实可以不开cors-headers但如果前端直接从浏览器跨域请求8000端口就需要cors-headers配合两条路选一条走同时开着也行只是多一层依赖。4.3 房间列表页和详情页从「有数据」到「交互完整」列表页的重点不是把rooms数组遍历出来而是“筛选条件真正影响请求参数”。用户选入住日期、离店日期、房型后前端要把这些条件拼成query再请求而不是在前端内存里过滤——否则订走的房间依然显示可订。script setup import { ref, onMounted } from vue import request from ../api/request const rooms ref([]) const filters ref({ check_in: , check_out: , room_type: , }) async function loadRooms() { const params {} if (filters.value.check_in) params.check_in filters.value.check_in if (filters.value.check_out) params.check_out filters.value.check_out if (filters.value.room_type) params.room_type filters.value.room_type rooms.value await request.get(/rooms/, { params }) } onMounted(loadRooms) /scriptget的第二个参数{ params }会把对象转成query string空值不传。后端get_queryset里只认check_in、check_out、room_type这三个参数前端对应拼上去两边字段名保持一致是联调时不吵架的前提。筛选顺序建议“日期先选房型后选”因为酒店业务的库存先按日期查再加房型维度。如果用户只选了入住没选离店可以只传check_in后端默认只排除当日入住的冲突订单。详情页的复杂度集中在“选日期 提交订单”。日期组件用Element Plus的el-date-pickertypedaterange一次选入住离店提交时调POST /orders/。一个我多次踩到的细节下单前先确认登录。没登录时调接口会401响应拦截器会把用户踢到登录页但用户的选房数据全丢了。更顺的做法是点击“立即预订”时检查token没有就跳登录页并带上redirect参数const goLogin () { localStorage.setItem(redirect_after_login, window.location.href) window.location.href /login }登录成功后读出redirect_after_login再跳回来这样用户登录完直接回到选房页面。这个体验细节在答辩演示时很加分因为大多数人做的是“登录后回首页选的数据没了”。详情页拿到订单创建成功后跳转到订单确认页显示订单号、金额和状态订单确认页还有一个隐藏价值——向评审展示订单状态机的概念pending、paid、cancelled、completed页面上一组tag表达状态变化比长篇文字解释直观得多。提示Element Plus按需引入能减少打包体积但毕设宁可全量引入也不要在按需配置上花太多时间演示时缺个组件更麻烦。5. 联调避坑djangovue前后端分离最容易翻车的5个现场5.1 Django时区错乱订单日期差一天现象用户选3月10日入住后端保存后变成3月9日或11日列表页显示错位。原因Django的USE_TZTrue时DateTimeField存的是UTC时间DateField本不该受影响但前端传递的日期字符串如果带时区偏移或者浏览器自动把本地时间转成ISO字符串解析时就会偏移一天。解决日期字段统一用DateField前端传YYYY-MM-DD字符串后端让DRF的DateField直接解析settings.py里把USE_TZ保持TrueTIME_ZONE设置为Asia/Shanghai。我在实战中最终把订单相关的check_in和check_out都定为DateFieldcreated_at这种时间戳用DateTimeField两类字段各管各的互不干扰。5.2 Vue打包后API请求全部404现象本地npm run dev一切正常npm run build后把dist文件扔给Django或nginx页面开了接口全404。原因打包后前端是纯静态文件/api请求打到了静态服务器上而静态服务器没有对应的API路由。解决部署架构改成“Django提供接口nginx把/api反向代理到Django”就像开发时Vite proxy做的那样。如果图省事把dist放进Django的static目录、用TemplateView serve前端页面则要确保请求仍然打到Django服务本身而不是被静态文件处理器截走。最稳妥的做法本地keep开发模式部署时写一份nginx配置把/api和/static分开代理这也能在答辩时展示“我理解部署”。5.3 CORS报错“CORS policy: No ‘Access-Control-Allow-Origin’”现象前端页面跑在5173端口请求8000端口的Django浏览器控制台报CORS错django-cors-headers装了也报错。原因settings.py里MIDDLEWARE顺序不对——corsheaders.middleware.CorsMiddleware必须在CommonMiddleware之前否则放行头没生效或者ALLOWED_HOSTS没包含前端originDjango直接400。解决按官方推荐的顺序把CorsMiddleware放在最上层MIDDLEWARE [ corsheaders.middleware.CorsMiddleware, django.middleware.common.CommonMiddleware, # ... ] CORS_ALLOWED_ORIGINS [http://localhost:5173, http://127.0.0.1:5173]如果你用Vite proxy其实不会触发CORS这个报错通常出现在直接访问8000或部署后前后端域名不同CORS_ALLOWED_ORIGINS白名单明确写不要图省事开CORS_ALLOW_ALL_ORIGINSTrue答辩被问安全策略时能解释清楚更稳。另外注意CORS和CSRF是两回事DRF的SessionAuth会附带CSRF校验但用JWT通常不受CSRF影响不要把两者混为一谈。5.4 并发下单同一房间最后一天被订两次现象两个人同时提交同一房间同一日期两个请求都返回成功数据库里两条pending订单。原因校验和写入之间存在时间窗口先查后写的两步操作在并发下会被交叉执行用exists()只做查询并不能阻止并发。解决把“校验写入”放进数据库事务并对房间行加锁from django.db import transaction with transaction.atomic(): room Room.objects.select_for_update().get(pkroom_id) conflict Order.objects.filter( roomroom, status__in[pending, paid], check_in__ltcheck_out, check_out__gtcheck_in, ).exists() if conflict: raise serializers.ValidationError({detail: 该房间已被抢先预订}) order Order.objects.create(...)select_for_update会对Room行加数据库锁第二个并发事务会等待前一个提交或回滚从而保证“查状态创建订单”是原子操作。这在毕设里同样是加分项因为大部分项目根本没考虑并发。注意事务必须配合数据库才能生效SQLite在并发写场景下效果有限换成MySQL或PostgreSQL部署这个锁才是真的SQLite演示时单用户操作看不到问题但写进去这个设计答辩被问“并发怎么办”就有得说。另外别在锁里做耗时网络操作锁的范围越小越好。5.5 Django执行查询-删除对象删房型时被订单挡住现象后台想删某个房型Django抛ProtectedError或者用CASCADE删了订单把用户订单数据带没了。原因RoomType被Room引用Room又被Order引用on_delete设置决定了删上游时下游怎么处理PROTECT是“有引用就不让删”CASCADE是“连坐”。解决我的方案是RoomType和Room都用PROTECTRoom用status字段做“停用”而不是物理删除Order表是用户数据绝不能因为删房型而消失。操作上前台客房下架直接改Room.status为maintenance从查询结果里排除真正要删房型时先处理关联订单。这个设计体现“你考虑过数据生命周期”比用CASCADE被数据库外键挡回来要成熟。6. 进阶与答辩演示把Demo变成被追问也不虚的项目系统跑通之后还有三件事值得投入时间都是在答辩现场能直接拉开差距的。第一件是造一套“看起来真实”的演示数据。别只有三间房、两个订单评委点进去一看全是空页面印象分先掉一半。我习惯写一个seed脚本用Django的management command批量生成几十个房间、若干房型、几个历史订单房型和价格做成可修改的常量跑python manage.py seed_demo_data就能刷出一套数据。脚本里顺手把某个房间设成“维修”状态演示“下架房型不出现”这个逻辑历史订单覆盖pending、paid、completed三种状态让列表页筛选器有东西可展示。第二件是准备一段3分钟的“全流程演示脚本”顺序固定注册新用户 → 按日期筛选房源 → 打开详情选日期 → 提交订单 → 个人中心看到订单 → 取消订单 → 后台把房间设为维修。中间故意演示一个“日期冲突”的错误提示证明校验不是摆设。我在项目验收前一定会在干净环境里完整走一遍这条链路并录屏保存录屏里如果发现请求失败宁可修好了再录也不要现场翻车。第三件是可选地做“后台有数据前端实时推送”。毕设里最常见的实时场景是“后台改订单状态前台个人中心立即看到”很多人上来就上WebSocket实际上WebSocket要处理连接管理、断线重连、鉴权复杂度远超课程设计范畴。我的建议是先用轮询前端每隔10秒拉一次订单状态改动小、逻辑简单答辩提一句“实时性要求不高轮询已满足场景WebSocket是扩展点”就足够自信了。用pythondjangovue这套组合做到这一步已经比多数毕设完整有模型设计、有接口契约、有权限、有并发考量、有部署说明演示时把背后这几层讲清楚比堆功能更有说服力。最后一条个人习惯我每次改完接口都会先看Django返回的JSON再切回页面页面显示不对时第一反应是打开浏览器开发者工具看Network面板而不是凭感觉改代码。这套系统能跑通不难难的是让它在被追问时依然站得住。希望帮到你。本文还有配套的精品资源点击获取