简介基于Python开发的图书馆自动预约座位系统源码包面向高校学生、计算机相关专业课程设计及毕业设计人群解决图书馆座位难预约、定时抢座等痛点。项目支持通过GitHub Actions在每周五、周六早晨自动运行可设置学号、密码和座位号实现次日预约并可选集成pushplus与微信公众号推送预约结果完整覆盖预约流程的自动化需求。压缩包共18个文件包含2个Python核心脚本、GitHub Actions工作流配置yml、环境依赖说明txt、项目配置文件xml/iml以及7张操作流程截图和Readme文档总大小仅1.73MB结构清晰便于上手。目前已有628人学习下载适合需要完成课设、毕设或希望学习自动化脚本与GitHub Actions实战的读者借鉴附带详细配置教程和常见问题排查说明可直接运行或在此基础上扩展功能。1. 图书馆自动预约座位系统一个“看起来简单”的Python实战项目做Python项目练手很多人会选爬虫、数据分析但图书馆自动预约座位系统往往被低估。去年我帮学校图书馆梳理这套系统时发现真正难的不是写一个“预约按钮”而是高并发的座位状态一致性——同一个座位不能同时被两个人约走到点了座位要自动释放中途离座还要判断是不是恶意占座。一个源码包能把这些点讲清比单纯看语法教程有用得多。这篇笔记我会按源码和项目使用说明的常见结构把数据模型、预约流程、并发控制和踩过的坑拆开讲适合刚学完Python基础、想读源码或做课设的读者。你会看到它不是一个“玩具项目”而是一套能真正落到图书馆业务里的可运行方案。2. 系统怎么拆从数据模型到预约状态机这套系统的核心价值是把“座位”变成一种可分配的资源。要支撑预约、签到、暂离、释放这一串动作第一步不是写接口而是把数据模型定清楚。很多刚接触源码的人喜欢先看路由和视图结果被一堆查询逻辑绕晕。我习惯反过来先看表结构再推流程最后读代码这样整套系统的主干一下就清楚了。2.1 三张表搞定核心数据座位、用户、预约记录常见的图书馆预约项目会设计三张基础表座位表、用户表、预约记录表。座位表存楼层、阅览室和座位编号用户表存学号和信用分预约记录表存每次预约的时间段和状态。下面是我从多个类似项目里归纳出的最简版本用SQLAlchemy表示from sqlalchemy import Column, Integer, String, DateTime, Boolean, ForeignKey from sqlalchemy.ext.declarative import declarative_base from sqlalchemy.orm import relationship Base declarative_base() class Seat(Base): __tablename__ seat id Column(Integer, primary_keyTrue, autoincrementTrue) room Column(String(50), nullableFalse) # 阅览室编号如 A201 seat_no Column(String(20), nullableFalse) # 座位编号如 A201-01 is_available Column(Boolean, defaultTrue) # 当前是否可预约 class User(Base): __tablename__ user id Column(Integer, primary_keyTrue, autoincrementTrue) student_id Column(String(20), uniqueTrue, nullableFalse) name Column(String(50)) credit Column(Integer, default100) # 信用分用于惩罚恶意占座 class Reservation(Base): __tablename__ reservation id Column(Integer, primary_keyTrue, autoincrementTrue) user_id Column(Integer, ForeignKey(user.id)) seat_id Column(Integer, ForeignKey(seat.id)) start_time Column(DateTime, nullableFalse) end_time Column(DateTime, nullableFalse) status Column(String(20), defaultBOOKED) # BOOKED/SIGNED/RELEASED/NO_SHOW created_at Column(DateTime, nullableFalse)这里有个容易被忽略的设计点只要两张表就够了为什么非要拆出单独的用户表因为预约系统一旦涉及信用分和黑名单就必须把用户信息和行为记录分离。比如迟到释放后要扣分如果用户信息嵌在预约记录里后续统计恶意占座就得反复扫全表。拆成独立表后每条预约通过user_id关联到具体用户信用分的增减只需要更新user表。is_available字段看起来是个简单的布尔值实际上它是整个状态机的“入口”。把座位当前是否空闲直接放在座位表里查询可以很快但这个字段也最容易造成数据不一致因为它在预约过程中会被多次改写。我会在后面的并发部分专门讲它为什么是坑。如果你打算改成多馆多楼层可以在Seat里再加一个library_id外键但学习项目保持三张表就够消化了。2.2 预约主流程查询、锁定、确认、释放的完整链路预约系统的操作流可以分为四个阶段查询可用座位、锁定座位、生成预约记录、定时释放未签到座位。源码里的接口设计通常也按这个拆前端先调查询接口拿到可预约座位列表再调预约接口提交。下面是客户端调用预约接口的典型方式import requests from datetime import datetime def book_seat(api_base, seat_id, user_id, start_time, end_time): payload { seat_id: seat_id, user_id: user_id, start_time: start_time.isoformat(), end_time: end_time.isoformat() } resp requests.post(f{api_base}/api/reserve, jsonpayload, timeout5) data resp.json() if data.get(code) 0: print(预约成功预约编号:, data[reservation_id]) else: print(预约失败:, data.get(msg))这个例子里的seat_id和user_id都来自前面的查询列表start_time和end_time必须是 ISO 格式字符串很多人在这一步会用错时间格式。timeout5是防止预约接口在高并发时挂起拖死客户端。真正到服务端处理逻辑要比这段代码复杂得多先查座位是否存在再查该时间段有没有冲突然后写预约记录并更新座位状态——顺序错一步就会出现“预约记录生成了座位还是可预约”的怪象。我在源码里看到一种典型实现用事务把“查冲突”和“写记录”包在一起。如果只查了冲突再插入两个请求同时进来时都能通过查询最后产生重复预约。所以正确的做法是给数据库加唯一约束比如(seat_id, start_time, end_time)不允许重复从底层挡住并发问题。预约完成后系统会定时扫描所有BOOKED状态的记录如果当前时间超过start_time一定分钟数还没有签到就把状态改为NO_SHOW同时把对应座位重新置为可预约。这条自动释放逻辑是整个系统“活”起来的关键。2.3 座位状态机为什么用状态字段而不是直接删除记录很多新手第一次写释放逻辑会直接把预约记录删除再把座位置为空闲。这个做法在演示时没问题但你一查历史数据就什么都没了。真实图书馆要统计上座率、高峰期占用时长甚至追查某天谁占了位子这些需求全靠预约记录所以绝不能删除而是用状态字段流转。下面是一张我从项目使用说明里提炼出的状态表状态含义触发动作后续动作BOOKED预约成功未签到提交预约到点自动释放或签到成功SIGNED已签到正在使用扫码/刷卡签到离开时释放或暂离RELEASED手动释放或超时释放用户主动释放/系统自动释放座位恢复可预约NO_SHOW预约未到超时未签到扣信用分座位释放为什么不用删除记录来代表释放因为状态流转能保证审计链条完整。比如用户9点预约9点15分没来系统把状态从BOOKED改成NO_SHOW座位释放这个过程记录在案之后用户申诉“我明明来了只是忘签到”管理员还能通过日志还原现场。如果直接删记录这张表只剩签到的人无法识别恶意占座。状态机的另一个好处是释放逻辑可以写成统一的“状态迁移”方法而不是散落在各个路由里。例如release_seat(reservation_id)只处理SIGNED和BOOKED状态不符合条件就拒绝避免重复释放。源码里通常会有一个seat_machine.py或类似模块把这些迁移规则集中管理读起来非常舒服。你在学习时也要养成这个习惯宁可多写一个状态常量类也不要到处用字符串魔法值。3. 源码核心模块定时抢座、冲突处理和迟到释放这一章是真正能从源码里“抄作业”的部分。图书馆预约系统的价值不只是提供一个查询界面而是能在开馆前准点放号、在并发高峰不发生超卖、在有人迟到时自动释放座位。我会按这三个点拆开每一段都给关键代码和参数说明。3.1 用 requests APScheduler 实现准点预约图书馆的系统通常每天早上固定时间放当天座位比如 7:30 开放预约。学生端的“抢座”其实就是一个定时任务到点后批量请求预约接口。源码里最常见的实现是 APScheduler 配合 requests因为 APScheduler 支持 cron 表达式比 while True sleep 稳定得多还能设置时区和错过执行策略。from apscheduler.schedulers.blocking import BlockingScheduler import requests from datetime import datetime API_URL http://127.0.0.1:5000/api/reserve def daily_book(): now datetime.now() # 设定今天上午 8:00 到 10:00 的使用时段 payload { seat_id: 101, user_id: 20240001, start_time: now.replace(hour8, minute0, second0, microsecond0).isoformat(), end_time: now.replace(hour10, minute0, second0, microsecond0).isoformat() } try: resp requests.post(API_URL, jsonpayload, timeout3) data resp.json() if data.get(code) 0: print(抢座成功:, data[reservation_id]) else: print(没抢到:, data.get(msg)) except requests.Timeout: print(预约请求超时下一轮再试) if __name__ __main__: scheduler BlockingScheduler(timezoneAsia/Shanghai) scheduler.add_job(daily_book, cron, hour7, minute30, misfire_grace_time60) scheduler.start()这个例子里的关键参数有三个第一timezoneAsia/Shanghai必须显式指定否则 APScheduler 默认用服务器本地时区如果服务器是 UTC任务会晚 8 小时才执行这在预约系统里是致命的问题第二misfire_grace_time60表示任务错过原定执行时间后60 秒内还可以补执行避免因网络抖动漏跑第三timeout3限制单次请求最长等待预约高峰时接口可能变慢如果 timeout 设太长定时任务会阻塞下一轮都跑不了。这里还得提一个很多人踩过的细节校园网环境里预约接口往往需要带 Session Cookie所以正式脚本里要先登录一次用requests.Session()保存登录态再在daily_book里复用。没有登录态直接发请求会返回 401或者被网关拦下来。你可以把登录逻辑放在scheduler.start()之前这样不会影响定时任务主体。3.2 乐观锁和唯一约束并发下单不翻车的两个保险并发控制是预约系统最核心的难点。假设 50 个人同时抢最后一个座位如果代码写成“先查询座位是否空闲再更新为已预约”那么 50 个请求都可能查询到空闲然后全部更新成功超卖就发生了。解决思路不是让代码更“聪明”而是利用数据库的原子更新。我推荐用乐观锁也就是在更新时带上条件让数据库只匹配当前仍可预约的记录from sqlalchemy import update def reserve_with_optimistic_lock(session, seat_id, user_id, start, end): # 关键WHERE 条件里带上 is_available True result session.execute( update(Seat) .where(Seat.id seat_id, Seat.is_available True) .values(is_availableFalse) ) if result.rowcount 0: raise Exception(座位已被他人预约) reservation Reservation( user_iduser_id, seat_idseat_id, start_timestart, end_timeend, statusBOOKED ) session.add(reservation) session.commit() return reservation.id这里的点在于result.rowcount返回的是真正被更新的行数。当两个事务同时执行这条update数据库的行锁会保证其中一个先执行成功另一个等到锁释放后再执行时发现is_available已经不是True更新行数为 0于是抛异常。这就是乐观锁的核心不提前查状态而是直接在修改时确认状态。光有乐观锁还不够seat表只能保证一个座位不能被同时预约但同一个用户会不会重复预约同一时段即使is_available更新成功用户可能在上一个事务里已经约过一次这里依然能插入第二条预约记录。要彻底堵住这个漏洞必须在Reservation表上加联合唯一约束# 在模型定义中补充 __table_args__ ( UniqueConstraint(seat_id, start_time, end_time, nameuq_seat_time), UniqueConstraint(user_id, start_time, nameuq_user_time), )第一个约束防止同一个座位在同一时间段被两次预约第二个约束防止同一个用户在同一时间段约两个不同座位。这两条约束和乐观锁一起才算把并发问题兜住。这个项目里如果少了唯一约束你可能测 10 次都发现不了一旦上线第一个高峰就会炸。建议你看源码时先搜UniqueConstraint和rowcount这两个关键词直接决定系统能不能扛住抢座高峰。3.3 迟到自动释放与信用分让座位活起来预约成功后总有人不会准时来。如果系统不处理座位会白白空着。图书馆预约系统的典型做法是允许 15 分钟宽限期超过后自动释放座位并把预约状态改为NO_SHOW同时给用户扣信用分。这个逻辑通常由一个每分钟运行一次的定时任务完成from apscheduler.schedulers.blocking import BlockingScheduler from datetime import datetime, timedelta def release_no_show(): now datetime.now() deadline now - timedelta(minutes15) # 查出所有已过期且仍未签到的预约 expired session.query(Reservation).filter( Reservation.status BOOKED, Reservation.start_time deadline ).all() for res in expired: # 释放座位 session.execute( update(Seat) .where(Seat.id res.seat_id) .values(is_availableTrue) ) # 更新预约状态 res.status NO_SHOW # 扣信用分 session.execute( update(User) .where(User.id res.user_id) .values(creditUser.credit - 10) ) session.commit() scheduler BlockingScheduler(timezoneAsia/Shanghai) scheduler.add_job(release_no_show, interval, minutes1) scheduler.start()这段代码里的关键参数是minutes1它决定了释放座位的最大延迟。如果设成 5 分钟那么用户至少要等 20 分钟才能看到座位被释放如果设成 30 秒数据库压力又会变大。我一般建议 1 分钟一个周期既及时又能控制负载。另一个细节是在循环里做更新操作容易写出 N1 条 SQL这里我直接用了批量查询再循环更新学习项目可以接受生产环境最好改成一条 UPDATE JOIN 语句。信用分是这个系统的隐性规则。每次NO_SHOW扣 10 分当信用分低于 60 时禁止预约。这个规则要在查询接口里也做一层判断否则用户还是能刷到预约表单。源码里可能把credit写成一个普通整数但你要理解它是整个惩罚机制的核心。我见过有人把信用分扣成负数还不影响预约就是因为查询参数里漏了判断。这块逻辑不复杂但很容易被忽略。4. 从项目使用说明到成功跑通四个常见坑拿到一个源码包第一件事是读项目使用说明但照说明做也会踩坑。这一章我会列四个最典型的翻车现场每个都按“现象 → 原因 → 解决”的顺序讲。这些都是我在跑同类项目时真正遇到过的问题不是凭空推测。4.1 Python版本和依赖安装按说明装也会翻车现象项目使用说明写着“Python 3.6 及以上”你用 Python 3.10 安装依赖后运行报ModuleNotFoundError: No module named pkg_resources或者某个第三方库编译失败。原因很多老项目是在 Python 3.6 或 3.7 环境下开发的依赖文件里的版本号都是当年的 pin 版。比如SQLAlchemy1.3.x在 Python 3.10 上可能没有预编译 wheel而gevent、lxml这类库在最新版 Python 上需要重新编译环境缺少编译工具就直接失败。比较隐蔽的是pkg_resources在较新 Python 中被移出了默认环境导致依赖工具链本身出问题。解决不要直接在系统 Python 里装用虚拟环境隔离版本Python 版本最好和项目说明一致。如果你使用的是 Python 3.10先尝试pip install -r requirements.txt失败时逐一把库升级到支持 3.10 的版本。升级后有可能会遇到 API 变了比如datetime.utcnow()被弃用这类兼容性修改在源码注释里通常会标出来你要能认出来。python -m venv venv source venv/bin/activate # Windows 下用 venv\Scripts\activate pip install -r requirements.txt这里有个细节创建虚拟环境时python命令指向的版本很重要。如果你机器上同时有 Python 3.8 和 3.11一定要用python3.8 -m venv venv指定版本否则默认可能拉到 3.11然后依赖又开始翻车。运行前再执行python -c import sys; print(sys.version)确认。4.2 时间与时区预约系统里最难调试的“黑匣子”现象定时预约任务每天提前 8 小时执行预约记录里的时间和页面显示的时间对不上释放任务总是延迟几分钟才触发。原因系统里多处使用了本地时间但服务器和数据库的时区不一致。常见的是服务器设置了 UTC数据库连接字符串里也没指定时区Python 的datetime.now()取的是操作系统本地时间而APScheduler默认又用自己的时区配置几处一混时间就乱了。解决统一规范所有后端逻辑只使用 UTC 时间存储和运算对外展示时再转换为Asia/Shanghai。数据库连接字符串里加?charsetutf8mb4同时把数据库会话时区设置为08:00。在源码里搜索datetime.now()尽量替换为datetime.now(timezone.utc)。定时任务则必须按我前文说的在调度器里显式设置timezoneAsia/Shanghai。from datetime import datetime, timezone, timedelta # 统一使用 UTC 存储 now_utc datetime.now(timezone.utc) # 展示时转北京时区 local_tz timezone(timedelta(hours8)) now_local now_utc.astimezone(local_tz)排查时优先看数据库里存的原始时间不要看页面。你在 MySQL 里执行select now()如果返回的是 UTC 而不是北京时间那多半是连接层或系统时区没配好。这类问题最恶心的地方在于它不会报错只有到点不执行或时间错乱时你才会发现所以项目使用说明里如果提到时区一定要看完。4.3 事务与锁为什么测试没问题上线就超卖现象本地单机测试时连续点击预约都成功看起来一切正常。一旦用并发脚本模拟 50 人同时抢一个座位系统返回的预约成功数远超座位数。随机抽样发现两条预约记录指向同一个座位且时间段重叠。原因代码里用了“先查询再插入”的逻辑没有加锁或唯一约束。本地点击是串行的很难触发并发竞态哪怕你用两个线程模拟如果数据库表里没有唯一约束两个请求都能通过“查询空闲”这一步然后插入两条记录。测试环境之所以没暴露是因为你一次只请求一两秒重叠窗口太小。解决在Reservation表加联合唯一约束并把预约插入改成“先更新座位状态再写预约记录”的顺序。同时给座位查询接口增加一个参数for_update在高频预约场景下使用悲观锁from sqlalchemy import select from sqlalchemy.orm import with_for_update # 悲观锁示例查询时锁定该行直到事务结束 seat session.execute( select(Seat).where(Seat.id seat_id).with_for_update() ).scalar_one() if not seat.is_available: raise Exception(座位不可约) seat.is_available False session.add(Reservation(...)) session.commit()悲观锁和乐观锁的取舍学生项目优先用乐观锁加唯一约束代码简单且性能好如果预约高峰非常集中悲观锁可以避免大量更新失败后的重试但会有锁等待。我一般建议先拿脚本压测压出问题再决定要不要换。源码里如果有with_for_update或rowcount说明作者考虑了并发如果没有你得自己补上。4.4 前端状态刷新页面显示有座后台已经没座现象用户在选座页面看到 10 个空位点进去提交时却提示座位已被预约刷新后空位变成 3 个。高峰期甚至出现“页面有座但永远约不上”的情况。原因前端座位列表是查询接口返回的快照不是实时状态。如果系统每 30 秒轮询一次那么这 30 秒内被其他人预约的座位并不会立刻消失。更糟的是一些源码把查询和预约分成了两个接口查询时不锁定座位预约时才发现冲突。解决前端轮询间隔从 30 秒缩短到 5 秒并在预约失败时立即重新拉取列表。后端查询接口可以加一个availabletrue条件避免把已预约的座位返回给前端。另外给座位表加一个version字段前端携带版本号请求如果版本不一致就返回冲突实现简单的增量更新。这些改动不算大但能明显减少“白点一下”的体验问题。如果你在改源码优先处理这个因为座位状态不一致会让用户对整个系统失去信任。5. 把学习项目改成能用的系统验证、部署与二次开发源码跑通只是第一步真正要投入实际使用还得补验证和扩展。这一章我会给你一套不写复杂框架的验证方法以及三个值得做的进阶方向。5.1 用模拟数据做全链路验证不要开浏览器手动点写个脚本模拟真实用户行为。下面这个并发脚本可以快速验证超卖是否修复import threading import requests from concurrent.futures import ThreadPoolExecutor SEAT_ID 101 USER_ID 20240001 def try_book(_): payload { seat_id: SEAT_ID, user_id: USER_ID, start_time: 2025-01-01T08:00:00, end_time: 2025-01-01T10:00:00 } try: resp requests.post(http://127.0.0.1:5000/api/reserve, jsonpayload, timeout3) return resp.json().get(code) except Exception: return -1 with ThreadPoolExecutor(max_workers20) as pool: results list(pool.map(try_book, range(50))) print(成功次数:, results.count(0), 失败次数:, results.count(1))我一般会连跑三轮第一轮 20 并发抢 1 个座位第二轮 50 并发抢 5 个座位第三轮 100 并发抢 10 个座位。如果成功次数正好等于座位数说明乐观锁和唯一约束生效。如果成功次数大于座位数别急着改把数据库里的预约记录按seat_id和start_time分组查重确认是不是真重复数据还是响应码误判。5.2 进阶API化、扫码签到、消息队列学习项目通常用 Flask 的同步接口改造时可以迁移到 FastAPI用 Pydantic 做参数校验用异步接口提升吞吐。座位状态变化用 WebSocket 推给前端就能告别轮询。预约高峰时写操作集中可以引入 Redis 做分布式锁把“座位是否可约”的判断放到 Redis 里减少数据库压力。扫码签到这个动作本质上是把状态从BOOKED改成SIGNED你只需要提供一个按reservation_id或二维码内容查询的接口即可难点不在扫码而在判断二维码是否属于当前用户。我自己做过一次教训总结这个系统的难点从来不是单点功能而是状态一致性。如果你只是应付课设把三张表和状态流转写清楚就够如果你想真正部署到图书馆一定要先压测再上线宁可慢一点也不能出现两个人都约到同一个位子的事故。图书馆预约座位系统看似简单但它是少数能把 Python、数据库、定时任务、并发控制串起来的完整项目。希望这篇拆解能帮你在读源码和做二次开发时少走弯路祝你的项目顺利跑通。本文还有配套的精品资源点击获取