基于Python Django与Vue的宾馆客房管理系统设计与实现

前阵子帮一家小型宾馆做了一套客房管理系统，后端用 Python，前端配 Vue，整体开发周期两周，从 Pycharm 里把环境搭起来到上线，效率比我预想的高不少。这两年问我要这套系统源码的人一直没断过，今天抽空把这套系统的技术选型、数据库设计、核心模块实现和踩坑记录完整梳理一遍，给准备做类似管理系统的同学一个可以直接抄的作业。

这套系统解决的问题很明确：宾馆前台每天要处理客房状态查询、客人预订登记、入住退房、押金管理和账单结算，如果全靠纸质笔记本或者 Excel，高峰期一对准夫妻同时开三间房，前台能忙到起飞。系统化之后，房态一眼可见，客人信息自动归档，账单自动计算，报表一键导出，对小宾馆来说已经是生产力级别的提升。

适合参考的人群：有 Python 和 Vue 基础，想做一个完整的全栈项目练手，或者确实有宾馆、民宿管理需求打算自建系统的朋友。这篇内容既有架构思路，也有可直接复现的代码片段和避坑提示。文章里我会以 Django 为主线讲，同时在关键节点把 Flask 的实现差异也点出来，两条技术路线你都能对上号。

1. 项目整体设计与技术选型思路

1.1 为什么后端选了 Python 而不是 Java 或 Node

接到这个需求的时候，我第一反应就是 Python。原因很简单：这类管理系统是典型的 CRUD 密集型业务，核心操作无非是查房间、加预订、改状态、算账单，没有复杂的并发计算，也没有海量数据要处理，Python 的开发和迭代速度在这种场景下优势非常明显。

换成 Java 的话，光 Spring Boot 的起步依赖、环境配置和编译部署就能吃掉两三天时间，而且小宾馆的管理系统未来大概率要加各种小功能，Python 改起来快，热更新也方便。Node 也能做，但 Python 在数据处理和后续可能的进销存扩展上更有优势，尤其是后面对接报表统计、导出 Excel、甚至跑点数据可视化分析，Python 生态里的 pandas、openpyxl、matplotlib 都是现成的。

另外还有一个实际考虑：Python 招人容易，或者说懂点 Python 就能接手这个项目。宾馆老板找本地外包维护，十有八九找回来的还是写 Python 的，技术栈太冷门后面维护都是麻烦。

1.2 Django 和 Flask 怎么选，别纠结

这个项目我最开始用 Flask 写了一个 demo，后来又用 Django 重构了一遍，两套我都跑通了，说说我的实际感受。

我的建议很简单：如果是做一个完整体面的管理系统，直接用 Django，省掉很多重复造轮子的时间。尤其是管理后台，Django Admin 几乎是零成本帮你搞定了一套数据维护界面，对内部管理系统来说非常香。如果你只是做一个纯 API 服务，前端完全独立，后台逻辑很轻，那 Flask 更合适，跑起来轻巧，部署也省事。

1.3 前端为什么搭配 Vue

管理系统的前端不像 C 端产品那样追求花哨交互动效，但也不意味着可以随便拿服务端模板渲染糊弄。Vue 在这个项目里的价值主要有三个：组件化开发让表单、列表、弹窗这些高频复用模块的维护成本大幅降低；响应式数据绑定让房态实时刷新这种功能写起来很自然；基于 Vue Router 和 Vuex/Pinia 的单页应用体验比传统的 JSP 模板爽太多。

尤其要提的是房态操作这个细节：以前传统多页应用改完一间房的状态要刷新整个页面才能看到结果，Vue 改一行数据就能让网格视图里的房间卡片当场变色，这个交互反馈对前台人员来说提升非常明显。

还有一个现实因素：Vue 在国内的社区活跃度最高，遇到问题搜解决方案最容易，团队招人也相对容易。这个项目前端就用 Vue 3 + Element Plus + Axios，整体开发体验很顺。

1.4 整体架构与数据流

系统采用前后端分离架构，这是目前主流的做法。前端是 Vue SPA，部署在 Nginx 上，通过 HTTP 调用后端 API；后端是 Django REST Framework，提供 JSON 格式的接口；数据库用 MySQL（SQLite 也可以用于开发测试）。

整体数据流大概是这样的：前端登录获取 Token，每次请求带上 Token，后端鉴权后处理业务逻辑，操作数据库，返回结果给前端渲染。预订、入住、退房这些核心流程都是这个模式。

做这套架构的时候最核心的设计思路是：把房间状态变更做成单一数据流。换句话说，不管前台是手动改房态、还是通过预订/退房流程触发变更，最终都只通过后端同一个状态更新接口来落库，避免出现不同入口改出互相矛盾的数据。这个设计在后文讲具体实现时会再展开。

2. 环境准备与项目骨架搭建

2.1 Pycharm 的选择和工程配置

工欲善其事必先利其器，Python 开发我还是推荐 Pycharm。这个项目用的是 Pycharm 2023.3 版本，专业版和社区版都行。专业版的好处是自带 Database 工具、Django/Flask 的专用支持，调试接口也方便；社区版虽然是免费的，但装插件也能凑合出大部分体验。如果只是学习或者学生身份，专业版免费申请也是可以的。

我的工程目录按这样的结构组织：

code复制guesthouse/
├── backend/                # Django 后端项目
│   ├── manage.py
│   ├── guesthouse/         # 项目配置目录
│   ├── apps/
│   │   ├── rooms/          # 房间管理模块
│   │   ├── orders/         # 订单模块
│   │   ├── customers/      # 客户模块
│   │   └── accounts/       # 用户认证模块
│   └── requirements.txt
├── frontend/               # Vue 前端项目
│   ├── src/
│   │   ├── api/            # 接口请求封装
│   │   ├── views/          # 页面组件
│   │   ├── router/         # 路由配置
│   │   └── store/          # 状态管理
│   └── package.json
└── README.md

2.2 虚拟环境别直接装全局，坑不少

很多人上来就在全局环境里 pip install django，这是我不推荐的。Python 项目最怕的就是依赖冲突，一个项目要 Django 3 一个要 Django 5，装在同一台机器上必炸。虚拟环境相当于给每个项目一个独立的集装箱，互不干扰。

创建虚拟环境命令很简单：

bash复制cd backend
python -m venv venv
# Windows 激活
venv\Scripts\activate
# Mac/Linux 激活
source venv/bin/activate

激活之后你会发现命令行前面多了个 (venv) 前缀，这就说明当前在虚拟环境里了。

激活后安装依赖：

bash复制pip install django djangorestframework django-cors-headers mysqlclient

生成 requirements.txt 方便后面部署：

bash复制pip freeze > requirements.txt

Flask 版本的话，安装 flask flask-sqlalchemy flask-restful flask-cors 这些包，用法类似。值得注意的是，我遇到过很多次虚拟环境创建在默认 C 盘用户目录下导致权限问题的案例，建议直接把 venv 建在项目目录内，这样迁移的时候跟着项目走，也不会有权限坑。

2.3 数据库设计：先把表关系捋清楚

数据库是这类管理系统的根基，表设计不好后面全是泪。我最初那版设计把房间和订单揉在一张表里，结果查一个客人住过几次房要写一堆循环，后来老老实实拆开，清爽很多。

这个项目最终的表结构设计如下：

订单状态我用了几个常量来标识状态流转，这也是管理系统最常见的设计模式：

• 0：待入住（已预订）
• 1：已入住
• 2：已退房
• 3：已取消

这里有一个细节想多说一句：客户表为什么要单独建，而不是直接记到订单表里？因为有回头客，他第二次来入住的时候，前台只需要输入手机号就能调出上次的证件信息和偏好，体验加分不少。所以客户表承担了类似于会员档案的职责。

2.4 Vue 前端环境配置

Vue 前端的搭建用 Vite 是最省事的。你要是在浏览器地址栏输入 npm create vue@latest 直接能进入交互式脚手架生成项目。或者手动跑：

bash复制npm create vite@latest frontend -- --template vue
cd frontend
npm install
npm install axios element-plus vue-router pinia

这几个包分别负责 HTTP 请求、UI 组件库、路由和状态管理。安装完用 npm run dev 启动开发服务器，默认端口一般是 5173。

要注意前后端联调时 Vite 默认端口和后端 Django 的 8000 端口不同，这样会碰到跨域问题，这个我在第 4 章会专门讲怎么处理。

3. 核心功能模块与实操实现

3.1 房间管理模块：状态流转是关键

房间管理是整个系统最基础也最核心的模块。一张房态图里每个房间卡片显示房号、房型、价格和当前状态，状态分为空闲、已预订、已入住、维修中。前端用不同颜色区分，后台用状态字段区分。

房间状态字段我用的是：

python复制# models.py
class Room(models.Model):
    STATUS_CHOICES = (
        ('idle', '空闲'),
        ('booked', '已预订'),
        ('occupied', '已入住'),
        ('repair', '维修中'),
    )
    room_no = models.CharField('房号', max_length=10, unique=True)
    room_type = models.ForeignKey(RoomType, on_delete=models.PROTECT, verbose_name='房型')
    floor = models.IntegerField('楼层', default=1)
    status = models.CharField('状态', max_length=10, choices=STATUS_CHOICES, default='idle')
    remark = models.CharField('备注', max_length=200, blank=True)

这个模块我犯过一个错误：一开始直接用前端传过来的 status 字段无脑更新数据库，结果出现了很大的数据一致性问题——比如 A 台电脑把房间改成“已入住”的同时，B 台电脑又把它改成“空闲”，前台两张图，看着都觉得自己没做错。

后来我改了设计：状态变更不直接接收任意值，而是通过专用接口做状态迁移，后端校验合法性。举个例子，只有“空闲”或“已预订”的房间才能完成“入住”操作，只有“已入住”的房间才能“退房”，中间的非法跳转直接拒绝并返回错误信息。这个思路说白了就是状态机思想，不要给前端太多的自由度，数据库的完整性才靠得住。

3.2 预订与入住流程：用订单贯穿整个生命周期

预订流程是这样的：前台选择房型 -> 系统列出可用的具体房间 -> 填写客人信息 -> 提交订单（状态为“待入住”）-> 客人到店后点“办理入住” -> 订单状态变“已入住”，房间状态变“占用”。

订单表的核心模型：

python复制class Order(models.Model):
    STATUS_CHOICES = (
        (0, '待入住'),
        (1, '已入住'),
        (2, '已退房'),
        (3, '已取消'),
    )
    order_no = models.CharField('订单号', max_length=32, unique=True)
    customer = models.ForeignKey(Customer, on_delete=models.PROTECT, verbose_name='客户')
    room = models.ForeignKey(Room, on_delete=models.PROTECT, verbose_name='房间')
    check_in_date = models.DateField('入住日期')
    check_out_date = models.DateField('退房日期')
    deposit = models.DecimalField('押金', max_digits=10, decimal_places=2, default=0)
    status = models.IntegerField('状态', choices=STATUS_CHOICES, default=0)
    created_at = models.DateTimeField('创建时间', auto_now_add=True)

这里有个问题我花了不少时间思考：为什么不直接根据订单一对一找到房间状态，而还要冗余一个房间状态字段？答案是性能。房态总览页要展示几十上百个房间，如果每个房间都要去 join 订单表才能算出“这个房间目前是什么状态”，查询会很重。房间表自身冗余一个 status 字段，配合订单表的状态，两者通过事务保持同步，查询时就一个纯单表查询，速度极快。

订单号的生成我当时也花了一点心思。早期用自增 id 直接做订单号，但前台看着不专业，而且容易暴露真实的订单量（同行竞对很容易摸清底细）。后来生成规则：yyyyMMdd + 6位随机数字，比如 20250614083201，既好看又能防止猜测，生成冲突的概率低到可忽略。生成时加个去重校验，万一碰撞就重新生成。

预订接口的核心逻辑伪代码：

python复制def create_order(request):
    room_id = request.data.get('room_id')
    check_in_date = request.data.get('check_in_date')
    check_out_date = request.data.get('check_out_date')

    # 校验房间是否存在且可用
    room = Room.objects.filter(id=room_id, status='idle').first()
    if not room:
        return Response({'error': '该房间不可预订'}, status=400)

    # 校验日期冲突（同一房间不能重复预订同一时间段）
    conflict = Order.objects.filter(
        room=room,
        check_in_date__lt=check_out_date,
        check_out_date__gt=check_in_date,
        status__in=[0, 1]
    ).exists()
    if conflict:
        return Response({'error': '该时间段已被预订'}, status=400)

    # 业务计算
    days = (check_out_date - check_in_date).days
    total_price = days * room.room_type.base_price

    # 创建订单、更新房间状态（用事务保证一致性）
    with transaction.atomic():
        order = Order.objects.create(
            order_no=generate_order_no(),
            customer=...,
            room=room,
            ...
            total_amount=total_price
        )
        room.status = 'booked'
        room.save()
    return Response({'order_no': order.order_no, 'total_amount': str(total_price)})

注意这段代码里日期的冲突判断逻辑：check_in_date__lt=check_out_date, check_out_date__gt=check_in_date，这个交叉区间判断能够覆盖两个时间段重叠的所有情况，是新老订单时间冲突检测的关键。

3.3 退房与账单结算：把费用的账算明白

退房时的费用结算是整个系统里最容易出纠纷的地方，所以在做这套逻辑时我参考了几家宾馆的线下规则，把计算方法尽量做通用一点，同时允许管理员在系统配置里自定义规则。

房费计算规则是：默认按天计费，一天的定义是中午 12 点到第二天中午 12 点；超过 12 点退房的，加收半天房费；超过 18 点退房的，加收全天房费。这个逻辑需要在后端用一个独立的函数实现，而不是看前端传什么就是什么，避免前台手工改金额扯皮。

python复制def calc_room_fee(order, actual_check_out_time):
    base_price = order.room.room_type.base_price
    plan_out = order.check_out_date  # 计划退房日
    actual_out = actual_check_out_time.date()
    nights = (actual_out - order.check_in_date).days

    total_fee = base_price * nights

    # 超时判断：退房日是否超过了计划退房日
    if actual_out > plan_out:
        # 超过计划日期的部分，按当天是否过12点/18点加收
        hour = actual_check_out_time.hour
        extra_days = 0
        if hour < 12:
            extra_days = 0
        elif hour < 18:
            extra_days = 0.5
        else:
            extra_days = 1
        total_fee += base_price * extra_days

    return total_fee

这类计算逻辑必须用单元测试覆盖，因为边界条件非常多，今天不加明天改需求，必被坑到。我当时写了整 15 个测试用例，覆盖一般入住、跨天入住、超时退房、连住多天等场景，好加才放心上线。

押金管理也有说法：入住时收押金，退房时如果房间设施无损，押金全额退回；如果有额外消费（比如小冰箱的饮料、损坏赔偿），从押金里扣除。账单表里我加了一个 item_list 字段用来存消费明细，格式是 JSON 字符串，比如 [{"item": "可乐", "price": 8, "num": 2}, {"item": "毛巾赔偿", "price": 20, "num": 1}]，这样账单就是可以追溯的，每一笔扣款对客人都有交代。

3.4 统计报表：老板最关心的实时数据

系统还做了统计模块，主页显示四张卡片：今日入住率、今日营收、在住房间数、待处理订单数。这个模块前端用了 ECharts 来画图表，后端提供聚合统计接口。

Django 的 ORM 聚合查询用来做这类统计非常方便，比如按房型统计未来七天的入住率：

python复制from django.db.models import Count

def room_type_occupancy(request):
    stats = []
    room_types = RoomType.objects.all()
    for rt in room_types:
        total_rooms = rt.room_set.count()
        # 统计当前状态为 已入住 且房型为该类型的房间数
        occupied = rt.room_set.filter(status='occupied').count()
        stats.append({
            'type_name': rt.type_name,
            'total': total_rooms,
            'occupied': occupied,
            'rate': round(occupied / total_rooms * 100, 2) if total_rooms else 0,
        })
    return Response(stats)

这个模块看似简单，但实际帮老板做了挺多决策参考。比如入住率低的时候，他会主动来看哪几个房型的空置率高，然后考虑优惠促销；周末高峰期也会根据数据安排更多保洁人手。系统能不能用起来，很大程度就看这种一眼懂的数据页面做得够不够好。

4. 前后端联调与常见问题排查

4.1 跨域问题：第一次联调被卡半小时

前后端分离项目第一个遇到的坑基本就是跨域。我用 Vue 的 dev server 跑在 5173 端口，Django 跑在 8000 端口，浏览器直接拦截了前端的跨域请求，控制台一片红色报错。

解决方案是后端开启 CORS。Django 下安装 django-cors-headers：

python复制# settings.py
INSTALLED_APPS = [
    ...
    'corsheaders',
]

MIDDLEWARE = [
    'corsheaders.middleware.CorsMiddleware',
    ...
]

CORS_ALLOWED_ORIGINS = [
    'http://localhost:5173',
    'http://127.0.0.1:5173',
]

Flask 下用 flask-cors：

python复制from flask_cors import CORS
CORS(app)

我建议生产环境不要图省事直接 CORS_ALLOW_ALL_ORIGINS = True，那样等于给任何网站都能调用你的接口留了口子，尤其是涉及客户身份证数据的系统，安全这块不能马虎。把允许的域名列表写明确，后面维护也清楚。

4.2 接口统一返回格式和鉴权设计

前后端联调时最容易出现的问题之一就是接口返回格式不统一。一会儿返回 {data: ...}，一会儿返回 {message: ...}，前端解析逻辑就得写一堆 if else。我的做法是在后端封装一个统一的 Response 结构：

python复制def success(data=None, message='success'):
    return Response({
        'code': 200,
        'message': message,
        'data': data
    })

def error(message='error', code=400):
    return Response({
        'code': code,
        'message': message,
        'data': None
    }, status=code)

这样前端 Axios 请求拦截器里统一处理 code === 200 的场景，其他情况直接弹出 message 提示，业务代码里就完全不用每个接口都做错误分支判断了。

鉴权这块我用的是 JWT，Django 下配 simplejwt 或者 djangorestframework-simplejwt 都很方便。前台员工登录后拿到 Token，存到 localStorage 或者 Pinia 里，之后每次请求在 Header 里带上：

javascript复制axios.interceptors.request.use(config => {
    const token = localStorage.getItem('token')
    if (token) {
        config.headers.Authorization = `Bearer ${token}`
    }
    return config
})

为什么不用 Django 自带的 session 鉴权？因为前后端分离之后，Session 依赖 Cookie 的机制比较绕，而且 JWT 是纯接口调用，对不同端的适配更好。有些同学还在纠结要不要开发一个注册功能，我的建议是管理系统不要开放注册，账号由管理员在后台直接创建，权限上也细分一下角色，前台人员可以操作房间和订单，但只有老板和管理员能看财务报表和系统设置。这个权限隔离在客户数据敏感的行业尤其重要。

4.3 常见报错和解决方案速查

整理一下我在开发和调试这套系统时遇到的几个高频问题和解决办法，基本覆盖了绝大多数新手会踩的坑。

除了上面这些，还有一个让我印象很深的问题：MySQL 数据库连接报 table 'xxx' doesn't exist，但我明明用 Django 的 migrate 成功迁移了表。后来排查发现是 Django settings 里配置的数据库名跟实际连接的不是同一个库，因为 DATABASES 配置里 NAME 写错了环境。这类基础配置问题排查起来特别耗时间，我的经验是遇到数据库相关报错先检查配置信息是不是跟实际环境对得上，不要急着看业务代码。

4.4 使用 Pinia 管理全局状态

Vue 前端我用 Pinia 管理全局状态，主要存两部分数据：一是当前登录用户的信息（用户名、角色），二是房态总览的数据缓存。

第一个非常好理解，登录成功后塞一份到 store，顶部导航的欢迎语、操作按钮的权限控制都从 store 里取。第二个是优化点：房态总览进入页的时候请求一次所有房态，当前台用户在前台页做了某个操作后，不用重新请求全量房态，只需要本地把该房间的状态字段改掉，页面秒刷新。

javascript复制// store/room.js
export const useRoomStore = defineStore('room', {
    state: () => ({
        rooms: []
    }),
    actions: {
        async fetchRooms() {
            const res = await api.get('/rooms/')
            this.rooms = res.data
        },
        updateRoomStatus(roomId, status) {
            const room = this.rooms.find(r => r.id === roomId)
            if (room) {
                room.status = status
            }
        }
    }
})

这个模式用了之后，前台操作的响应速度体感快了很多，不用每个操作都等接口返回后再刷新列表。不过我加了一个兜底逻辑：所有写操作成功后还是会触发一次后台静默刷新，只是这次刷新不对用户展示 loading，避免极端情况下本地状态和后端不一致。

5. 部署上线与后续扩展

5.1 项目打包部署方案

开发完成后要上线给宾馆实际使用，部署方案不需要太复杂，一个小型服务器就够了，我的方案是 Nginx + Gunicorn + Django + MySQL，前端打包成静态文件交给 Nginx 托管。

前端打包：

bash复制cd frontend
npm run build

产物在 dist 目录下，把它传到服务器 Nginx 的 html 目录即可。

后端部署：

bash复制pip install gunicorn
gunicorn guesthouse.wsgi:application --bind 0.0.0.0:8000 --workers 3

Nginx 配置里把 /api/ 前缀的请求反向代理到 Django，其他请求直接访问前端静态文件。这样一套下来，不需要额外开一个前后端分离的架构，访问同一个域名端口，既安全又省资源。

如果想懒省事一点，也可以直接 Docker Compose 编排，把 MySQL、后端、前端、Nginx 分别做成四个容器，一条 docker compose up -d 全部搞定。如果你之前用 Flask 写过博客或者小项目，这种做法应该很熟悉。对小型管理系统来说，容器化虽然稍有学习成本，但好处是迁移部署非常方便，换服务器不用重新配环境，docker compose 一把梭。不过我还是想提醒一下，Docker 部署至少要有基础的镜像构建概念，如果你之前连 Linux 命令都不熟，老老实实用 Nginx + Gunicorn 的方式其实更稳，毕竟这类小系统也不会频繁迁移。

5.2 系统可扩展的方向

这套系统做完上线后，客户在用的过程中又提了不少需求，有几个我觉得很值得扩展：

• 多门店支持：在现有表上增加 store 字段，房态、订单、报表都按门店维度做隔离，适合连锁民宿或宾馆。
• 小程序/公众号订房入口：C 端客人能自己在线看房、订房，后台只需多开一套 API 给小程序端调用，前端复用现有逻辑。
• 对接身份证读卡器：宾馆办理入住按规定需要登记身份证信息，如果桌面上放一个身份证读卡器，通过 USB 读取姓名、证件号自动填入系统，能省前台大量录入时间。这个需求虽然不算技术难度有多高，但对宾馆的实际效率提升非常明显。
• 经营数据分析面板：把订单数据按月、按周做同比环比分析，展示 RevPAR（每间可售房收入）、平均房价、出租率等酒店行业核心指标。这个部分用 Python 的 pandas 做离线分析，渲染到 Vue 前端的大屏上。
• 对接门锁系统：通过蓝牙或无线模块把退房后的虚拟房卡发送到客户手机，实现无前台自助入住。这个属于硬核扩展，需要跟门锁厂商对接协议，但也是目前智慧酒店的大趋势。

我觉得这套系统后续最值得做的是小程序端。微信小程序的订房入口对客人来说使用习惯最自然，而且开发小程序后不需要额外推广，只需在前台放个二维码，住过的客人扫码就能下次直接预订，复购率提升明显。后端 API 只要把现有的 DRF 接口加上小程序的登录逻辑即可，前端复用一套 Vue 代码基础的判断逻辑，开发周期不会超过一周。

5.3 Flask 版本的实现差异对照

如果你决定用 Flask，有几个地方跟 Django 的实现逻辑有区别，我简单列一下核心差异：

• ORM：Django 用自带 ORM，Flask 一般配 SQLAlchemy。模型定义语法略有不同，但基本概念一致，映射关系手动写 db.Column 和 db.relationship。
• 迁移：Django 的 migration 是自动生成的，SQLAlchemy 需要配 Alembic 或者 Flask-Migrate。
• Admin：Django Admin 自带后台可以直接改数据，Flask 要装 Flask-Admin，定制程度更高但配置量也更大。
• 路由：Flask 用装饰器 @app.route('/rooms')，Django 用 urlpatterns 配置，从开发体验上来说我喜欢 Flask 一点，每个接口跟函数绑定非常直觉。

其实如果你只是做一个管理系统，没有特殊原因我就建议直接 Django，少踩很多自己拼模块的坑。我的 Flask 版本最后是因为客户要加一个复杂的统计报表，写 SQLAlchemy 底层查询查询时感到明显不如 Django ORM 顺手。当然，这也有个人使用习惯的因素而已。

写在最后

做了这么多管理系统，我个人最大的体会是：技术的难点其实不在某个框架怎么用，而在于你怎么把一个线下业务流程抽象成清晰的数据模型。宾馆客房管理系统的核心就是房间状态和订单状态的流转设计，把这一步想清楚，后面的代码只是堆体力。

当时我踩过比较大的一个坑就是上面反复提到的状态更新入口不统一的问题，前前后后花了差不多一天的时间整理状态链路才理顺。后来我把这类系统的状态流转设计成一个通用的状态机组件，再遇到其他类似场景就能直接复用了，这种积累才是做项目真正的收获。

另外想掏心窝子说一句：能看到这里的同学，大概率是想把它当毕业设计或者练手项目的。如果你只是交作业，那就老老实实把 Django + Vue 这套完整跑通，每行代码都自己敲一遍，面试聊到项目时才不会心虚。不管怎么样，把这篇文章收藏起来，做的时候拿出来对照，比网上那些零散的教程要省心得多。有卡住的地方，欢迎评论区留言，我看到都会回复。