企业官网建设流程全解析

又是一个经典的"课设三件套"项目——图书馆座位预约系统。说实话，这几年每次到毕业季或者学期末，我都能在私信里看到类似的问题：能不能用Python做个座位预约系统？数据库怎么设计？预约冲突怎么处理？源码和文档怎么组织才能拿到高分？

这个项目的热度一直没降过，原因很现实：它的业务场景足够完整，既有用户登录、座位查询这种基础功能，又有预约抢座、签到暂离这种带状态流转的复杂逻辑，还牵扯到并发控制、时间调度这些容易踩坑的细节。作为课程设计、毕业设计，甚至是想往全栈方向走的练手项目，它的含金量都相当能打。

我这次就基于自己的实操经验，把这个项目从数据库设计到核心业务实现完整拆一遍。你拿到的源码和文档，我会告诉你每个模块为什么这么写，哪些地方是答辩老师最爱追问的高频考点，以及我在实际调试中遇到的那些坑。无论你是打算直接把这套项目当课设交上去，还是想搞清楚里面的原理然后自己改造一版，这篇都能给你省下不少时间。

1. 整体方案设计与技术选型

1.1 为什么选Python做这类系统

很多人选Python做图书管座位预约，冲的就是它的开发效率。这类管理系统本质上就是标准的增删改查加上业务状态流转，用Python写起来，代码量比Java要少一截。尤其是上课学过Python但没系统学过Java的同学，用Python做课设，至少不用在语法和框架配置上浪费太多时间。

再一个就是生态。Python在Web开发、数据处理这块的库非常全，你要做的座位预约系统涉及的几个核心能力——用户认证、数据库操作、定时任务——都有非常成熟的解决方案。我的建议是Web框架直接用Flask，原因很简单：它轻，够用，项目结构一目了然。你给答辩老师讲起来也方便，路由写了哪些、每个路由做什么事情，直接对着代码说就行。Django当然也行，但对课设来说有点重，模块间耦合度也高，不如Flask这种手动挂载的方式好理解。

1.2 技术栈选型与模块划分

我这次整理的项目版本，采用的是一个典型的三层结构：

这套组合的好处是每一层都能单独讲清楚。答辩的时候老师如果问"你用了什么架构"，你回答"基于MVC思想的轻量级分层架构"，然后用Flask的路由、模板、模型层分别对应MVC的Controller、View和Model，这个回答堪称标准答案。

功能模块划分上，我把它切成五个大的功能域：

• 用户模块：注册、登录、个人信息管理、密码修改。这里要注意密码不能明文存储，我用的Werkzeug自带的generate_password_hash做加密，这个是Flask全家桶自带的，不用额外装库。
• 座位管理模块：楼层、区域、座位号的维护，座位的状态展示（空闲、已预约、使用中、暂离、已禁用）。
• 预约模块：核心模块，包含预约座位、取消预约、签到、暂离、释放座位、续约等操作。
• 查询统计模块：按日期、楼区、状态等多个维度查座位，管理员可以查看整体使用率。
• 管理后台模块：管理员对用户、座位、预约记录的管理，以及违规用户的拉黑处理。

1.3 项目目录结构与交付物规划

这套源码的目录组织我建议这样搞，命名清晰一点，导师看起来也舒服：

library_seat/ ├── app.py # 程序入口 ├── config.py # 配置文件 ├── models.py # 数据模型 ├── extensions.py # 扩展对象初始化 ├── requirements.txt # 依赖包列表 ├── README.md # 项目说明文档 ├── utils/ │ ├── __init__.py │ ├── decorators.py # 登录校验装饰器 │ └── helper.py # 通用工具函数 ├── views/ │ ├── __init__.py │ ├── auth.py # 用户认证路由 │ ├── seat.py # 座位与预约路由 │ └── admin.py # 管理后台路由 ├── static/ │ ├── css/ │ ├── js/ │ └── images/ ├── templates/ │ ├── base.html │ ├── index.html │ ├── login.html │ ├── register.html │ ├── reserve.html │ ├── my_reserve.html │ └── admin/ │ ├── dashboard.html │ ├── user_manage.html │ └── seat_manage.html └── docs/ ├── 需求分析.md ├── 数据库设计说明.md └── 使用手册.md

关于交付物，我一直强调一个观点：源码、数据库脚本、文档三位一体，缺一个都会在验收环节吃大亏。数据库脚本一定要单独放一份SQL文件，文档里面要写清楚怎么导入，这个我在后文实操部分会详细说。

2. 数据库设计：预约系统的地基

2.1 核心表结构设计

我见过太多同学一上来就写代码，结果做到预约冲突那块发现数据库表设计根本撑不住，回去改表结构时想死的心都有。数据库是预约系统的地基，表设计直接决定你的业务逻辑好不好写。

这套项目的数据库，我设计了四张核心表：

用户表（users）

这里有个容易忽略的点：role字段和status字段一定要分开。role是权限标识，status是账号状态。有些同学用一个字段又想表示角色又想表示禁用状态，结果搞出各种奇怪的魔数，后期维护简直灾难。

座位表（seats）

座位的状态字段是这个表的核心。我建议用数字做状态码，但代码里一定要用常量或者枚举去引用，不能直接裸写数字。比如定义SEAT_STATUS_FREE = 0这种，后面改状态的时候才不容易出错。

预约记录表（reservations）

这张表是整个系统的核心，后面讲业务逻辑的时候会反复提到。注意这里我把预约日期和时间段分开存了，因为图书馆预约通常是"某一天某个时间段"，合在一起存反而不好查询和统计。

违规记录表（violations）

违规表看起来简单，但它是"黑名单机制"的数据来源。很多同学的课设败在这个地方：规则写不清楚，违规记录和用户管理对不上账。我的建议是预约和违规解耦，每张表管好自己的事，要用的时候再join查。

2.2 状态机与时间规则设计

坐位预约系统最考验逻辑的不是新增删除这种基本操作，而是状态流转。座位有状态，预约记录也有状态，两个状态之间要联动，这个牵一发动全身的地方，就是整个系统的"心脏"。

预约记录的状态机我这样定义：

已预约(0) → 已签到(1) → 已结束(3) 已预约(0) → 已取消(4) → 终态 已预约(0) → 爽约(5) → 终态 已签到(1) → 已暂离(2) → 已结束(3) 已签到(1) → 已结束(3)

为什么要定义这么细？因为你后面写的每一个接口，本质上都是在驱动这些状态迁移。比如签到接口，做的事情就是"把status为0（已预约）的记录改为1（已签到）"，同时把对应的座位从"已预约"改为"使用中"。状态定义清晰了，代码就是水到渠成的事，状态没理清，写一个接口改一个bug。

时间规则是另一个大头。图书馆的真实规则一般是这样的：

• 预约时段结束前30分钟内可以取消预约；
• 预约开始后15分钟内必须签到，否则自动释放座位并记为爽约；
• 暂离时间超过30分钟，自动释放座位并记一次违规。

这些规则直接决定了你的定时任务怎么写。我的做法是在项目里做一个schedule任务，每分钟跑一次，检查两件事：有没有该签到没签到的超时预约、有没有该从暂离恢复或释放的记录。定时任务用APScheduler，轻量且好集成，不需要额外起服务。

2.3 并发控制与索引设计

座位预约系统有个经典问题：同一时刻好多人抢同一个座位，怎么保证不超卖？

如果在座位的预约记录上不加任何限制，两个用户同时提交预约请求，数据库的检查结果可能都是"这个座位空闲"，然后插入两条记录，座位就超卖了。解决这个问题最常用的办法有两个：

第一种是用数据库的唯一约束。给reservations表加一个联合唯一索引，比如(seat_id, reserve_date, start_time, status)，语义是"同一个座位在同一天同一个时间段只能有一条非取消状态的预约记录"。这样即使并发请求进来，数据库层也会直接挡住重复插入。

第二种是使用事务和行锁。预约时先用SELECT ... FOR UPDATE锁住座位记录，再进行状态检查，然后插入预约记录，最后更新座位状态。整个操作在一个事务里，要么全部成功要么全部回滚。对课设来说，第一种方案就够用了，逻辑简单、不容易出错，还能顺便展示你对数据库约束的理解。

不过要注意，唯一索引加在status上会有个坑：status是会变的。如果用户取消预约，原来的记录status变成4，这时候同一座位的同一时段就能再次预约了。所以唯一索引里不能包含status的终态变更逻辑，我的做法是取消预约时物理删除记录，或者把status改成4的同时把该条的end_time改成过去时间，让唯一索引不生效。更简单的方案是：取消预约直接删掉那条记录，用另一种状态来做审计，这样唯一索引永远只作用于当前有效的预约记录上。

3. 核心业务逻辑实现

3.1 预约流程与抢座逻辑

预约是整个系统最核心的接口。在写代码之前，先在纸上把各种情况列出来：目标座位不存在怎么办？座位已被占用怎么办？用户当天已经有了预约怎么办？用户当前有未完成的违规记录还能预约吗？这些边界情况，答辩老师最爱问的就是"如果...怎么办"。

预约接口的业务流程我拆成五步：

1. 校验用户登录状态和权限；
2. 校验传入参数（日期、开始时间、结束时间、座位ID）的格式和合法性；
3. 检查该用户当天是否已存在有效预约（防重复预约）；
4. 检查目标座位在目标时间段是否空闲（防冲突）；
5. 创建预约记录，更新座位状态。

其中第四步是核心中的核心。我当时的查询条件是这样写的：

# 检查当前时间段是否有冲突预约 conflict = Reservation.query.filter( Reservation.seat_id == seat_id, Reservation.reserve_date == reserve_date, Reservation.status.in_([0, 1, 2]), # 已预约、已签到、已暂离 Reservation.start_time < end_time, Reservation.end_time > start_time ).first()

判断时间段重叠的逻辑是：已有的预约开始时间早于我要预约的结束时间，并且已有预约的结束时间晚于我要预约的开始时间。只要这条查出来有记录，就说明时间冲突了。这个重叠判断写反了的话会出现各种漏判，这是我在这个项目上踩过的最坑的一次，具体后面在问题排查里细说。

时段粒度我定的是30分钟，比如9:00-9:30、9:30-10:00这样分。大家在课设答辩里可以自己定，只要保证前后端校验规则一致就行。

3.2 签到、暂离、释放的闭环

预约只是第一步，整个闭环还包括签到、暂离、释放这几个动作。一个完整的使用周期应该是：预约成功 → 按时签到 → 使用中 → 暂离（可选） → 结束释放。这一条链路做完，你才算真正理解了座位预约的核心业务流程。

签到接口的处理逻辑是：用户到达图书馆，找到约定的座位，点击"签到"。后端需要校验：

• 当前时间是否在约定的签到时间窗口内（我设定的是预约开始前30分钟内到开始后15分钟内，超过这个窗口视为迟到或爽约）；
• 这条预约记录确实是当前用户的且状态为"已预约"。

校验通过后，把预约记录状态改为"已签到"，同时把座位状态改为"使用中"，并把sign_in_time记录为当前时间。

暂离和释放的规则是这样的：用户需要临时离开座位时，可以点击"暂离"。这时候座位状态变为"暂离"，但用户仍保有座位使用权。如果超时未返回，系统自动释放座位并将该次行为记为违规。主动释放的逻辑比较简单——使用完毕后点击"释放"，预约记录状态变为"已结束"，座位状态变为"空闲"。

这里有一个细节要注意：座位状态和预约记录状态必须保持一一对应。比如预约记录是"已签到"，但是座位状态却还停留在"已预约"，这种不一致就是bug的温床。我在代码里把所有状态更新都封装到同一个函数里，每次改动同时更新两张表，避免出现数据不一致的情况。

3.3 违规与黑名单机制

有了签到时限和暂离时限，自然就会出现违反规则的用户。这个模块做得细致，是课设在功能完整性上的一个加分项。

我的设计是这样的：用户超过预约开始时间15分钟仍未签到的，记一条"爽约"违规记录；暂离超过30分钟未返回的，记一条"超时暂离"违规记录。当用户在近7天内累计违规达到3次，系统将其账号加入黑名单，禁止预约7天。

黑名单的检查逻辑也可以直接放进预约接口里，预约前先查一下这个用户近期的违规次数，超了就弹"预约受限"的提示。这样做的好处是你不需要额外搞一套复杂的权限系统，一个简单的查询就能支撑起整个规则引擎，课设完全够用。

管理端界面我会单独做一个违规记录列表，方便管理员查看所有用户的违规明细，也可以手动取消某个用户的违规记录。手动处理这类"人工兜底"的设计，在答辩时提一嘴，老师会觉得很周到。

4. 实操过程与关键代码

4.1 环境准备与项目初始化

动手写代码之前，环境要先搭好。这套项目依赖的Python包我整理在requirements.txt里，核心依赖如下：

Flask==2.3.3 Flask-SQLAlchemy==3.1.1 Flask-Login==0.6.3 APScheduler==3.10.4 PyMySQL==1.1.0 cryptography==41.0.7

安装依赖就一条命令：

pip install -r requirements.txt

数据库我默认用MySQL。如果是本地开发测试，把config.py里的连接串改成SQLite也可以零成本跑起来，方便没有装MySQL环境的同学做演示。config.py里大概是这样的：

import os BASE_DIR = os.path.abspath(os.path.dirname(__file__)) class Config: SECRET_KEY = os.environ.get('SECRET_KEY') or 'dev-secret-key' SQLALCHEMY_TRACK_MODIFICATIONS = False class DevConfig(Config): # 默认使用 SQLite，方便快速启动 SQLALCHEMY_DATABASE_URI = 'sqlite:///' + os.path.join(BASE_DIR, 'library.db') DEBUG = True class ProdConfig(Config): SQLALCHEMY_DATABASE_URI = os.environ.get('DATABASE_URL') or \ 'mysql+pymysql://root:password@localhost/library_seat?charset=utf8mb4'

注意一下Flask-SQLAlchemy 3.x版本里，以前在__init__.py里直接db = SQLAlchemy(app)的写法已经不太推荐了。正确做法是在extensions.py里先db = SQLAlchemy()，然后在app.py里db.init_app(app)。这样延迟绑定，避免循环导入的问题。

模型的定义我这里放几个关键表的完整代码，方便你直接对照。

# models.py from datetime import datetime from werkzeug.security import generate_password_hash, check_password_hash from extensions import db class User(db.Model): __tablename__ = 'users' id = db.Column(db.Integer, primary_key=True) username = db.Column(db.String(50), unique=True, nullable=False, index=True) password_hash = db.Column(db.String(255), nullable=False) real_name = db.Column(db.String(50)) role = db.Column(db.SmallInteger, default=0) # 0-普通用户 1-管理员 status = db.Column(db.SmallInteger, default=1) # 0-禁用 1-正常 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) class Seat(db.Model): __tablename__ = 'seats' id = db.Column(db.Integer, primary_key=True) floor = db.Column(db.String(20), nullable=False) area = db.Column(db.String(50), nullable=False) seat_no = db.Column(db.String(20), nullable=False) status = db.Column(db.SmallInteger, default=0) # 0-空闲 1-已预约 2-使用中 3-暂离 4-禁用 description = db.Column(db.String(255)) class Reservation(db.Model): __tablename__ = 'reservations' __table_args__ = ( db.UniqueConstraint('seat_id', 'reserve_date', 'start_time', 'status', name='uq_seat_date_start_status'), ) id = db.Column(db.Integer, primary_key=True) user_id = db.Column(db.Integer, db.ForeignKey('users.id'), nullable=False, index=True) seat_id = db.Column(db.Integer, db.ForeignKey('seats.id'), nullable=False, index=True) reserve_date = db.Column(db.Date, nullable=False, index=True) start_time = db.Column(db.Time, nullable=False) end_time = db.Column(db.Time, nullable=False) status = db.Column(db.SmallInteger, default=0) created_at = db.Column(db.DateTime, default=datetime.now) checkin_time = db.Column(db.DateTime) release_time = db.Column(db.DateTime)

这里有一个非常关键的地方需要提醒：UniqueConstraint如果加入了status字段，一旦记录状态从0变成其他值，唯一约束就不会挡住新的预约插入了。听起来是好事？不，这里埋着一个隐患。假如status=0时插入了一条预约A，这条记录后来变成了status=3（已结束），此时同样的seat_id、reserve_date、start_time的status=0约束就空了，系统允许再插一条status=0的预约B。数据库层面看起来没问题，但业务上需要保证"同一座位同一时段只有一条有效记录"，这就必须在业务代码里做二次校验，不能只依赖数据库约束。我在前面的3.1里已经写了冲突查询的代码，两条组合到一起才是一个完整的防重复方案。

4.2 登录与权限校验的通用封装

登录认证我用的Flask-Login，这个库会帮我们处理session和当前用户等一堆细节。我封装了一个登录校验的装饰器，使用起来非常方便：

# utils/decorators.py from functools import wraps from flask import redirect, url_for, flash, session def login_required(func): @wraps(func) def wrapper(*args, **kwargs): if not session.get('user_id'): flash('请先登录', 'warning') return redirect(url_for('auth.login')) return func(*args, **kwargs) return wrapper def admin_required(func): @wraps(func) def wrapper(*args, **kwargs): if session.get('role') != 1: flash('需要管理员权限', 'danger') return redirect(url_for('index')) return func(*args, **kwargs) return wrapper

用session传用户ID和角色，而不是Flask-Login推荐的那套current_user机制，是为了减少模板引擎里的耦合。课设项目里怎么简单怎么来，但权限判断的通用性还是要保证。

4.3 预约接口的完整实现

预约接口是整个系统的核心战场，我把它完整贴出来，大家可以直接对照改造：

# views/seat.py from datetime import datetime, timedelta, date, time from flask import Blueprint, request, jsonify, session from models import db, Seat, Reservation, Violation from utils.decorators import login_required seat_bp = Blueprint('seat', __name__) @seat_bp.route('/api/reserve', methods=['POST']) @login_required def reserve(): data = request.get_json() seat_id = data.get('seat_id') reserve_date = data.get('reserve_date') start_time = data.get('start_time') end_time = data.get('end_time') # 参数校验 if not all([seat_id, reserve_date, start_time, end_time]): return jsonify({'code': 400, 'msg': '参数不完整'}), 400 user_id = session['user_id'] # 1. 检查用户是否有违规限制 today = date.today() week_ago = today - timedelta(days=7) recent_violations = Violation.query.filter( Violation.user_id == user_id, Violation.created_at >= week_ago ).count() if recent_violations >= 3: return jsonify({'code': 403, 'msg': '违规过于频繁，预约功能已被限制'}), 403 # 2. 检查用户当天是否已有有效预约 existing = Reservation.query.filter( Reservation.user_id == user_id, Reservation.reserve_date == reserve_date, Reservation.status.in_([0, 1, 2]) ).first() if existing: return jsonify({'code': 409, 'msg': '当天已有预约记录，请勿重复预约'}), 409 # 3. 检查座位是否存在且状态允许预约 seat = Seat.query.get(seat_id) if not seat or seat.status == 4: return jsonify({'code': 404, 'msg': '座位不存在或已禁用'}), 404 # 4. 检查时间段冲突 start_dt = datetime.strptime(start_time, '%H:%M').time() end_dt = datetime.strptime(end_time, '%H:%M').time() conflict = Reservation.query.filter( Reservation.seat_id == seat_id, Reservation.reserve_date == reserve_date, Reservation.status.in_([0, 1, 2]), Reservation.start_time < end_dt, Reservation.end_time > start_dt ).first() if conflict: return jsonify({'code': 409, 'msg': '该时段座位已被预约'}), 409 # 5. 创建预约并更新座位状态 new_reservation = Reservation( user_id=user_id, seat_id=seat_id, reserve_date=reserve_date, start_time=start_dt, end_time=end_dt, status=0 ) seat.status = 1 db.session.add(new_reservation) db.session.commit() return jsonify({'code': 200, 'msg': '预约成功'}), 200

这段代码看着不长，但每一步都不能少。尤其是第4步的时间段冲突判断，我前前后后调过好几版，最初用的是Reservation.start_time <= start_dt这种简单比较，导致"9:00-10:00已经有人预约，9:30-10:30再来约"这种交叉重叠的场景完全没拦住。后来改成现在的写法才彻底解决。

4.4 定时任务与自动释放

前面提到过超时未签到、暂离超时自动释放，这需要定时任务来驱动。用APScheduler的BackgroundScheduler实现，代码非常简单：

# app.py from apscheduler.schedulers.background import BackgroundScheduler from datetime import datetime, timedelta def auto_release_expired(): """每分钟执行一次，处理超时未签到和暂离超时""" now = datetime.now() # 1. 将超过预约开始时间15分钟仍未签到的记录置为爽约 expired_reservations = Reservation.query.filter( Reservation.status == 0, Reservation.reserve_date == now.date(), Reservation.start_time < (now - timedelta(minutes=15)).time() ).all() for res in expired_reservations: res.status = 5 # 爽约 seat = Seat.query.get(res.seat_id) seat.status = 0 # 释放座位 db.session.add(Violation( user_id=res.user_id, reserve_id=res.id, violation_type='爽约', description='超过预约时间15分钟未签到' )) # 2. 将暂离超过30分钟的记录自动释放 late_release_time = now - timedelta(minutes=30) ... db.session.commit() scheduler = BackgroundScheduler() scheduler.add_job(auto_release_expired, 'interval', minutes=1) scheduler.start()

这里有个实现细节要注意：定时任务跑起来之前，要确保数据库连接已经初始化，否则会报"working outside of application context"的错误。解决办法是给任务函数加上with app.app_context():包裹，或者像上面这样在函数内部调用模型操作之前手动推入上下文。

定时任务这块不需要做得太复杂，分钟级的扫描对课设完全够用。你可以在文档里写清楚"系统每分钟自动检查一次超时情况"，这个设计本身就是抓分点。

4.5 数据库初始化与示例数据

数据库脚本我会单独放在docs/library_seat.sql和项目根目录下的init_db.py里。init_db.py的作用是创建所有表并插入一些初始数据，这样打包交付给别人的时候，对方不用手动建表，跑一下脚本就能看到效果。

# init_db.py from app import app from models import db, User, Seat from werkzeug.security import generate_password_hash import random def init_tables(): with app.app_context(): db.create_all() # 创建管理员账号 if not User.query.filter_by(username='admin').first(): admin = User(username='admin', role=1, status=1, real_name='管理员') admin.set_password('admin123') db.session.add(admin) # 生成示例座位，比如3层楼，每层2个区域，每个区域20个座位 if Seat.query.count() == 0: for floor in ['1F', '2F', '3F']: for area in ['A区', 'B区']: for row in range(1, 3): for col in range(1, 11): seat_no = f'{row:02d}{col:02d}' db.session.add(Seat( floor=floor, area=area, seat_no=seat_no, status=0 )) db.session.commit() print("数据库初始化完成：已创建表结构和示例数据") if __name__ == '__main__': init_tables()

这里的示例数据生成用循环嵌套模拟真实图书馆座位编号，思路很简单但很实用。管理员默认账号密码是admin/admin123，文档里一定要标注清楚，让对方拿到项目就能立刻登录使用。

5. 常见问题与排查技巧

5.1 环境与依赖层面的坑

问题1：安装依赖时cryptography包编译失败。

多见于Windows环境或者Python 3.12+版本。解决方案是先用pip安装预编译版本，别用源码编译：

pip install cryptography --only-binary :all:

如果还是失败，就把PyMySQL和cryptography都卸了重装，PyMySQL对MySQL 8.0以上的认证方式依赖这个加密库。

问题2：Flask-SQLAlchemy版本冲突，模型怎么都查不到数据。

这个坑十个人有八个人会踩。Flask-SQLAlchemy 3.x版本里，db.Model的元数据和2.x不完全兼容。如果你的代码是从别处抄的旧版写法，可能出现表能创建但查询报Table 'xxx' is already defined for this MetaData instance之类的错。排查办法是把所有db实例全部统一，只从一个地方导入，不要在每个文件里各自实例化。我上面extensions.py的写法就是为了避免这个问题。

5.2 数据库层面的坑

问题3：中文数据插入MySQL乱码。

创建数据库的时候必须明确指定utf8mb4编码：

CREATE DATABASE library_seat DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;

连接串里也要加上charset参数：mysql+pymysql://root:password@localhost/library_seat?charset=utf8mb4。只改一处的话，乱码问题还会时不时冒出来。

问题4：唯一约束和业务逻辑冲突。

这个就是我前面提到的uq_seat_date_start_status那个约束。当你取消预约不是删除记录而是更新status的时候，同一座位同一时段可能会插入第二条记录，但业务上不应该出现。我的建议是：直接删掉取消的预约记录，或者把唯一索引里的status字段去掉。如果你不想丢失历史记录，可以加一个is_deleted字段并把唯一索引建立在(seat_id, reserve_date, start_time, is_deleted)上。方案很多，关键是你要想清楚自己用的是哪套，别混着来。

5.3 业务逻辑层面的坑

问题5：时间比较的时候字符串和time类型搞混。

前端传过来的时间是字符串，例如"09:30"，数据库里存的是time类型。直接拿字符串和时间比较，Python会报TypeError。一定要先做解析：

start_dt = datetime.strptime(start_time, '%H:%M').time()

还有datetime和date的区别，reserve_date我建议前端传"YYYY-MM-DD"格式的字符串，后端用datetime.strptime(reserve_date, '%Y-%m-%d').date()转日期类型。

问题6：并发预约偶发的超卖。

如果你用了事务但隔离级别不对，SELECT查空闲在并发下也会读到脏数据。课设场景下最简单的方案是直接用SQLAlchemy的with_for_update()行锁，或者干脆依赖前面提到的唯一约束让数据库报错，然后在代码里捕获IntegrityError转成"预约失败"提示。想深挖的老师如果问你"你的系统怎么防超卖"，你能说出"数据库唯一约束兜底 + 业务层预检查"这套组合拳，已经算很扎实了。

6. 项目答辩技巧与评分亮点

最后聊点实际的，怎么拿高分。项目做完只是第一步，答辩讲好才是真本事。

一个很实用的思路是：别按代码模块讲，按"用户故事"讲。你从"一个学生想预约明天早上的座位"开始，演示他登录、选座、预约、签到、暂离、释放的完整流程，中间穿插系统规则：如果超时未签到会怎样、如果和别人时间冲突会怎样。这样讲，老师跟着你的节奏走，思路非常清晰，而且每个功能点都能对应到实际的业务价值上。

另一个加分项是主动说出你的设计取舍。比如"我这里没有用外键约束，因为课设数据量小，MySQL的InnoDB默认会建外键约束，但我在删除数据时会先手动检查关联记录，避免外键约束带来的耦合"。这种话一说出来，老师就知道你确实理解了数据库设计原理，而不是只会建表。

演示的时候建议准备两套环境：一套是已经造好数据的成品环境，直接用；一套是空数据库环境，现场从init_db.py开始跑。万一演示到一半环境挂了，你还能从容地现场初始化，这种应急表现在老师眼里是加分的。

文档部分我会特别强调"数据库设计说明"这一章，把每张表的字段含义、状态流转、约束设计讲清楚，配合ER图。课程设计的评分标准里文档占比普遍不低，一份详实的设计文档比冗长的源码管用得多。

这套项目后续还可以扩展的方向不少：比如对接校园一卡通接口做身份认证、增加占座推荐算法、实现座位使用率统计的可视化大屏。哪怕是已经定稿的课设，把这些方向写进"不足与展望"章节，都能让论文显得更有思考深度。