Flask+Vue前后端分离酒店管理系统开发实战与权限设计

先说明一点，这套"三个角色的酒店管理系统"我前后做过两个版本，第一版用 Django 模板渲染，第二版改成 Flask 提供接口、Vue 做页面，也就是标题里提到的那一套组合。整个过程踩了不少坑，也把 Flask 和 Django 的异同想得更清楚了。下面这篇文章不是课程式的贴代码，而是把我从选型、建模、写接口、接前端到排错的全过程摊开讲，适合正在做课设、或者第一次接触前后端分离管理系统的人参考。

1. 一个标题里的三笔糊涂账：先理清技术选型再动手

1.1 Flask 和 Django 到底怎么选

标题里同时出现 flask 和 django，很多人会以为它们是一起用的。不是，这两者通常是二选一，都是 Python 的 Web 框架，但设计哲学差别挺大。

Django 是"全家桶"，自带 ORM、Admin 后台、表单处理、认证系统，约定大于配置，适合内容管理、后台管理系统这种功能性很强的项目。Flask 是"微型框架"，只提供最核心的路由和请求响应机制，数据库、表单、认证全靠第三方扩展，比如 SQLAlchemy、Flask-Login、Flask-JWT-Extended。它的好处是灵活、轻、代码完全可控，坏处是一切都要自己拼。

我的建议是：如果项目要求你输出数据库设计文档、接口文档、并且前端页面要自己做交互，用 Flask 更合适。为什么？因为 Flask 不会替你做太多事情，路由、模型、权限这些核心逻辑你都得亲手写一遍，你反而更容易把系统内部结构讲清楚。Django 的 admin 和自动 CRUD 虽然好用，但演示的时候别人一看就知道是 Django 自带后台，缺乏"你亲手实现"的说服力。

另外还有一个实际原因：Django 带着模板引擎，很多人做管理系统习惯用模板渲染页面，前后端代码混在一起，一旦涉及 Vue 这种前端框架就束手束脚。题干同时出现 vue，说明你要做的是前后端分离，这种情况下 Flask 只负责出 JSON 接口，和 Vue 配合反而干净利落。所以后端框架我最终选了 Flask。

1.2 PyCharm 在这个项目里扮演什么角色

PyCharm 不是框架，是 IDE，也就是写代码的工具。用它不是因为它能提升 Flask 性能，而是因为调试、虚拟环境管理、数据库连接这些环节它都集成好了，省了很多事。

这个项目里我主要用到了 PyCharm 的几个能力：第一，创建虚拟环境（Virtualenv），Python 项目最忌讳依赖混乱，每个项目独立环境是基本素养；第二，Flask 项目的运行配置，直接在 Run Configuration 里指定 FLASK_APP 和 debug 模式，不用在终端手敲一堆命令；第三，数据库工具窗口，可以直接查看 MySQL 数据表内容，调试接口返回结果时特别有用，不用来回切工具。

有一点很多人容易误会：PyCharm 的 Community 免费版其实也够用，不需要专业版。专业版的 Flask/Django 项目模板确实方便，但 Community 版新建普通 Python 工程、装依赖、配运行方式，一样可以完整跑通这个项目。

1.3 前后端分离的项目长什么样

先说架构。Flask 负责的是 /api/auth/login、/api/room/list 这类 JSON 接口，Vue 负责登录页面、管理后台页面、预订页面，浏览器里跑的是纯前端代码，页面里的数据通过 axios 请求后端接口获取。两者通过 HTTP 通信，开发时前端用 Vite 代理解决跨域，生产环境可以把 Vue 打包后的静态文件交给 Flask 托管。

我对比过模板渲染和前后端分离两种方案的感受。模板渲染版本里，页面跳转、数据渲染、权限判断都挤在 Flask 层，逻辑是能跑，但一旦页面复杂，Jinja2 模板很快就变得很难维护。Vue 版本里，前端把数据状态管起来了，比如"当前登录用户是谁"存到状态管理器里，路由守卫判断能不能进某个页面，后端只管校验 token 和角色，两边各司其职，开发体验完全不一样。

代价是工作量变大，你要同时维护两套代码，还要解决跨域、token 刷新、接口协议统一这些问题。后面我会详细讲具体做法。

2. 三个角色对应三套权限：先把业务模型画明白

2.1 角色定位与核心功能清单

任何管理系统，开发第一步不应该是写代码，而是把角色和权限理清楚。我做的这套系统里有三个角色：

• 管理员（admin）：管员工账号，管房间价格，查看全系统订单和统计报表，是最高权限。
• 前台员工（staff）：查看房间状态，办理入住登记、退房、为客人下单，管理到店客人的信息。
• 客人（guest）：注册、登录、在线预订房间、查看自己的订单、取消未入住订单。

这个权限划分不是随意定的，而是参考了真实酒店前台的运作流。客人到前台，前台需要能快速查到哪间房空着、什么价格，然后开单；客人线上预订，则要能看到可订房间并下单。两边的操作面会有重叠，比如"查看房间状态"员工和客人都要能看，但"改价格"这种操作只有管理员能做。

我用一句话概括这个模型：角色 = 身份的标签，权限 = 该角色能访问的接口集合。前端负责控制"看得到什么"，后端负责控制"能执行什么"。前端权限只是用户体验层面，后端权限才是安全底线，这一点后面还会再强调。

2.2 数据库设计：六张表撑起整个系统

这个项目我设计的数据库不复杂，核心就六张表，我把它们列出来，字段都是实际跑通过的：

表结构有个设计细节值得说：users 表必须把 password_hash 存进去，绝对不能存明文密码。我用的是 werkzeug.security 提供的 generate_password_hash 和 check_password_hash，Flask 生态里这是默认做法。

房间状态这个字段要单独留意，我遇到过并发问题，后面有一章专门讲。

orders 表里要保留一个快照字段，比如下单时的房价。为什么？因为房价可能调价，订单生成之后就应该按照下单当天的价格结算，而不是按照当前房间价格，否则客人就会困惑。这是数据建模里容易忽略但业务上非常重要的一点。

2.3 角色和权限的本质：谁在什么条件下能做什么

权限设计的核心问题不是"哪个角色能进哪个页面"，而是"哪个角色能调哪个接口"。我按这个思路整理接口权限：

• auth：登录、注册、个人信息，所有角色共用。
• 房间管理：查看列表所有角色可用；新增、修改、删除只有管理员可用；状态变更加床、退房标记，员工和管理员可用。
• 订单管理：创建订单员工和管理员可用，客人在线预订走单独接口；取消订单，客人只能取消自己的，员工可以操作全部到店订单。
• 用户管理：重置密码、禁用账号，只有管理员可用。

这套规则落到代码上，就是给每个接口加角色校验装饰器，后面我会给出具体实现。落到前端上，就是路由表的 meta 里声明 roles，Vue Router 的守卫去拦截。

有一句经验我特别想分享：不要把权限判断写成 if 套 if 散落在各种地方，一定要统一封装。后端写一个 role_required 装饰器，前端写一个全局守卫函数，两边各管各的，后面要换角色或者加角色，只需要改声明处，不用满项目找判断逻辑。

3. 后端接口设计：Flask 蓝图的舞台

3.1 项目目录结构和蓝图注册

Flask 项目如果全写在一个 app.py 里，前期几十行看着爽，后面几百行就灾难了。我用蓝图的模式拆成模块，目录结构大概这样：

hotel_flask/ ├── app/ │ ├── __init__.py # 创建 Flask 实例，注册蓝图和扩展 │ ├── auth/ │ │ ├── __init__.py │ │ └── views.py # 登录、注册接口 │ ├── admin/ │ │ ├── __init__.py │ │ └── views.py # 管理员专属接口 │ ├── staff/ │ │ ├── __init__.py │ │ └── views.py # 前台业务接口 │ ├── booking/ │ │ ├── __init__.py │ │ └── views.py # 客人预订、订单接口 │ ├── models/ │ │ └── models.py # SQLAlchemy 模型 │ └── utils/ │ ├── auth_utils.py # 角色装饰器 │ └── response.py # 统一返回格式 ├── config.py # 数据库、密钥等配置 ├── requirements.txt └── run.py

蓝图的好处是按业务域隔离代码，auth、admin、staff、booking 互不干扰。注册方式很简单：

from flask import Flask from app.auth.views import auth_bp from app.admin.views import admin_bp from app.staff.views import staff_bp from app.booking.views import booking_bp app = Flask(__name__) app.register_blueprint(auth_bp, url_prefix="/api/auth") app.register_blueprint(admin_bp, url_prefix="/api/admin") app.register_blueprint(staff_bp, url_prefix="/api/staff") app.register_blueprint(booking_bp, url_prefix="/api/booking")

这样一来，接口地址天然带上了模块前缀，比如 /api/auth/login、/api/admin/users，调试和阅读代码时定位意图非常快。这里要给新手一个忠告：蓝图不是越多越好，业务边界明确的场景才用，我这个系统的角色划分正好天然适合这种拆法。

3.2 模型层与序列化：SQLAlchemy 的使用细节

Flask 官方推荐的数据库操作方式是 Flask-SQLAlchemy。模型定义看起来像这样：

from flask_sqlalchemy import SQLAlchemy from werkzeug.security import generate_password_hash, check_password_hash from datetime import datetime db = SQLAlchemy() class User(db.Model): __tablename__ = 'users' id = db.Column(db.Integer, primary_key=True) username = db.Column(db.String(64), unique=True, nullable=False) password_hash = db.Column(db.String(255), nullable=False) role = db.Column(db.String(16), nullable=False, default='guest') # admin/staff/guest real_name = db.Column(db.String(64)) phone = db.Column(db.String(20)) created_at = db.Column(db.DateTime, default=datetime.now) def set_password(self, password): self.password_hash = generate_password_hash(password) def check_password(self, password): return check_password_hash(self.password_hash, password) def to_dict(self, with_token=False): data = { 'id': self.id, 'username': self.username, 'role': self.role, 'real_name': self.real_name, 'phone': self.phone, 'created_at': self.created_at.strftime('%Y-%m-%d %H:%M:%S') } return data

三个角色共用一张 User 表，用 role 字段区分，这是我反复权衡后的选择。起初我考虑过管理员、员工、客人各建一张表，最后否了。原因有两个：一是登录认证只查一张表，逻辑最简单，token 里塞 user_id 和 role 就够了；二是真实业务里管理员和员工本质都是"内部人员"，分开建表反而制造麻烦。客人单独建表的好处是字段可以更宽松，但代价是登录要区分两张表，非要把简单的事搞复杂，不值。

to_dict 方法是我推荐的写法。接口返回数据时，绝对不能把 password_hash 直接返回，手动控制每个模型序列化时的字段集合，是避免敏感数据泄露的最朴素也最可靠的办法。

3.3 带角色的登录认证：装饰器怎么写才不踩坑

登录接口返回的不只是用户信息，还要有一个 token。我用的是 Flask-JWT-Extended 这个扩展，把用户 id 和角色都放进 token 的 identity 里：

from flask_jwt_extended import create_access_token @auth_bp.route('/login', methods=['POST']) def login(): data = request.get_json() username = data.get('username') password = data.get('password') user = User.query.filter_by(username=username).first() if not user or not user.check_password(password): return {'msg': '用户名或密码错误'}, 401 # 把 id 和 role 塞进 token access_token = create_access_token( identity={'user_id': user.id, 'role': user.role}, expires_delta=False ) return {'token': access_token, 'user': user.to_dict()}, 200

然后写一个角色校验装饰器，这是整个后端权限体系的核心：

from functools import wraps from flask_jwt_extended import jwt_required, get_jwt_identity def role_required(*roles): def decorator(fn): @wraps(fn) @jwt_required() def wrapper(*args, **kwargs): current = get_jwt_identity() or {} if current.get('role') not in roles: return {'msg': '没有权限执行此操作'}, 403 return fn(*args, **kwargs) return wrapper return decorator

使用方式就是在路由上叠加一个装饰器参数：

@admin_bp.route('/users', methods=['GET']) @role_required('admin', 'staff') def list_users(): ...

这里强调一个新手容易犯的错：jwt_required() 必须写在 role_required 内部，顺序不能反。如果先校验角色再校验 token，当一个未登录用户带着空身份来访问时，角色判断逻辑会先拿不到身份信息，返回的就不是标准的 401 而是 403，前端拦截器就很难统一处理。我初版就犯过这个错，调试了一个晚上才排查清楚。

4. Vue 前端对接：从登录到角色路由守卫

4.1 路由按角色划分的三种写法

前端我用 Vue 3 + Vue Router 4 + Pinia，项目是通过 Vite 脚手架创建的。路由按模块拆分，重点在于给每个页面声明允许访问的角色。

我的做法是在路由的 meta 字段里放两个自定义属性：

{ path: '/admin/users', component: () => import('@/views/admin/UserManage.vue'), meta: { requiresAuth: true, roles: ['admin'] } }, { path: '/staff/checkin', component: () => import('@/views/staff/CheckIn.vue'), meta: { requiresAuth: true, roles: ['admin', 'staff'] } }, { path: '/guest/my-orders', component: () => import('@/views/guest/MyOrders.vue'), meta: { requiresAuth: true, roles: ['guest'] } }

然后写全局前置守卫：

router.beforeEach((to, from, next) => { const token = localStorage.getItem('token') const role = localStorage.getItem('role') if (to.meta.requiresAuth && !token) { next('/login') return } if (to.meta.roles && !to.meta.roles.includes(role)) { next('/403') return } next() })

这种方式是最直观的"声明式权限"。我试过更复杂的动态路由方案，也就是登录后根据角色动态添加路由，但那需要后端额外提供路由表接口，还要管理路由卸载，对这个小系统来说完全是过度设计。静态路由加前置守卫，思路简单，后续加页面也不容易出错。

4.2 axios 拦截器与 401 的全局处理

前端所有请求走同一个 axios 实例，拦截器统一做两件事：加 token、处理错误。

const request = axios.create({ baseURL: '/api', timeout: 10000 }) request.interceptors.request.use(config => { const token = localStorage.getItem('token') if (token) { config.headers.Authorization = `Bearer ${token}` } return config }) request.interceptors.response.use( response => response.data, error => { if (error.response && error.response.status === 401) { localStorage.removeItem('token') localStorage.removeItem('role') router.push('/login') } return Promise.reject(error) } )

这段代码解决了两个常见问题。一个是每次请求都手动加 Authorization 头的问题，拦截器统一搞定。另一个是登录过期的问题，后端返回 401 时自动清掉本地登录态、踢回登录页，用户不会看到一堆报错弹窗。

关于 403 要不要全局处理，我的选择是不处理。因为 403 意味着已经登录但没有权限，这种时候直接跳到一个"无权访问"提示页反而会把用户搞懵，不如在页面里根据角色做按钮级控制，后面细说。

4.3 页面按钮级权限的细节

路由守卫控制的是"能不能进这个页面"，但页面上还要控按钮。比如管理员页面上有一个"删除房间"按钮，员工角色的前端如果直接渲染出来，虽然点了会收到 403，但体验不好。

我的做法是封装一个小指令 v-permission，或者更简单一点，在组件里读取当前角色判断：

<el-button v-if="role === 'admin'" type="danger" @click="deleteRoom(row)"> 删除 </el-button>

有很多教程教人只做按钮隐藏，不做后端校验。我明确说：这只解决体验问题，不解决安全问题。因为前端代码是公开的，一个懂点技术的前台员工完全可以打开开发者工具、改掉 localStorage 里的 role、直接调管理接口。所以按钮隐藏必须配后端 role_required，一层管体验，一层管安全，缺一不可。

5. 在 PyCharm 里从零跑通项目的完整过程

5.1 环境准备与依赖锁定

先说环境怎么搭。我用的版本是 Python 3.10，PyCharm 2023 版本，MySQL 8.0。

在 PyCharm 里新建一个 Pure Python 类型的工程，然后打开 Terminal 执行：

python -m venv venv source venv/bin/activate # Windows 下是 venv\Scripts\activate pip install flask flask-sqlalchemy flask-jwt-extended flask-cors pymysql

requirements.txt 里务必把版本锁住，不然过几个月别人拉下来一装，依赖版本变了，项目可能直接跑不起来。我的 requirements.txt 开头几行是这样：

Flask==2.3.3 Flask-SQLAlchemy==3.1.1 Flask-JWT-Extended==4.5.3 Flask-Cors==4.0.1 PyMySQL==1.1.0

然后到配置数据库连接。config.py 里的 SQLALCHEMY_DATABASE_URI 写成 MySQL 格式：

app.config['SQLALCHEMY_DATABASE_URI'] = 'mysql+pymysql://root:数据库密码@127.0.0.1:3306/hotel_db?charset=utf8mb4'

注意字符集必须指定 utf8mb4，否则存中文姓名、房间描述时容易出问题。这算是我早期踩过的一个暗坑。

5.2 后端联调的三个高频问题

后端接口写完，第一步不是对接 Vue，而是先拿接口测试工具验证。我用的 Postman，一步步调通再进前端。

联调中最常见的问题有三个：

第一个是数据库表没建。SQLAlchemy 的 db.create_all() 要在 Flask 应用上下文里执行，很多人直接 python xx.py 运行后在空数据库里查数据，会一直报"Table doesn't exist"。我为了省事，在 run.py 里加了启动建表和初始数据灌入的逻辑，演示环境直接拉起就用。

第二个是 JSON 序列化报错，比如 datetime 对象不能直接 jsonify。前面的模型 to_dict 里把时间格式化成字符串，就是为了避开这个错误。如果你的模型没做这一步，接口几乎百分百会在复杂字段附近崩掉。还有个隐藏坑是 Decimal（主键、余额字段常见），也要先转 float 或 str。

第三个是基于类的视图或者蓝图没注册路由，访问接口直接 404。这种问题在开发中很容易被误判成"接口写错了"，其实只是你忘了在 app 实例里 register_blueprint。我在完整跑通前加了一个调试手段，启动时把所有路由打印出来：

for rule in app.url_map.iter_rules(): print(rule)

一眼就能确认接口路径和预期是否一致。

5.3 前端代理与 CORS 的正确配置

开发阶段前后端不同端口，Flask 跑在 5000，Vite 跑在 5173，浏览器跨域会挡掉请求。有两种解法：

后端直接开 CORS：

from flask_cors import CORS CORS(app, supports_credentials=True)

前端配置 Vite 代理：

// vite.config.js export default defineConfig({ server: { port: 5173, proxy: { '/api': { target: 'http://127.0.0.1:5000', changeOrigin: true } } } })

这里我踩过一个具体问题：如果 axios 里配置了 baseURL 为空，且请求路径直接写 http://127.0.0.1:5000/api/xxx，那代理完全不生效，因为浏览器实际请求的是完整外链，走到了后端，跨域靠的还是后端的 CORS 头。两种方案都能让请求通，但代理方案更干净，因为在浏览器里所有请求看起来都是同源的。最终我的选择是：前端代理解决开发跨域，后端 CORS 也开着，双保险，后面若要部署到线上不会因为跨域卡住。

6. 你大概率会遇到的坑：我实测过的排错记录

6.1 房间"超卖"：并发预订的状态竞争

这是产品质量和演示效果的巨大分水岭，建议至少加一个最小实现，让整个系统看起来真正严谨。

场景是这样的：两个客人同时预订同一间房。后端逻辑如果写成"先查房间状态，如果是 available，创建订单，再改成 locked"，在并发情况下会发生竞态。两个请求同时查到 available，都认为自己成功预订了，房间就被超卖。本地演示时可能碰不上，但上线或者演示过程中稍不留意就会复现出来。

解决方案我用了两个层次。第一层是数据库层面加行级锁，让查询和更新变成原子操作：

from sqlalchemy import text room = Room.query.filter_by(id=room_id, status='available').with_for_update().first() if not room: return {'msg': '该房间已被预订'}, 400 # 先更新状态，再创建订单 room.status = 'locked' db.session.commit() # 创建订单...

with_for_update() 会生成 SELECT FOR UPDATE 语句，把一个房间记录锁住。第二个请求进来时会在这里阻塞，等第一个请求事务提交后，它拿到的就是 status='locked' 的记录，查询直接为空，就会走"已被预订"的分支。

第二层是业务逻辑优化：先改状态再创建订单。哪怕不依赖锁，只要更新语句带条件 status='available'，数据库层面就能阻止覆盖。实际我两层都做了，效果非常稳。

6.2 时间字段的时区陷阱

费了一个下午改的时间 bug。最初 models 里 created_at 用的默认值是 datetime.utcnow，存进数据库的时间比北京时间少了 8 小时。前端拿到时间后直接展示，订单列表里"创建于昨日"看着特别不对劲。

排查过程也不难，启动接口看一眼返回的 JSON，发现时间戳确实是 UTC，然后定位到模型定义。

处理方案是我放弃了 UTC 统一存储的思路，直接改成本地时间：

created_at = db.Column(db.DateTime, default=datetime.now)

同时在 to_dict 序列化里固定格式为 %Y-%m-%d %H:%M:%S。对这个项目规模来说，本地时间存储最直观，debug 时也省心。如果你的系统要面向多时区用户，那再考虑 UTC 存储加前端本地化，小项目不必复杂化。

6.3 密码安全与其他容易被忽略的点

密码处理前面提过一次，这里展开。一定要用哈希，绝不能明文存。我见过不少课程设计项目直接明文存密码，展示的时候为了显得"好用"甚至还回显密码。一旦数据库泄露，所有用户的密码就都曝光了。用 werkzeug.security 做哈希校验，成本几乎为零，这应该是底线。

另外还有一个权限漏洞，光靠前端隐藏菜单远远不够。比如火狐开发者工具、浏览器控制台里直接输入 fetch("/api/admin/users").then(...)，只要后端没有做角色校验，任何登录用户都能查到所有用户列表。所以后端装饰器必须覆盖所有敏感接口，这个没有任何商量余地。

最后一个容易被忽略的点是日志。员工误操作删掉了订单，管理员想查是谁干的，如果没有操作日志就真的无从下手。我在后台加了一个 operation_logs 表，员工做关键操作（入住、退房、改价、删订单）时都会写一条记录，管理员页面可以看到最近操作流水。这个功能对管理系统来说属于"看起来不重要、实际上很拉好感"的部分，也很符合真实业务需求。

回头看我跑通整个系统的过程，最大的感受是：技术选型不追求最强，而是追求"自己掌控得住"。Flask 加 Vue 这套组合，刚好让我能把后端逻辑、数据库表、前端页面都亲手写出来，每个部分都说得清来龙去脉。如果你也要做类似的酒店管理系统，或者换个领域改成教师管理系统、设备管理系统，思路完全通用：先把角色模型画清楚，再把接口权限定下来，最后才是写页面。我在实际项目里把这些模块拆成可复用的思路，换一个业务场景，换一套表结构，骨架可以直接平移过去。