Flask + Vue 从零搭建影城售票管理系统：选座锁座与订单状态实战

做影城售票管理系统这类项目，最忙的不是写代码本身，而是把购票链路里那些细碎的状态理顺：选座、锁座、生成订单、支付、出票，每步都有先后依赖，一个环节掉了，整个体验就崩了。这篇文章记录我用 Flask + Vue 从零搭起一个影城售票管理系统的完整过程，后端走 Python 的轻量路线，前端用 Vue 处理最头疼的选座交互，开发环境用 PyCharm 提高效率。标题里同时写了“flask”和“django”，其实对应的是两种可选的 Python 后端方案，我后面会专门说明这个框架选择，以及为什么最终落在 Flask 上。

这套系统解决的是两个核心问题：对普通用户，提供影片浏览、场次查询、在线选座、订单支付的全流程体验；对影城管理员，提供影片维护、影厅配置、场次排期和订单管理的后台能力。无论你是在做课程设计、毕业设计，还是单纯想练手一个完整的前后端分离项目，这个组合都很合适。Flask 足够轻、心智负担小，Vue 又擅长处理动态交互，两者配合能把业务逻辑和界面操作都讲清楚。

1. 项目定位：这套影城售票系统到底能做什么

1.1 用户端与管理员端的功能边界

先把需求拆清楚。影城售票系统不是简单地把电影列表摆出来，而是分成两个完全不同的角色视角。

用户端核心链路是：注册登录 → 浏览热映影片 → 查看某部电影的场次 → 进入影厅选座 → 提交订单 → 模拟支付 → 查看我的订单。这里最容易忽略的是“场次”这个概念，它是电影和影厅的组合产物，同一部电影在一个影厅一天可能排三场，不同场次的时间、价格都不同。所以数据模型里必须有单独的 session 表来记录“什么时间、在哪个厅、放哪部片”。

管理员端则是另一套逻辑：维护电影信息、上传海报、设置影片状态，维护影厅的行列数，为指定影厅创建场次并设置票价，以及查看订单数据。这套系统我做成了前后端分离，管理员和用户的界面分到不同路由下，但共用同一套后端 API。

1.2 技术栈为什么这样组合

技术选型这块，我走了不少弯路，也算踩出了一些经验。标题里同时出现 Flask 和 Django 是有原因的，这两个框架是 Python Web 开发最常见的两个选择，很多项目资料里会同时标注两个方案。

Django 的优势在于“全家桶”，ORM、Admin 后台、认证体系都是现成的，做个内容管理型后台非常快。但售票系统的业务有大量定制化的状态流转，比如锁座超时释放、座位并发抢占，Django 的默认后台反而会绊脚。Flask 的优势是轻和自由，路由、蓝图、SQLAlchemy 都可以按需组合，API 层做得很干净，配合 Vue 做前后端分离很顺手。

所以我最终的方案是：Flask + SQLAlchemy + Vue 3 + Vite，用 PyCharm 统一管理开发和调试。如果你更熟悉 Django，也可以把后端替换成 Django REST Framework，业务逻辑和前端 Vue 部分是完全通用的。

2. 技术选型复盘：为什么是 Flask+Vue 而不是 Django 全家桶

2.1 Flask 在售票系统里的真实优势

很多初学者会纠结：Flask 是不是太简单了？不适合做“系统”？我实际做过以后可以直说：对于售票系统这种体量的项目，Flask 的灵活反而比 Django 的完备更值钱。

比如权限控制。Django 自带的 User 和 Permission 机制适合标准的内容管理，但售票系统需要的是两种角色，用户和管理员。用 Flask 的话，我可以自己定义 JWT 负载，给管理员多签一个 role 字段，接口装饰器里判断一下角色就完事，不需要去适配框架自带的权限表。

再比如选座锁座这个操作。它要求“同一时刻只有一个请求能成功锁到同一个座位”，这要依赖数据库层面的条件更新，而不是纯应用层判断。Flask 配合 SQLAlchemy 可以非常直接地写：

result = SeatLock.query.filter_by( session_id=session_id, seat_row=row, seat_col=col, status=0 ).update({"status": 1, "lock_time": now()}) db.session.commit()

这一句 update 能天然保证并发下只有一个请求成功，Django ORM 也能完成类似操作，但整个思路在 Flask 里更自由，不会被框架的其他机制干扰。

2.2 Vue 负责交互，Flask 负责数据

前后端分离最大的好处是职责清晰。Flask 这边只返回 JSON，不关心页面长什么样；Vue 这边只负责渲染和交互，不直接操作数据库。

选座是最典型的例子。座位状态实时变化，用户点击座位要立刻反馈颜色变化，提交后还要等后端确认锁座结果。这种交互让服务端直接渲染模板会非常痛苦，用 Vue 的响应式数据就好办很多——座位二维数组一变，界面自动刷新。

另外一个原因是开发效率。Vue 3 单文件组件把模板、脚本、样式放在一起，PyCharm 对 Vue 的支持也足够好，组件语法高亮、模板补全都很顺。开发时用 Vite 的代理把 API 请求转发到 Flask 的 5000 端口，热更新一开，改完代码页面立刻生效，联调体验远好于改完模板刷新页面。

2.3 PyCharm 在这里的角色不是摆设

很多人把 PyCharm 只当成一个写代码的编辑器，其实这个项目里它能帮上大忙。Flask 的调试配置可以直接在 PyCharm 里跑，断点打在接口函数里，前端请求发过来就能逐步看数据。

我把前后端拆了两个运行配置：后端用 Flask 自带的 app.run(debug=True)，前端用 npm run dev。PyCharm 支持多配置并行启动，一次把两边都拉起来。数据库迁移命令也可以在 Terminal 面板里直接敲，不需要额外切换窗口。

3. 数据库设计：五张核心表如何把业务串起来

3.1 用户表、电影表、影厅表的建模细节

数据库是整个系统的地基，我想明白这个问题花了不少时间。售票系统最核心的表是这五张：用户表、电影表、影厅表、场次表、订单表，另外还需要一张座位锁表来记录每场次的座位状态。

用户表比较简单，但要注意密码不能明文存。我用的方案是 Werkzeug 提供的 generate_password_hash，注册时加密，登录时 check_password_hash 校验。角色字段用字符串存，user 和 admin 两种，admin 账号可以通过脚本直接写入数据库。

class User(db.Model): __tablename__ = "user" id = db.Column(db.Integer, primary_key=True) username = db.Column(db.String(64), unique=True, nullable=False) password_hash = db.Column(db.String(256), nullable=False) phone = db.Column(db.String(20)) role = db.Column(db.String(10), default="user") created_at = db.Column(db.DateTime, default=datetime.now)

电影表要存标题、封面图、时长、上映日期、简介、状态。状态字段很关键，它决定影片在用户端是否展示。我设计了三个值：0 未上映、1 热映中、2 已下架，管理员可以手动切换。

影厅表相对简单，存名称、总行数、总列数。设计成行列数而不是固定座位数，是为了后面选座组件方便用二维数组渲染，也方便管理员配置不同规模的影厅。

3.2 场次表与座位锁表的关联设计

场次表是电影和影厅的桥。它记录这场电影放的哪部片、在哪个厅、几点开始、票价多少、状态如何。

class Session(db.Model): __tablename__ = "session" id = db.Column(db.Integer, primary_key=True) movie_id = db.Column(db.Integer, db.ForeignKey("movie.id")) hall_id = db.Column(db.Integer, db.ForeignKey("hall.id")) start_time = db.Column(db.DateTime, nullable=False) end_time = db.Column(db.DateTime, nullable=False) price = db.Column(db.Float, nullable=False) status = db.Column(db.Integer, default=1)

座位锁表是我最花心思设计的一张表。它不是影厅的物理座位表，而是“某场次下某个座位的状态表”，字段包括场次 id、行、列、状态、锁定的时间。状态 0 表示可用，1 表示锁定但未支付，2 表示已售。

选座的时候，用户看到的就是这张表以场次 id 为条件的结果。

3.3 订单表与状态流转逻辑

订单表是用户端最重要的一张表。因为它关联了用户和场次，还得记录总价和订单状态。我额外加了订单号字段，用时间戳加随机数生成，方便用户查询。

class Order(db.Model): __tablename__ = "order" id = db.Column(db.Integer, primary_key=True) order_no = db.Column(db.String(32), unique=True) user_id = db.Column(db.Integer, db.ForeignKey("user.id")) session_id = db.Column(db.Integer, db.ForeignKey("session.id")) total_price = db.Column(db.Float, default=0) status = db.Column(db.Integer, default=0) # 0待支付 1已支付 2已取消 created_at = db.Column(db.DateTime, default=datetime.now)

订单状态流转是整个系统里最容易出 bug 的地方。我定的是：用户选座后创建订单，状态为待支付，座位锁定；支付成功后状态改为已支付，座位改为已售；如果超过锁定时长未支付，后端脚本自动释放座位，并允许取消订单。这套流转想清楚后，业务流程立刻就顺了。

4. 后端实现：Flask API 从认证到购票的完整链路

4.1 项目目录结构与初始化方式

后端我没有把所有代码塞进一个 app.py，而是用蓝图拆成模块，这样后续维护会很舒服。直接看目录结构：

backend/ app.py config.py models/ __init__.py user.py movie.py hall.py session.py order.py api/ __init__.py auth.py movies.py sessions.py orders.py admin.py utils/ __init__.py jwt_helper.py

app.py 里创建 Flask 实例、注册蓝图、配置跨域，基本上只做装配工作。config.py 放数据库连接串和 JWT 密钥。数据库我用最简单的 SQLite，连接串写 sqlite:///cinema.db，这样项目拷到任何机器都能跑，不用额外装数据库服务。

4.2 认证模块：JWT 登录与角色控制

认证这块我用了 flask-jwt-extended，这个库比手动解析 JWT 省心很多，登录成功返回 access_token，后续请求在请求头带 Authorization: Bearer token 就行。

@app.route("/api/auth/login", methods=["POST"]) def login(): data = request.get_json() user = User.query.filter_by(username=data.get("username")).first() if user and check_password_hash(user.password_hash, data.get("password")): access_token = create_access_token( identity=str(user.id), additional_claims={"role": user.role} ) return jsonify({"code": 0, "token": access_token, "role": user.role}) return jsonify({"code": 1, "msg": "用户名或密码错误"})

管理员的接口通过一个自定义装饰器控制，从 get_jwt() 里取出 role 字段，不是 admin 就拒绝访问。这个方式比在每个接口里重复判断要清爽得多。

4.3 核心业务接口：场次查询与选座锁座

用户端核心接口设计上，我坚持“查询接口返回数据尽量完整，减少前端二次拼接”。比如场次列表接口，我直接返回场次 id、电影标题、电影封面、影厅名称、开始时间、价格，前端拿到就能渲染，不用再根据 movie_id 去查一次电影表。

选座锁座分成两步接口。第一步是获取座位状态，返回一个二维数组，0 代表可用、1 代表锁定、2 代表已售。第二步是提交订单时锁座，这一步我特意把锁座和订单创建放在同一个事务里，避免出现“订单创建了但座位没锁住”或者“座位锁了但订单没生成”的数据不一致问题。

提交订单的接口需要接收 session_id 和一个座位坐标列表，后端会逐座执行条件更新。如果某个座位已经被别人抢先锁了，更新影响行数为 0，我立刻抛出一个业务异常，前端就能提示“座位已被购买”，然后刷新座位状态。

4.4 管理员接口与数据初始化脚本

管理员接口比较常规：电影增删改查、场次创建、订单列表。我多做了一个场次冲突检测，创建场次时要判断同一个影厅在同一时间段是否已经有排期。

判断逻辑是这样的：新场次的时间区间 [start_a, end_a] 与已有场次 [start_b, end_b] 冲突的条件是start_a < end_b and start_b < end_a，这个双条件覆盖了所有重叠情况，包括首尾相接的边界情况。做排期类功能很容易漏掉这个判断，我自己就因为这个上过当。

数据初始化脚本我用 Flask CLI 写了一个命令，首次运行执行数据库建表，并写入管理员账号和几部测试电影，省得每次手工往数据库插数据。

5. 前端实现：Vue 选座交互与数据联调

5.1 页面结构与路由设计

前端我用 Vue 3 加 Vue Router 搭的，路由分两大块：用户端在主页路径下，管理员端在 /admin 路径下。页面包括观影首页、电影详情、选座页、订单页、我的订单，以及管理员的电影管理、场次管理、订单管理。

// router/index.js 核心路由 const routes = [ { path: "/", component: HomePage }, { path: "/movie/:id", component: MovieDetail }, { path: "/session/:id/seat", component: SeatSelect, meta: { requiresAuth: true } }, { path: "/orders", component: MyOrders, meta: { requiresAuth: true } }, { path: "/admin", component: AdminLayout, meta: { requiresAuth: true, role: "admin" } } ];

路由守卫里我统一做了两件事：检查本地有没有 token，检查用户角色是否匹配。每次页面跳转前先判断，没有权限直接弹回登录页，这样后端即使被绕过，前端也不会把无权限的界面暴露出来。

5.2 选座组件：二维数组渲染与交互状态

选座是整个前端最核心的组件。我把它单独拆成 SeatMap.vue，通过 props 接收后端传来的座位数组，然后用两重 v-for 循环渲染。

数据结构是二维数组，每个元素是一个对象，包含 row、col、status。渲染时根据 status 给座位 div 加不同的 class，灰色代表已售不能点，黄色代表锁定中，绿色代表可选。用户点击可选座位时，先把状态改成临时选中色，和 Locked 的黄色区分开，提交订单后由后端返回最终结果。

这里有个交互细节：用户可能选了座位又反悔，再点一下要能取消选中。所以组件里维护了一个 selectedSeats 集合，点击座位时先判断它在不在集合里，在就移除，不在就添加。同时限制最多选 5 个座位，达到上限后继续点击给一个轻提示。

座位数据是进入页面时请求的，锁定期满后状态会变，所以我加了一个 30 秒轮询，刷新座位状态。虽然不是实时推送，但足以避免用户看到的是过期数据。

5.3 axios 封装与 token 注入设计

前端所有请求走 axios，我封装了一个 request 实例，在请求拦截器里统一从 localStorage 取 token，加到请求头。

request.interceptors.request.use(config => { const token = localStorage.getItem("token"); if (token) { config.headers.Authorization = `Bearer ${token}`; } return config; });

响应拦截器里做统一错误处理，如果返回 401，说明 token 过期或者未登录，直接清掉本地 token 并跳转登录页。这个设计让每个页面不用各自处理认证异常，很省事。

后端返回的 JSON 我统一成一个结构：code 为 0 表示成功，非 0 表示业务错误，msg 字段携带提示。前端拦截器只对 HTTP 状态码做处理，业务上的错误就在具体接口那里再用 code 判断，两层不混淆。

6. 完整实操：用 PyCharm 从零跑通项目

6.1 环境准备与依赖安装清单

如果所有代码都是现成的，从零跑通这套系统大概需要半小时。第一步是准备 Python 环境，我用 PyCharm 新建项目时直接选择虚拟环境 venv，Python 版本建议 3.10 或 3.11，太高或太低都可能碰到个别依赖兼容问题。

后端依赖我整理成 requirements.txt，核心是这几个：flask、flask-sqlalchemy、flask-cors、flask-jwt-extended、werkzeug。前端用 Vite 创建 Vue 3 项目，然后安装 vue-router 和 axios。注意前端不要手动建 package.json，直接用命令初始化更不容易出错。

6.2 数据库迁移与初始化执行顺序

数据库这块我图省事，没有用 Flask-Migrate 做迁移版本管理，而是直接在主模块里执行 db.create_all()。但对于已经有业务数据的表，改动模型后这种方案不会自动加列，所以更规范的做法还是用 Flask-Migrate，我推荐你在正式项目里用迁移。

初始化数据的顺序有讲究：先建用户管理员，再建电影和影厅，最后建场次。因为场次表的外键依赖前面几张表的数据，顺序反了要么报错，要么关联不上。

我在项目里加了一个初始化命令，执行后会在终端打印创建的数据条数，方便确认没有漏。

6.3 前后端联调与 PyCharm 运行配置

联调阶段最重要的就是跨域配置。Flask 后端监听 5000 端口，Vue 开发服务器监听 5173 端口，端口不同必然触发浏览器跨域限制。我解决的办法是 flask-cors 库，直接允许所有来源在开发阶段使用。

生产环境更稳妥的做法是用 Nginx 做反向代理，把 /api 前缀的请求转发到 Flask，这样前后端同域名访问就不再跨域。开发阶段为了省事，也可以配置 Vite 的 proxy，将 /api 代理到 localhost:5000，我在项目里两种配置都写了，默认走的是后端的 CORS 方案，更直接。

PyCharm 里面配置运行有两步。后端直接创建一个 Flask 项目的运行配置，指定 app.py 作为运行入口。前端需要在 PyCharm 里设置 npm 任务，command 写 run dev，script 选 dev。两个配置都配好后，点一下并行运行按钮，就能同时拉起前后端。

7. 常见问题排查与避坑实录

7.1 跨域请求被拦截的完整排查思路

前后端分离项目里跨域是第一大坑。遇到报错时先看浏览器控制台的具体信息，如果提示 CORS policy，马上检查后端有没有安装 flask-cors 并调用 CORS(app)。

我犯过一次低级错误：装了个 flask-cors 但在 app.py 里没初始化，前端死活拿不到数据。另外注意 flask-cors 对带 token 的请求要允许 Authorization 请求头，默认配置有时候会忽略这个头，导致登录接口通了，带 token 的接口全部失败。

7.2 并发锁座的竞争条件处理

系统上线后我模拟了两个账号同时选同一个座位，果然有一个请求会失败，这正是条件更新 SQL 在发挥作用。这里的关键心得是：不要在应用层先查询再判断，一定要用数据库的条件更新作为最终防线。

# 正确做法：条件更新，避免原子性问题 row = SeatLock.query.filter( SeatLock.session_id == session_id, SeatLock.row == row, SeatLock.col == col, SeatLock.status == 0 ).update({"status": 1, "lock_time": now()})

如果先查出来是 0，再改状态，中间隔着几毫秒就有可能会被另一个请求插队。这也是为什么我坚持把锁座写成一句 update 而不是先 select 后 update。

7.3 时间处理：时区、格式与场次边界

时间问题是另一类高频 bug。SQLite 默认存时间用的是 ISO 格式字符串，Flask 返回 JSON 时会转成类似 2024-05-01T14:30:00 的形式，前端 new Date() 可以直接解析，这个倒是没有大问题。

真正坑的是场次结束时间。我开始只存了开始时间和电影时长，没算结束时间，后来做排期冲突检测时需要比较结束时间，临时在查询里计算。建议你在数据库设计时就把开始时间和结束时间都存下来，不要后面再算。

7.4 图片上传后前端无法访问的处理

电影海报上传我也踩了坑。Flask 默认不暴露上传目录的静态访问，前端拿到图片路径后 404。解决办法是给上传目录专门配置一个静态路由：

@app.route("/static/uploads/<path:filename>") def uploaded_file(filename): return send_from_directory(UPLOAD_FOLDER, filename)

同时文件名必须用 secure_filename 处理，否则带特殊字符的文件名可能引发路径问题。这一点只适合本地开发，真正的生产环境应该把图片放到对象存储服务上，而不是存在应用目录里。

7.5 一张问题速查表

8. 项目后续扩展与个人经验

整个项目搭完之后，我自己也复盘了哪些地方能做更好。第一个是支付模块目前只是模拟接口，真实对接第三方支付时，还需要考虑支付回调、订单状态同步和幂等处理，逻辑会复杂不少。第二个是座位图可以做成 SVG 或者 Canvas 的形式，比现在的 div 网格更接近真实影厅的弧形排布。

第三个扩展方向是场次管理稍微加一点智能化，比如根据电影热度和历史售卖率自动调整票价，这就涉及简单的数据分析，用 Flask 做接口也很自然。第四个是部署交付，开发环境跑通了不等于上线，真实部署时建议用 gunicorn 启动 Flask，前端打包后交给 Nginx 托管，数据库也换到 MySQL，这套结构我已经在另一个模拟项目里验证过，整体思路是一样的。

再说一句个人实际操作的体会：我前后做了两遍这个系统，第一遍把所有逻辑都塞在 app.py 里，改一个地方就要动一大堆代码；第二遍才老老实实按蓝图和组件拆分，开发体验完全不一样。如果你也打算照着做，我最大的建议是先把数据库表关系和状态流转图画清楚，再动手写代码。表结构没想明白之前，写再多接口都是返工。

最后分享一个小技巧：调试阶段把 Flask 的 debug 日志和 Vue 的浏览器开发者工具配合用，在后端接口函数第一行打一个断点，前端操作一步就能看到请求进来，配合 debugger 逐步看数据变化，能帮你把很多隐蔽状态下落问题定位得又快又准。