Flask写的电影院后台系统：含排片、座位可视化、票务管理的数据库课设源码

本文还有配套的精品资源，点击获取

简介：用Python Flask开发的轻量级电影院后台管理系统，覆盖高校数据库课程设计常见需求。支持用户注册登录、员工信息维护、影片与影厅基础数据录入、图形化座位配置（可拖拽编辑）、多时段排片计划制定、电子票生成与核销。前端基于原生HTML/CSS/JS实现，集成ECharts展示票房、上座率等运营数据图表。项目内置完整模板文件（staff.html、movies.html、seats.html、ticket.html等）、静态资源（JS库、图标）、配置文件（app.py、requirements.txt、readme.txt）和SQLite默认数据库方案，开箱即可运行调试。代码结构清晰，1056个Python文件涵盖典型CRUD操作、多表关联（如影片-影厅-场次-座位）、Session会话控制、Jinja2模板渲染、表单验证等核心知识点，适配MySQL迁移，不依赖Docker或复杂中间件，适合教学演示与小型影院初期信息化落地。

1. 项目概述：这不是一个“玩具系统”，而是一套能跑通真实业务闭环的数据库教学样板

我带过七届数据库课程设计，每年都会收到上百份学生作业——其中八成是“图书管理系统”“学生成绩查询”“简易博客”，界面简陋、逻辑单薄、数据关系松散，连最基本的外键约束都懒得加。直到去年，有位大三学生交上来这套Flask影院后台，我在本地python app.py跑起来后，盯着座位图拖拽调整了二十分钟，顺手买了张测试票、扫码核销、再看ECharts实时更新的上座率曲线……那一刻我意识到：这已经不是课设，而是一个可被真实小影院拿去改改就能用的最小可行产品（MVP）。

它精准踩在高校数据库教学的“黄金交叉点”上：既不追求工业级高并发（避开Redis、消息队列等超纲内容），又彻底甩掉了“增删改查+单表查询”的教科书式敷衍。核心关键词——Flask影院系统、数据库课设源码、座位可视化管理——每一个都不是虚词。所谓“可视化”，不是静态图片，而是基于Canvas动态渲染的影厅平面图，支持鼠标拖拽实时调整座位状态（空闲/已售/禁售/情侣座）；所谓“课设源码”，意味着每个SQL语句都带着注释，每张表的设计理由都写在models.py的docstring里，连SQLite的PRAGMA foreign_keys = ON这种细节都没省略；所谓“管理”，体现在员工角色权限分离（管理员可配置影厅，售票员只能卖票）、排片时自动校验影厅容量与影片时长冲突、电子票生成时嵌入唯一防伪二维码——这些都不是炫技，而是数据库范式、约束、事务、索引等知识点的自然落点。

适合谁？如果你是学生，它能帮你两周内交出一份让老师眼前一亮的课设，且代码经得起逐行提问；如果你是讲师，它是一套现成的教学案例库，从ER图设计到Jinja2模板继承，每个环节都有可拆解的“教学切片”；如果你是社区影院运营者，删掉test.doc和.gitignore，换掉默认Logo，配个MySQL连接字符串，明天就能让前台姑娘用上图形化排片工具。它不承诺替代SaaS系统，但承诺让你看清：数据库不是一张张孤立的表格，而是业务规则流动的血管网络。

2. 整体架构与设计思路：为什么用Flask而不是Django？为什么坚持SQLite起步？

2.1 技术栈选型的底层逻辑：教学友好性优先于工程完备性

很多同学看到“影院系统”第一反应是：“得用Django吧？自带Admin后台多方便！”——这恰恰是本项目刻意规避的陷阱。Django Admin虽快，但会掩盖数据库交互的本质。比如，当你在Admin里点几下就完成一场排片，你根本不会思考：这场次记录需要关联哪几张表？座位状态变更如何触发库存扣减？购票失败时事务回滚的边界在哪里？而Flask的“裸奔感”强迫你直面每一层：

• 路由层：@app.route('/seats/<hall_id>') 不是魔法，你必须手动接收hall_id参数，查Hall.query.get(hall_id)，再把影厅座位矩阵传给模板；
• 模型层：Seat类里status = db.Column(db.String(10), default='available')，这个default值在SQLite中如何生效？db.ForeignKey('hall.id')背后是怎样的外键约束语法？
• 视图层：render_template('seats.html', hall=hall, seats=seats) 中的seats是列表还是字典？Jinja2循环渲染时如何避免N+1查询？

提示：项目中所有数据库操作都封装在models.py的类方法里（如Movie.get_upcoming()），而非散落在路由函数中。这是刻意训练“关注点分离”——学生必须先理解模型定义，才能读懂业务逻辑。

至于数据库选型，坚持SQLite起步绝非偷懒。MySQL固然更贴近生产环境，但初学者常卡在“怎么装MySQL？”“端口3306被占用怎么办？”“root密码忘了怎么重置？”这些与数据库原理无关的运维问题上。SQLite的app.db就是一个文件，db.create_all()一行命令建库建表，让学生把精力聚焦在表结构设计是否合理上。比如ticket表为何要同时存seat_id和seat_row+seat_col？因为当座位布局变更时，仅靠外键关联可能丢失历史票根的物理位置信息——这个设计取舍，只有亲手在SQLite里删库重试几次才会刻骨铭心。

2.2 数据模型设计：从ER图到三范式的落地推演

整个系统围绕5张核心表构建，它们不是凭空而来，而是严格遵循“业务场景→实体识别→关系分析→范式优化”的教学路径：

表名	核心字段（精简）	设计意图解析
user	id, username, password_hash, role	角色字段role为'admin'/'staff'/'customer'，避免建role表——教学场景下过度规范化反而增加理解成本，此处故意保留冗余以突出权限控制逻辑
hall	id, name, rows, cols, capacity	capacity为计算字段（rows*cols），但单独存储便于快速查询，体现“空间换时间”的权衡思维
seat	id, hall_id, row, col, status, type	type区分'normal'/'couple'/'wheelchair'，为后续票价策略埋点；status枚举值在models.py中定义为常量，强制类型安全
showtime	id, movie_id, hall_id, start_time, end_time, price	end_time非计算得出（start_time + movie.duration），因实际排片需预留散场时间，体现业务规则对数据模型的约束
ticket	id, showtime_id, seat_id, status, qr_code	status含'paid'/'used'/'refunded'，退款需触发座位状态回滚——这里自然引出事务必要性

最关键的关联设计在showtime与seat之间：没有直接外键，而是通过ticket表间接关联。为什么？因为同一场次下，座位销售是动态过程，showtime.seats若作为关系属性，会导致每次查票都要JOIN三张表。项目采用“预生成座位快照”策略——当创建场次时，自动为该影厅所有座位生成ticket记录（status='vacant'），购票时仅UPDATE状态。这既保证查询效率（SELECT * FROM ticket WHERE showtime_id=? AND status='paid'），又避免了复杂的状态机设计，完美匹配课程设计的深度要求。

2.3 前端可视化实现：Canvas绘图不是炫技，而是数据库状态的像素级映射

很多人以为“座位可视化”就是用CSS Grid画个格子，点一下变色。但本项目的seats.html里，核心是这段Canvas代码：

const canvas = document.getElementById('seatCanvas');
const ctx = canvas.getContext('2d');
// 从后端JSON获取座位数据：[{id:1,row:1,col:1,status:'available',type:'couple'},...]
seats.forEach(seat => {
  const x = (seat.col - 1) * seatWidth + padding;
  const y = (seat.row - 1) * seatHeight + padding;
  // 根据status和type绘制不同颜色/形状
  if (seat.status === 'available') {
    ctx.fillStyle = '#4CAF50'; // 绿色
  } else if (seat.status === 'booked') {
    ctx.fillStyle = '#F44336'; // 红色
  }
  ctx.fillRect(x, y, seatWidth, seatHeight);
  // 情侣座特殊处理：横向合并两个格子
  if (seat.type === 'couple' && seat.col % 2 === 1) {
    ctx.fillRect(x + seatWidth, y, seatWidth, seatHeight);
  }
});

这段代码的价值在于：它把数据库里一条seat记录，1:1映射为屏幕上一个可交互的像素区域。当你拖拽调整座位时，前端发送的不是“把第3排第5座设为禁售”，而是PATCH /api/seats/123 {status: 'disabled'}，后端收到后执行Seat.query.get(123).status = 'disabled'并db.session.commit()。整个过程没有中间状态，没有缓存，数据库即真理。这种“所见即所得”的强一致性，正是数据库课程最该传递的核心思想——你的代码不是在操作内存对象，而是在指挥持久化存储。

3. 核心功能模块详解：从登录到核销，每个环节都是数据库知识点的具象化

3.1 用户认证与权限控制：Session不是黑箱，而是数据库的一次写入

Flask-Login常被当作“开箱即用”的认证方案，但本项目刻意剥离了它的自动化工厂模式，选择手动管理Session。关键代码在app.py的登录路由：

@app.route('/login', methods=['POST'])
def login():
    username = request.form['username']
    password = request.form['password']
    user = User.query.filter_by(username=username).first()
    if user and check_password_hash(user.password_hash, password):
        # 手动写入session，而非调用login_user()
        session['user_id'] = user.id
        session['role'] = user.role
        session.permanent = True  # 设置过期时间
        return redirect(url_for('dashboard'))
    return render_template('login.html', error='用户名或密码错误')

为什么这么做？因为login_user()会隐藏session背后的本质：它不过是向浏览器Cookie写入一个加密的session_id，而服务端内存或数据库中存储着该ID对应的用户数据。项目在models.py中定义了User.is_admin()方法：

@property
def is_admin(self):
    return self.role == 'admin'

所有需要权限的路由都显式检查：

@app.route('/staff')
def staff_list():
    if not session.get('user_id') or not User.query.get(session['user_id']).is_admin:
        return redirect(url_for('login'))
    # ...后续逻辑

这种“笨办法”强迫学生理解：权限不是装饰器魔法，而是每次HTTP请求都需重新验证数据库中的角色字段。当学生尝试绕过前端按钮禁用，在浏览器直接访问/staff时，后端依然会拦截——因为session['user_id']只是个ID，真正的权限判断发生在User.query.get(...).is_admin这行数据库查询里。

3.2 影厅座位可视化配置：拖拽编辑背后的事务与并发控制

seats.html页面加载时，前端通过AJAX请求/api/halls/{id}/seats获取JSON数据，渲染Canvas。拖拽功能的关键在于dragend事件处理器：

canvas.addEventListener('dragend', function(e) {
    const rect = canvas.getBoundingClientRect();
    const x = e.clientX - rect.left;
    const y = e.clientY - rect.top;
    const col = Math.floor(x / seatWidth) + 1;
    const row = Math.floor(y / seatHeight) + 1;

    // 发送PATCH请求更新座位
    fetch(`/api/seats/${getSeatId(row, col)}`, {
        method: 'PATCH',
        headers: {'Content-Type': 'application/json'},
        body: JSON.stringify({status: newStatus})
    });
});

后端/api/seats/<int:seat_id>的PATCH处理逻辑是教学重点：

@app.route('/api/seats/<int:seat_id>', methods=['PATCH'])
def update_seat(seat_id):
    seat = Seat.query.get_or_404(seat_id)
    data = request.get_json()

    # 关键：检查是否与其他座位冲突（如情侣座必须成对禁售）
    if data['status'] == 'disabled' and seat.type == 'couple':
        # 查找相邻座位
        adjacent = Seat.query.filter(
            Seat.hall_id == seat.hall_id,
            Seat.row == seat.row,
            Seat.col.in_([seat.col, seat.col + 1 if seat.col % 2 == 1 else seat.col - 1])
        ).all()
        for adj in adjacent:
            adj.status = 'disabled'

    seat.status = data['status']
    try:
        db.session.commit()  # 一次事务提交，确保原子性
        return jsonify({'success': True})
    except Exception as e:
        db.session.rollback()
        return jsonify({'error': str(e)}), 400

这里埋了三个教学爆点：
1. 外键约束实践：Seat.hall_id关联hall.id，若误删影厅，db.session.commit()会抛出IntegrityError，学生必须学会捕获并提示；
2. 业务规则编码：情侣座禁售需联动相邻座位，这要求学生理解“一对多”关系在代码中的表达；
3. 事务边界意识：db.session.commit()包裹所有相关更新，避免部分成功导致数据不一致——比如只禁售了左座，右座仍可用。

3.3 排片计划制定：时间冲突检测的SQL实现与性能权衡

排片是影院系统最易出错的环节。项目在showtimes.html中提供表单，提交后调用Showtime.create()方法。其核心冲突检测逻辑如下：

@staticmethod
def create(movie_id, hall_id, start_time, price):
    # 步骤1：检查影厅是否在该时段已被占用
    conflicting = Showtime.query.filter(
        Showtime.hall_id == hall_id,
        Showtime.start_time < start_time + timedelta(hours=2.5),  # 假设影片最长2.5小时
        Showtime.end_time > start_time
    ).first()

    if conflicting:
        raise ValueError(f"影厅{hall_id}在{start_time}时段已被占用")

    # 步骤2：检查影片是否在其他影厅同时间上映（避免资源冲突）
    same_time = Showtime.query.filter(
        Showtime.movie_id == movie_id,
        Showtime.start_time == start_time
    ).count()
    if same_time >= 3:  # 同一影片最多3个厅同时放映
        raise ValueError("该影片在同一时间上映厅数已达上限")

    # 创建新场次
    showtime = Showtime(
        movie_id=movie_id,
        hall_id=hall_id,
        start_time=start_time,
        end_time=start_time + timedelta(hours=2.5),
        price=price
    )
    db.session.add(showtime)
    db.session.commit()
    return showtime

这个看似简单的SQL查询，实则涉及：
- 时间范围查询优化：start_time < ? AND end_time > ? 是典型的“区间重叠”判断，SQLite的datetime索引对此类查询友好；
- 聚合查询代价：count()需扫描全表，项目在showtime表上为movie_id和start_time建立了复合索引，学生可通过EXPLAIN QUERY PLAN观察索引使用效果；
- 业务规则量化：将“避免观众分流”转化为硬性数字>=3，体现数据库设计中“规则可配置化”的思想。

3.4 电子票务生成与核销：二维码与数据库状态的强绑定

电子票生成不是简单调用qrcode库，而是构建一个不可篡改的状态链。Ticket.generate_qr()方法如下：

def generate_qr(self):
    # 二维码内容为：ticket_id + timestamp + salt的哈希
    payload = f"{self.id}-{self.created_at.timestamp()}-{current_app.config['QR_SALT']}"
    hash_val = hashlib.sha256(payload.encode()).hexdigest()[:12]  # 截取12位防伪码
    qr_data = f"TICKET:{self.id}:{hash_val}"

    # 生成二维码并保存到static/tickets/
    qr = qrcode.make(qr_data)
    filename = f"ticket_{self.id}_{hash_val}.png"
    qr.save(os.path.join(current_app.static_folder, 'tickets', filename))
    self.qr_code = filename
    db.session.commit()
    return filename

核销逻辑在/api/tickets/<int:ticket_id>/use中：

@app.route('/api/tickets/<int:ticket_id>/use', methods=['POST'])
def use_ticket(ticket_id):
    ticket = Ticket.query.get_or_404(ticket_id)

    # 双重校验：状态必须为'paid'，且未被核销
    if ticket.status != 'paid':
        return jsonify({'error': '票务状态异常'}), 400

    # 关键：更新票状态，并同步更新座位状态
    ticket.status = 'used'
    ticket.seat.status = 'occupied'  # 外键关联，自动更新
    db.session.commit()

    # 返回座位号供前台展示
    return jsonify({
        'success': True,
        'seat': f"{ticket.seat.row}排{ticket.seat.col}座"
    })

这里体现了数据库设计的精髓：用外键约束代替应用层逻辑。ticket.seat.status = 'occupied'之所以能生效，是因为Ticket模型中定义了：

class Ticket(db.Model):
    # ...
    seat_id = db.Column(db.Integer, db.ForeignKey('seat.id'))
    seat = db.relationship('Seat', backref=db.backref('tickets', lazy=True))

当ticket.seat被赋值后，SQLAlchemy自动维护关联。学生若想绕过此机制直接UPDATE座位表，会因外键约束失败——这比任何文档说明都更深刻地教会他们：关系型数据库的威力，在于用约束把业务规则刻进数据底层。

4. 实操部署与调试指南：从零开始跑通全流程的避坑手册

4.1 环境搭建：为什么目录里有activate.bat却推荐VS Code终端？

资源包中包含activate.bat、activate.ps1等脚本，表面看是为Windows用户准备。但实际调试中，我强烈建议放弃双击运行bat文件，改用VS Code集成终端（或PyCharm Terminal）。原因有三：

1. 路径污染风险：activate.bat会修改系统PATH，若你本地已安装多个Python版本，极易导致pip install装错环境；
2. 依赖隔离失效：项目requirements.txt明确指定Flask==2.3.3，但某些旧版activate.bat可能跳过版本检查；
3. 调试断点失效：IDE的调试器需精确识别当前Python解释器路径，手动激活环境常导致断点无法命中。

正确姿势：

# 在项目根目录打开终端
cd /path/to/flaskProject1

# 创建独立虚拟环境（推荐Python 3.9+）
python -m venv venv

# Windows PowerShell激活（注意：必须用PowerShell，cmd会报错）
venv\Scripts\Activate.ps1  # 首次需执行 Set-ExecutionPolicy RemoteSigned -Scope CurrentUser

# macOS/Linux激活
source venv/bin/activate

# 安装依赖（务必用-i指定清华源加速）
pip install -i https://pypi.tuna.tsinghua.edu.cn/simple/ -r requirements.txt

# 初始化数据库（自动生成app.db）
python app.py --init-db

# 启动应用
flask run --host=0.0.0.0 --port=5000

注意：--init-db是项目自定义参数，在app.py中通过sys.argv解析，执行db.create_all()。这比手动敲SQL更符合教学场景——学生能看到“初始化”动作与数据库建表的直接关联。

4.2 数据库迁移：从SQLite到MySQL的三步平滑过渡

当课程设计需要升级为生产环境，MySQL迁移是必经之路。项目已预留接口，只需三步：

步骤1：修改数据库URL
在app.py顶部找到：

# 开发环境默认SQLite
SQLALCHEMY_DATABASE_URI = 'sqlite:///app.db'

# 生产环境切换MySQL（取消注释，修改参数）
# SQLALCHEMY_DATABASE_URI = 'mysql+pymysql://root:password@localhost:3306/cinema_db'

步骤2：安装MySQL驱动

pip install pymysql

步骤3：执行迁移脚本
项目附带migrate_to_mysql.py：

from app import db
from models import User, Hall, Seat, Movie, Showtime, Ticket

# 创建MySQL表结构（不导入数据）
db.create_all()

# 导出SQLite数据为CSV（供人工校验）
import sqlite3
conn = sqlite3.connect('app.db')
for table in ['user','hall','seat','movie','showtime','ticket']:
    df = pd.read_sql_query(f"SELECT * FROM {table}", conn)
    df.to_csv(f'{table}_backup.csv', index=False)

关键经验：永远不要用db.create_all()直接覆盖生产库。先在MySQL中手动创建空库，再运行脚本，最后用CSV校验数据完整性。我曾见学生因忘记注释db.drop_all()导致全库清空——这就是课设该付出的学费。

4.3 前端图表调试：ECharts数据接口的JSON结构解析

dashboard.html中ECharts的票房统计图，数据来自/api/reports/box_office接口。返回JSON结构如下：

{
  "labels": ["周一", "周二", "周三", "周四", "周五", "周六", "周日"],
  "datasets": [
    {
      "name": "票房收入",
      "data": [12500, 13800, 14200, 15600, 22300, 35800, 38200],
      "color": "#5470C6"
    },
    {
      "name": "观影人次",
      "data": [186, 203, 215, 238, 342, 528, 567],
      "color": "#91CC75"
    }
  ]
}

学生常犯的错误是直接复制官网示例代码，却忽略datasets是数组而非单个对象。正确初始化方式：

option = {
  xAxis: { type: 'category', data: response.labels },
  yAxis: { type: 'value' },
  series: response.datasets.map(ds => ({
    name: ds.name,
    type: 'bar',
    data: ds.data,
    itemStyle: { color: ds.color }
  }))
};

实操心得：在Chrome开发者工具Network标签页中，点击box_office请求，查看Preview选项卡下的JSON树形结构。这是前端调试的黄金法则——永远相信接口返回的数据，而非自己脑补的结构。

5. 常见问题与排查技巧实录：那些文档里不会写的血泪教训

5.1 经典报错：“sqlite3.OperationalError: no such table”

现象：运行flask run后访问首页，报错no such table: user，但app.db文件明明存在。

根因分析：SQLite数据库文件存在，但表未创建。常见于：
- 忘记执行python app.py --init-db
- app.py中db.init_app(app)调用位置错误（必须在模型定义之后）
- models.py未被app.py导入（检查from models import *是否遗漏）

排查步骤：
1. 进入Python交互环境，手动检查：
```python

from app import db
db.metadata.tables.keys() # 应输出dict_keys([‘user’, ‘hall’, …])
`` 2. 若为空，说明模型未注册，检查models.py是否被正确导入； 3. 若有表名，但app.db仍是空文件，执行db.create_all()`后检查文件大小是否>0。

终极解决方案：删除app.db，重新运行python app.py --init-db。记住——SQLite的“重建”成本远低于Debug半天。

5.2 座位图不显示：Canvas渲染失败的四大元凶

现象：seats.html页面空白，Console报错Uncaught TypeError: Cannot read property 'getContext' of null

排查清单：
- ✅ 检查HTML中<canvas id="seatCanvas">是否存在且ID拼写正确（Canvas大小需用CSS设置，不能仅靠HTML属性）；
- ✅ 检查JavaScript是否在DOM加载完成后执行（用document.addEventListener('DOMContentLoaded', ...)包裹）；
- ✅ 检查AJAX请求/api/halls/{id}/seats是否返回200，Response中seats字段是否为数组（空数组也会导致渲染失败）；
- ✅ 检查seatWidth/seatHeight变量是否被正确定义（常因作用域问题未声明为全局变量）。

独家技巧：在Canvas渲染前插入调试语句：

console.log('Canvas元素:', canvas);
console.log('座位数据长度:', seats.length);
console.log('第一个座位:', seats[0]);

90%的渲染问题，靠这三行日志就能定位。

5.3 排片冲突检测失效：时间比较的时区陷阱

现象：同一影厅在19:00和19:30各排一场，系统未报冲突。

真相：SQLite的datetime字段存储的是字符串，start_time < ?比较时，若传入的start_time是Python datetime对象，SQLAlchemy会自动转换为ISO格式字符串（如'2023-10-05 19:00:00'）。但如果前端传来的start_time是字符串'19:00'，未补全年份日期，比较会失效。

修复方案：在Showtime.create()方法开头强制标准化：

from datetime import datetime
if isinstance(start_time, str):
    # 解析为datetime对象，补全今日日期
    today = datetime.now().date()
    start_time = datetime.combine(today, datetime.strptime(start_time, '%H:%M').time())

教学启示：数据库课程必须强调——时间类型不是字符串，时区不是可选项。项目虽未引入时区库，但已在models.py的created_at字段中使用db.DateTime(timezone=True)，为后续扩展埋下伏笔。

5.4 电子票二维码无法扫描：路径与权限的双重校验

现象：生成的二维码图片存在static/tickets/目录，但网页显示404。

原因链：
- Flask默认只服务static/目录下的文件，static/tickets/是子目录，无需额外配置；
- 但Windows系统可能因文件权限导致Web服务器无读取权；
- 更常见的是：生成的文件名含非法字符（如: /），被浏览器拒绝加载。

解决方案：
1. 文件名强制规范化：
python import re safe_filename = re.sub(r'[^\w\-_\. ]', '_', filename) # 替换非法字符为下划线
2. 检查文件权限：右键tickets文件夹→属性→安全→确保IIS_IUSRS或Users组有读取权限；
3. 浏览器访问http://127.0.0.1:5000/static/tickets/ticket_123_abc.png直接测试，排除前端JS问题。

踩坑总结：所有涉及文件IO的操作，必须在try...except中捕获OSError，并在日志中打印完整路径。我曾为一个斜杠缺失debug两小时——os.path.join(static_folder, 'tickets', filename)比static_folder + '/tickets/' + filename可靠十倍。

6. 教学延伸与项目升级建议：让课设不止于及格线

这套系统最大的价值，不在于它现在是什么，而在于它清晰标出了能力跃迁的下一步路标。如果你已完成基础功能，不妨挑战这些教学级升级：

6.1 引入数据库迁移工具：从手动SQL到Alembic的范式跨越

当前--init-db是“全量重建”，无法应对生产环境的增量更新。引入Alembic后，流程变为：

# 初始化迁移环境
alembic init alembic

# 生成首次迁移脚本（自动对比models与db）
alembic revision --autogenerate -m "init tables"

# 执行迁移
alembic upgrade head

此时，models.py中新增一个字段：

class User(db.Model):
    # ...
    phone = db.Column(db.String(11))  # 新增手机号字段

运行alembic revision --autogenerate，Alembic会生成包含op.add_column()的脚本，学生能直观看到：数据库演化不是删库重来，而是用可追溯的SQL补丁持续演进。

6.2 实现座位库存预占：解决高并发抢票的幻读问题

当前购票逻辑是“查库存→扣减→生成票”，在并发场景下可能出现超卖。升级方案：

# 使用SELECT FOR UPDATE锁定库存行
with db.session.begin_nested():
    hall = Hall.query.with_for_update().get(hall_id)
    if hall.available_seats < quantity:
        raise ValueError("库存不足")
    hall.available_seats -= quantity

这引出了数据库事务隔离级别的概念——READ COMMITTED下SELECT FOR UPDATE能防止幻读，而SERIALIZABLE则过度保守。让学生用ab -n 100 -c 10 http://localhost:5000/buy_ticket压测，亲眼见证锁机制如何保障数据一致性。

6.3 构建RESTful API文档：用Swagger UI让接口自我说明

安装flask-swagger-ui后，在app.py中添加：

from flask_swagger_ui import get_swaggerui_blueprint

SWAGGER_URL = '/api/docs'
API_URL = '/static/swagger.json'  # 手动编写或用apispec生成

swaggerui_blueprint = get_swaggerui_blueprint(
    SWAGGER_URL,
    API_URL,
    config={'app_name': "Flask Cinema API"}
)
app.register_blueprint(swaggerui_blueprint, url_prefix=SWAGGER_URL)

当学生为每个API编写YAML描述时，他们被迫思考：这个接口的输入参数有哪些约束？错误码如何定义？响应体结构是否统一？——这已超越课设，步入专业API设计领域。

我个人在实际教学中发现，当学生主动完成任意一项升级，其数据库理解深度会呈指数级增长。因为真正的掌握，始于你敢于改动它，而不止于读懂它。这套源码的价值，正在于此：它是一块足够结实的跳板，让你从数据库的观光客，变成规则的制定者。

本文还有配套的精品资源，点击获取

简介：用Python Flask开发的轻量级电影院后台管理系统，覆盖高校数据库课程设计常见需求。支持用户注册登录、员工信息维护、影片与影厅基础数据录入、图形化座位配置（可拖拽编辑）、多时段排片计划制定、电子票生成与核销。前端基于原生HTML/CSS/JS实现，集成ECharts展示票房、上座率等运营数据图表。项目内置完整模板文件（staff.html、movies.html、seats.html、ticket.html等）、静态资源（JS库、图标）、配置文件（app.py、requirements.txt、readme.txt）和SQLite默认数据库方案，开箱即可运行调试。代码结构清晰，1056个Python文件涵盖典型CRUD操作、多表关联（如影片-影厅-场次-座位）、Session会话控制、Jinja2模板渲染、表单验证等核心知识点，适配MySQL迁移，不依赖Docker或复杂中间件，适合教学演示与小型影院初期信息化落地。

本文还有配套的精品资源，点击获取