简介：一份基于Python Django与Vue.js开发的酒店预订管理系统毕业设计资源，面向计算机专业学生及开发者，可作为毕业设计、课程设计或项目实训的完整参考。平台采用B/S架构，前台包括首页、客房详情、订单中心、用户中心，后台涵盖总览、订单管理、客房管理、房间分类、标签、评论、用户、运营、日志及系统信息等模块，前后端分离，server目录为后端、web目录为前端，便于按模块阅读、调试和二次开发。资源共391个文件，以Python源码、Vue组件、JavaScript、JSON配置为主，搭配大量jpeg、png、svg、jpg等图片素材，另有favicon、less、markdown等辅助文件，整体压缩包约33.19MB，后端依赖清单与部署说明一应俱全。目前已有249人学习下载，适合需要快速搭建酒店预订平台、理解Django与Vue前后端协作机制，或为毕业设计准备可运行项目与文档素材的读者，能够覆盖从环境配置、数据表初始化到页面联调的主要环节。
1. 酒店预订网站毕设源码：Django 后端与 Vue 前端的真实分工
每年毕业季都能看到一批做酒店预订网站的同学，选题高度相似，但最后拿到的分数差异很大。同一个题目，有人交上去的是一个能跑通预订流程、后台能管房间和订单的完整系统，有人交上去的只是登录注册加一个静态列表页。差距不在选题，而在实现深度。这份基于 Python + Django + Vue.js 的酒店预订管理系统源码，就是把前者该有的东西一次给齐了——用户注册登录、客房浏览与搜索、在线预订、订单管理、后台数据维护，以及一套能支撑这些页面正常工作的 REST API 接口设计。
我看过太多毕设源码的常见问题是：前端页面做得很漂亮，但接口对不上；或者后端模型设计得还行，但 Vue 这边根本不知道怎么调。这份资源的价值在于它不是零散文件，而是把 Django 的 ORM 模型、视图函数、JWT 用户认证和 Vue 的组件化页面、路由守卫、axios 封装串成了一条完整链路。适合三类人：自己选了类似题目还没动工的应届生，需要在短时间内把系统跑起来再改改参加答辩的，以及想参考一个完整前后端分离项目的在职开发者。
2. 认清项目骨架：为什么是 Django + Vue 而不是别的组合
2.1 前后端分离的边界在哪里划分
打开源码目录，第一件事不是急着跑代码，而是先看清谁在管什么。Django 负责的是一台“业务服务器”：用户能不能登录、房间还有没有库存、订单金额怎么算、数据存进哪张表。Vue 负责的是“浏览器里的交互层”：日历组件选入住日期、列表页的筛选条件、订单提交后的提示弹窗，这些都是前端的事。
两者的分界线在 API。Django 这边用 DRF（Django REST Framework）暴露接口，Vue 这边用 axios 发请求。凡是涉及数据读写和权限校验的逻辑都放在 Django 里，Vue 只负责把 JSON 数据渲染成页面。这么分工的好处是：答辩老师问“你的系统架构是什么样的”，你可以直接回答“前后端分离，Django 提供 RESTful API，Vue 负责视图层交互，数据通过 JSON 传输”，一句话就能讲清架构思路。
目录结构里通常会看到 backend 和 frontend 两个顶级目录，或者 django 和 vue 两个目录。不管命名是什么，识别方法就是看哪个里面有 manage.py，哪个里面有 package.json。manage.py 所在的是 Django 工程，package.json 所在的是 Vue 工程。搞清楚这一点，后面所有启动步骤都不会迷糊。
2.2 Django 端的应用划分与模型字段设计
Django 项目按 app 划分业务模块，酒店预订系统最常见的拆分是用户模块和订单模块。用户模块管理前台注册的会员信息，订单模块管理预订记录和客房信息。一个容易忽略的设计点是：用户和订单之间是外键关系，但订单和房间之间的关联要小心处理。如果订单直接外键到房间表，那一个房间多个订单就是一对多映射，订单查询时用 filter 就能拿到所有预订记录。
模型字段设计是这份源码里值得细看的部分。用户模型通常扩展自 Django 自带的 AbstractUser，新增手机号和头像字段。房间模型的核心字段是房型名称、门市价、协议价、可订数量、床型、面积、图片地址。预订订单模型是整张表里最关键的设计，字段至少包含订单编号、用户外键、房间外键、入住日期、退房日期、入住人数、订单金额、下单时间、订单状态，其中状态字段用数字表示，比用字符串更规范：
class Order(models.Model): ORDER_STATUS = [ (0, '已提交'), (1, '已确认'), (2, '已入住'), (3, '已退房'), (4, '已取消'), ] order_no = models.CharField('订单编号', max_length=32, unique=True) user = models.ForeignKey(User, on_delete=models.CASCADE, verbose_name='用户') room = models.ForeignKey(Room, on_delete=models.CASCADE, verbose_name='房间') check_in_date = models.DateField('入住日期') check_out_date = models.DateField('退房日期') order_amount = models.DecimalField('订单金额', max_digits=8, decimal_places=2) status = models.SmallIntegerField('订单状态', choices=ORDER_STATUS, default=0) create_time = models.DateTimeField('下单时间', auto_now_add=True)这段模型设计的逻辑关键在于订单编号用独立字段生成唯一标识，而不是依赖自增主键——否则订单号一多就容易泄露业务量。入住和退房日期用 DateField 而不是 DateTimeField，因为酒店按天计费，时间精度只精确到天就够了。订单金额用 DecimalField 而不是 FloatField，浮点数计算金额会出现 0.1 + 0.2 不等于 0.3 的问题，Decimal 才能保证金额精确。最后那个 choices 参数让 Django 的 Admin 后台自动显示状态的中文含义，同时在序列化器里也能直接读出对应状态名。
2.3 Vue 端的页面结构与路由划分
前端部分按照 Vue 的路由结构来读，最容易看出系统功能全貌。一个标准的酒店预订网站前端至少包含这几个页面视图：首页展示推荐房型和最新活动，客房列表页支持按价格区间和床型筛选，客房详情页展示大图和预订表单，订单确认页核对入住信息，个人中心页查看历史订单和修改个人资料。加上登录和注册两个独立页面，整个路由表大致在 7 个视图左右。
路由守卫在这套系统里是必需的设计。酒店预订系统的特点是：游客可以浏览客房，但提交订单必须登录。所以路由表里要区分“公开页面”和“需要认证的页面”。Vue Router 的 beforeEach 钩子里写一判断，如果目标路由需要登录而本地没有 token，就强制跳转到登录页并带上 redirect 参数：
router.beforeEach((to, from, next) => { const token = localStorage.getItem('token') if (to.meta.requiresAuth && !token) { next({ path: '/login', query: { redirect: to.fullPath } }) } else { next() } })这段代码的作用是在跳转前拦截。localStorage 里的 token 是登录成功后由后端返回的 JWT 令牌，前端拿到后持久化保存。路由元信息 meta.requiresAuth 标记了哪些页面需要登录才能访问。登录成功后跳转回 redirect 参数指定的原目标地址，这样用户体验比较顺，不至于登录完又得重新找页面。
Vue 组件划分也有讲究。搜索栏、房型卡片、订单状态标签这类多处复用的元素，在源码里应该都抽成了独立组件而不是写死在页面里。页面级组件放在 views 目录，可复用组件放在 components 目录，API 请求统一封装在 api 目录下的独立文件里，而不是在页面里零散地写 axios 调用——后者代码一多就变成一锅粥。
3. 把项目跑起来：从环境准备到前后端联调
3.1 Python 与 Vue 环境配置的完整命令序列
环境搭建是卡住新手的第一道门槛。Python 版本建议使用 3.8 及以上，Vue 端需要 Node.js 14 以上。以 Windows 系统为例，完整的环境准备命令如下：
# 进入后端目录并创建虚拟环境 cd backend python -m venv venv venv\Scripts\activate # 安装依赖 pip install -r requirements.txt # 执行数据库迁移 python manage.py makemigrations python manage.py migrate # 创建后台管理员账号 python manage.py createsuperuser # 启动 Django 开发服务器 python manage.py runserver 0.0.0.0:8000每条命令都有明确目的。python -m venv venv 创建独立虚拟环境，避免把依赖装进全局 Python 里污染其他项目。venv\Scripts\activate 激活这个环境，Linux 和 Mac 上对应的是 source venv/bin/activate。requirements.txt 里列出的是 Django、DRF、djangorestframework-simplejwt、corsheaders 这类后端核心包。makemigrations 根据模型变更生成迁移文件，migrate 把迁移文件应用到数据库，这两个命令缺一不可。createsuperuser 为 Django Admin 后台创建管理员，这是管理房型和订单数据的入口。runserver 启动开发服务器，0.0.0.0 表示监听所有网卡地址，方便用手机在同一局域网内测试。
前端环境配置的命令序列要注意 Node 版本，Vue CLI 创建的项目对 Node 版本有要求。如果之前已经安装过 Vue CLI，直接用 npm run serve 启动开发服务器：
# 进入前端目录 cd frontend # 如果 package.json 没有 node_modules 目录，先安装依赖 npm install # 启动 Vue 开发服务器 npm run serve前端开发服务器默认跑在 8080 端口，后端跑在 8000 端口，两个服务同时运行就构成了联调环境。npm install 安装的依赖都写在 package.json 里，axios、vue-router、element-ui 或 ant-design-vue 这类 UI 组件库都在其中。安装过程如果卡在某个包上，常见原因是网络问题，换 npm 镜像源能解决大部分依赖安装失败的问题。
3.2 数据库初始化和后台管理配置
Django 默认使用 SQLite 数据库，这对毕设项目来说是合理选择。SQLite 是文件型数据库，不需要额外安装数据库服务，整个库就是一个 db.sqlite3 文件，迁移和备份都非常简单。如果毕设要求使用 MySQL，修改 settings.py 里的 DATABASES 配置并安装 pymysql 或 mysqlclient 即可，模型层代码不用改。
Django Admin 后台是这套系统的一大亮点，几乎不用额外写代码就拥有了一个后台管理系统。在 admin.py 里把模型注册进去，就能在后台维护房型、订单、用户数据：
from django.contrib import admin from .models import Room, Order @admin.register(Room) class RoomAdmin(admin.ModelAdmin): list_display = ('room_type', 'price', 'stock', 'bed_type', 'area') list_editable = ('price', 'stock') search_fields = ('room_type',) @admin.register(Order) class OrderAdmin(admin.ModelAdmin): list_display = ('order_no', 'user', 'room', 'check_in_date', 'check_out_date', 'order_amount', 'status') list_filter = ('status', 'check_in_date')list_display 指定后台列表页显示的字段，list_editable 让管理员不用进入编辑页就能直接改价格和库存，search_fields 提供搜索框，list_filter 在右侧生成筛选栏。这些配置对毕设答辩特别重要——演示时管理员在后台修改房间价格、确认订单状态，都是加分的操作展示。房间库存字段在订单确认后要同步减一，这个逻辑在视图层完成，后台只管数据维护。
3.3 跨域配置与登录认证流程
前后端分离必然遇到跨域问题。前端跑在 8080 端口，后端跑在 8000 端口，浏览器会把从 8080 访问 8000 的请求视为跨域。解决方式是安装 django-cors-headers，然后在 settings.py 里配置允许的来源：
INSTALLED_APPS = [ ... 'corsheaders', ] MIDDLEWARE = [ ... 'corsheaders.middleware.CorsMiddleware', ] CORS_ALLOWED_ORIGINS = [ 'http://localhost:8080', 'http://127.0.0.1:8080', ]CORS_ALLOWED_ORIGINS 只允许列出的域名跨域访问，比直接设置 CORS_ALLOW_ALL_ORIGINS = True 更安全。注意中间件顺序，CorsMiddleware 要放在 CommonMiddleware 前面，否则请求可能被拦截在前。
登录认证流程用的是 JWT，而不是 Django 默认的 Session。JWT 的优势是无状态，前端拿到 token 后保存在 localStorage，每次请求在 headers 里带上 Authorization 字段，后端通过验证 token 识别用户身份。对比 Session 模式需要服务端存储会话状态，JWT 对前后端分离更友好。登录接口的实现思路是接收用户名密码，用 authenticate 校验，成功后签发 access token 和 refresh token 返回给前端。前端 axios 拦截器里统一添加请求头，而不是每个请求单独写。
4. 核心业务功能实战拆解：搜索、预订与订单流转
4.1 房型搜索接口的参数设计与实现
酒店预订网站的核心入口是搜索。用户选择入住日期、退房日期和入住人数，系统返回符合条件的房型列表。这个搜索接口的设计比大多数人想象的要复杂一些，因为要处理的不只是“有哪些房型”，还要考虑“这几天哪些房型还有空房”。
最朴素的实现是写成：查所有房型，排除库存为零的，然后返回列表。这种实现不考虑日期重叠问题。实际场景是：一个房型总量有 10 间，但 7 月 10 日到 7 月 12 日这三天已经订出去 8 间，那么库存应该显示 2 间而不是 10 间。所以搜索接口要动态计算可订数量。Django 视图里用 ORM 查询可以这样组织：
def search_rooms(request): check_in = request.GET.get('check_in') check_out = request.GET.get('check_out') people = request.GET.get('people', 1) available_rooms = Room.objects.filter(stock__gt=0) rooms = [] for room in available_rooms: # 查询该房型在入住日期范围内的冲突订单 conflict_orders = Order.objects.filter( room=room, status__in=[0, 1, 2], check_in_date__lt=check_out, check_out_date__gt=check_in ) occupied = conflict_orders.count() available = room.stock - occupied if available > 0: rooms.append({ 'id': room.id, 'room_type': room.room_type, 'price': room.price, 'available': available, 'bed_type': room.bed_type, 'area': room.area }) return JsonResponse({'rooms': rooms})这段代码的关键在于日期重叠判断。一条订单和搜索区间发生冲突的条件是：订单的入住日期早于搜索的退房日期，且订单的退房日期晚于搜索的入住日期。这个条件里 check_in_date__lt=check_out 和 check_out_date__gt=check_in 两个过滤条件缺一不可。库存计算是房间总量减去冲突订单数，而不是直接读 stock 字段，因为 stock 字段表示的是房型总数而非实时余量。状态过滤 status__in=[0, 1, 2] 是把已提交、已确认、已入住的订单都算作占用，已退房和已取消的订单不占用房间。返回数据里带上 available 字段，前端就能在房型卡片上直接显示“仅剩 X 间”。
4.2 订单创建与状态流转的完整链路
用户点击“提交订单”按钮后，前端把选中的房型 ID、入住日期、退房日期提交到后端订单创建接口。后端要做三件事：校验日期合法性、计算订单金额、生成订单编号并入库。
校验日期这一步最容易翻车。入住日期必须早于退房日期，入住日期不能早于今天。这个逻辑放在前端也能做，但后端必须再校验一次——绕过前端直接调接口在技术上很容易实现，后端不做校验就等于是裸奔。日期校验和金额计算的视图实现：
from django.utils import timezone from datetime import datetime def create_order(request): data = json.loads(request.body) room_id = data['room_id'] check_in = datetime.strptime(data['check_in'], '%Y-%m-%d').date() check_out = datetime.strptime(data['check_out'], '%Y-%m-%d').date() people = data['people'] if check_in >= check_out: return JsonResponse({'code': 400, 'msg': '入住日期必须早于退房日期'}) if check_in < timezone.now().date(): return JsonResponse({'code': 400, 'msg': '入住日期不能早于今天'}) room = Room.objects.get(id=room_id) nights = (check_out - check_in).days amount = room.price * nights order_no = 'HT' + timezone.now().strftime('%Y%m%d%H%M%S') + str(random.randint(100, 999)) order = Order.objects.create( order_no=order_no, user=request.user, room=room, check_in_date=check_in, check_out_date=check_out, order_amount=amount, status=0 ) return JsonResponse({'code': 200, 'msg': '下单成功', 'order_no': order.order_no})订单编号生成的逻辑是 前缀“HT”加时间戳加三位随机数。时间戳精确到秒，加上随机数防止同一秒内重复，这个生成策略在单机开发环境足够用。nights 的计算直接用退房日期减入住日期，得到的就是住宿晚数。订单金额等于单价乘晚数，这是最简单的计费模型，不含服务费和税费。如果毕设要求实现会员折扣，在金额计算这里加一层会员等级判断即可。
订单状态流转是答辩时容易讲清楚的功能点。状态从用户提交订单时的“已提交”开始，管理员后台确认后变为“已确认”，用户入住后变为“已入住”，退房后变为“已退房”。用户主动取消时状态变为“已取消”。状态机的每个转移都对应一个后台操作或用户操作。源码里如果实现了状态变更接口，通常是把当前订单 ID 和目标状态传入，后端更新状态字段。库存也是在这个环节变动的——订单确认时扣减库存，订单取消时恢复库存。
4.3 个人中心的订单查询与状态展示
个人中心页面的核心是当前登录用户的订单列表。后端接口返回当前用户所有订单，前端根据状态值渲染不同颜色的标签。这里的 API 设计需要区分两类用户：普通用户只能查自己的订单，管理员可以查所有订单。Django 的 queryset 过滤条件直接写成 user=request.user，就能把查询限制在当前登录用户。
订单列表接口的返回数据要把关联字段处理好。房间名称、房间图片、订单金额、入住日期、退房日期都要返回给前端。用 Django 的序列化器或者直接手工构造 JSON 都行，但要注意 N+1 查询问题。如果拿到订单列表后逐个查询关联的房间信息，订单多的时候会产生大量查询，性能明显变慢。正确做法是用 select_related 一次把外键关联对象查出来：
orders = Order.objects.filter(user=request.user).select_related('room', 'user').order_by('-create_time')select_related 的原理是生成一条 SQL JOIN 语句，把订单和关联的房间、用户一次性查出来。order_by('-create_time') 按下单时间倒序，新订单排在最前面。前端拿到数据后直接渲染列表，状态值通过一个映射表转成中文文本和标签颜色，代码可读性比在模板里写一堆 if 判断高得多。
5. 避坑指南：环境、联调、部署阶段的高频翻车现场
5.1 数据库迁移失败：模型改了但迁移文件没生成
现象：运行 python manage.py migrate 后提示 “No migrations to apply”，但数据库里明明没有对应的表。
原因：新增或修改模型后，忘记先运行 makemigrations。migrate 只执行迁移文件，不会自动扫描模型变化并生成迁移脚本。
解决：每次修改 models.py 后，先运行 python manage.py makemigrations，确认看到 “Migrations for 'hotel'” 输出，再运行 migrate。迁移报错时注意看控制台提示，如果有字段冲突会明确指出是哪张表哪个字段。
5.2 前端请求后端一直 404：URL 写错还是代理没配
现象：Vue 页面里调用 /api/rooms/ 接口，浏览器控制台报 404，页面显示不了数据。
原因：Django 路由里注册的 URL 前缀和前端请求的 URL 对不上。如果 Vue 的请求地址写了 /api/rooms/，但 Django 的 urlpatterns 里只有 rooms/ 没有加 api 前缀，请求自然落到 404。
解决：统一约定 API 前缀。Django 的 urlpatterns 里用 include 方式挂载 app 路由时统一加 api 前缀，前端 axios 的 baseURL 配置成 http://127.0.0.1:8000/api，两边只管理相对路径，避免硬编码拼接出错。排查时先在浏览器直接访问后端地址看返回，确认后端接口本身能用，再查前端代理配置。
5.3 跨域请求被拦截：CORS 配置没有生效
现象：前端请求后端接口，控制台报 CORS error，请求根本没到后端。
原因：三种情况。第一种是没装 django-cors-headers。第二种是装了但中间件顺序不对。第三种是 CORS_ALLOWED_ORIGINS 里写的前端地址和实际请求地址不一致，比如前端跑在 localhost:8080 但配置写的是 127.0.0.1:8080。
解决：先确认安装包在 requirements.txt 里。再看 settings.py 的 MIDDLEWARE 里 CorsMiddleware 是否排在 CommonMiddleware 之前。最后核对 CORS_ALLOWED_ORIGINS 的地址是否与浏览器地址栏完全一致。开发阶段图省事的话临时改成 CORS_ALLOW_ALL_ORIGINS = True 排错，上线前再收紧。
5.4 JWT 登录成功后请求仍返回 401：token 没有正确附加到请求头
现象：登录接口正常返回 token，但访问订单列表接口返回 401 Unauthorized。
原因：前端没有把 token 放到 Authorization 请求头里。Django 的 JWT 认证默认从 HTTP 头里取 Bearer Token，前端没有设置这个头，后端认为请求未认证。
解决：在 axios 请求拦截器里统一附加 token：
axios.interceptors.request.use(config => { const token = localStorage.getItem('token') if (token) { config.headers.Authorization = `Bearer ${token}` } return config })保存 token 时要确认 key 和取值一致，获取时用了 getItem('token') 那保存时就要 setItem('token', ...)。为了避免字面量拼写错误，把 token 的存储 key 定义成常量在项目里统一引用。
5.5 日期时间不一致：数据库时间和本机时间差 8 小时
现象：订单下单时间显示比实际时间晚 8 小时，或者日期筛选查不到当天的数据。
原因：Django 的 settings.py 里 TIME_ZONE 默认是 'UTC'，USE_TZ 默认是 True，数据库存的是 UTC 时间，读取时如果不做时区转换就显示 UTC 时间。
解决：把 TIME_ZONE 改成 'Asia/Shanghai'，USE_TZ 设成 False。如果项目已经用了 USE_TZ = True，那在获取当前时间时用 timezone.now() 而不是 datetime.now()，日期字段用 auto_now_add 会自动处理时区。已经入库的错误时间数据需要写脚本批量修正。
6. 把毕设从 60 分做到 85 分：扩展成带角色权限的后台系统
前端框架选中后台管理系统往往比前台页面更容易打动答辩老师。前台酒店预订网站做得再好，本质上是浏览加下单，后台如果只是 Django Admin 自带的界面，答辩演示时就少了“权限控制”这个技术亮点。最常见的扩展方向是把 Admin 升级成独立管理界面，并实现角色权限区分——运营人员只能管理房型和订单，财务人员只能查看订单金额相关的报表，超级管理员拥有全部权限。
权限控制的后端实现有多种方案：Django 自带的 PermissionRequiredMixin、django-guardian 的对象级权限、基于角色的 RBAC 模型。对毕设项目来说 RBAC 的粒度最合适。用户表关联角色表，角色表关联权限表，权限表里定义“查看订单”“修改房型”“导出报表”等操作。定义一个权限校验的装饰器，在视图函数上标注需要的权限，校验不通过就返回 403：
def permission_required(permission_code): def decorator(view_func): def _wrapped_view(request, *args, **kwargs): if not request.user.has_perm(permission_code): return JsonResponse({'code': 403, 'msg': '无权限操作'}, status=403) return view_func(request, *args, **kwargs) return _wrapped_view return decorator这里用 request.user.has_perm 判断当前用户是否拥有指定权限码对应的权限，permission_code 的命名格式是“应用名.操作”，比如 hotel.view_order。前端路由需要根据用户角色动态生成，在 Vuex 里保存用户信息和角色列表，路由表按角色过滤后再 addRoute 动态添加。动态路由的好处是用户直接输入 URL 也访问不了无权限的页面，路由层面也做了拦截，而不是只靠后端验证。
数据统计报表是另一个值得加的模块。酒店预订系统天然的统计数据包括：每日订单量、每日营收、房型入住率、月度趋势。这些统计在后端用 ORM 的 aggregate 和 annotate 就能算出来，不需要引入额外框架。按日期分组统计订单数量：
from django.db.models import Count, Sum from django.db.models.functions import TruncDate daily_orders = Order.objects.filter( status__in=[1, 2, 3] ).annotate( date=TruncDate('create_time') ).values('date').annotate( order_count=Count('id'), total_amount=Sum('order_amount') ).order_by('date')TruncDate 把 datetime 字段截断成日期，按天分组。status__in 过滤出有效订单，已取消和已提交但未确认的订单不计入营收。values 指定分组维度，annotate 里 Count 计算订单数，Sum 计算总金额。返回的列表可以直接喂给前端的图表组件，Vue 生态里 ECharts 的折线图或柱状图都能直接用这套数据渲染。答辩时演示一个带趋势曲线的营收报表，比演示十个静态页面都更有说服力。
房间管理页面也可以做得更完整。房型日历视图按天展示每个房型的可订数量，哪天满房哪天还有余量，一眼看明白。这个视图需要后端提供一个按日期范围返回每日库存的接口，前端用表格渲染，行是房型，列是日期，单元格背景色按余量从红到绿渐变。数据量不大时这只是一个二维数组的组装问题，不需要引入复杂的前端图表库。
每一个扩展点，最终都要落回对 Django 模型、视图、序列化器和 Vue 组件、路由、状态管理的实际操练。这套毕设源码提供的核心价值是完整可用的基线——它让每个想拿高分的人不必从零写起，而是能站在一个已经跑通的前后端分离架构上，专注做增量设计和实现。从那以后，我每次接到毕设指导任务都会强制自己先跑一遍完整流程：装环境、建数据库、起服务、用前台订一单、去后台确认状态、查个人中心订单列表。走完这条链路再动手改代码，而不是一上来就埋头看源码。希望这份拆解笔记能帮你少走这段弯路，把时间花在真正拉分的地方。
本文还有配套的精品资源，点击获取
