1. 项目定位这套系统到底要解决图书馆里的什么麻烦1.1 核心角色与业务场景每年到三四月份图书馆预约小程序这类题目都会集中冒出来。我带完的这套基于 Spring Boot Vue 微信小程序的图书馆预约系统源码、数据库脚本和配套文档都齐所以干脆把从设计到落地的完整思路整理出来。这套项目表面上是“毕设题目”本质上它是一个典型的全栈预约业务系统。我做的版本以高校图书馆的自习座位预约为主因为这是当前图书馆最普遍的需求。你也能在表结构上直接扩展出“研讨间预约”“图书借阅预约”只需要加一个资源类型字段就行。系统里一共三条主链路读者端微信小程序登录 - 查看区域与座位 - 选择时间段并预约 - 到馆签到 - 离座释放。管理端Vue 后台管理页面 - 维护房间/座位 - 查看预约记录 - 处理违约 - 查看使用率统计。后端Spring Boot 提供统一接口 - 基于 MySQL 处理预约事务 - 返回给前端统一 JSON 结构。很多同学拿到这种项目第一反应是把页面做得像购物 App其实评审老师更看重业务闭环是否完整。你能解释清楚“座位怎么锁”“预约怎么防重复”“超时座位怎么释放”比堆十个页面都管用。1.2 评审老师可能追问的三个点第一是“同一个座位同一时段被两个人同时预约怎么办”。这个问题对应的就是并发控制后面我会专门讲。第二是“用户身份从哪来”。微信小程序里用户不会主动注册必须靠 wx.login 拿 code再由后端去微信服务端换 openid整个系统拿 openid 当用户唯一标识。第三是“座位状态怎么维护”。是预约时就修改座位状态还是签到才修改这直接决定了座位图是否准确。我建议把预约状态做成显式的状态机比如待使用 - 已签到 - 已完成待使用 - 已取消待使用 - 超时。每个状态对应 index 数字前端根据数字显示不同颜色的标签后端用常量类统一管理不要散落在代码里到处写魔法值。2. 技术选型背后的逻辑为什么偏偏是这三个2.1 Spring Boot 版本千万别贪新标题里的 Spring Boot 很多同学会直接去官网下最新版但这恰恰是毕设翻车最频繁的地方。现在 Spring Boot 3.x 要求 JDK 17 起步包名也从 javax 换成了 jakarta很多老教程、老代码直接跑不起来。网上那些“springboot 版本太高导致项目无法启动”的问题十有八九是版本和 JDK 不匹配。这套项目我放在 Spring Boot 2.7.x 上配合 JDK 8 或 JDK 11能兼容绝大多数学校的机器环境。管理端用 Vue 3 Vite Element Plus小程序端用微信原生框架。选 Vue 3 不是因为“新”而是 Vite 启动速度确实快演示的时候不用干等。如果学校只装了 JDK 17那也可以把 Spring Boot 升到 3.x但要注意替换所有 javax.servlet 为 jakarta.servletMyBatis 相关依赖也要换成新坐标。我建议你先把 2.7.x 跑通再考虑升级演示。2.2 Vue 管理端和小程序端的分工同一个系统有两个前端很容易搞混。我习惯把它们理解成“操作端”和“展示端”小程序是给读者用的界面要克制核心功能就是选座、预约、看状态Vue 管理端是给管理员用的信息密度要高表格、搜索、筛选、统计是主角。Vue 端页面我规划了登录页、首页统计、房间管理、座位管理、预约记录、用户列表六个路由。首页统计放四个卡片今日预约数、今日签到数、座位使用率、违约人数底下再用 ECharts 画一个近七天的趋势图纯前端图表就能搞定不需要额外后端接口。小程序端页面则控制在五个以内首页展示区域和公告、座位预约页、我的预约列表、个人中心、签到页。不要每个功能都单独开页面否则代码量和体验都会失控。2.3 前后端接口约定直接决定联调效率我不建议后端直接返回一个 Map 或者裸数据因为小程序和 Vue 管理端各自写不同的解析逻辑出问题会非常难查。我这边统一返回{ code: 200, msg: 操作成功, data: {} }code200 表示成功其他值对应业务错误比如 401 表示未登录、403 表示无权限、500 表示服务端异常。前端封装一个 request 方法统一拦截非 200 的 code并自动跳转登录页这样后续加接口几乎不用重复写错误处理。同时所有需要登录的接口都要求在请求头里带Authorization: Bearer token后端用拦截器解析 token解析失败直接返回 401。很多同学把这个逻辑写在每个 Controller 里那是典型的反模式一定要用拦截器抽出来。3. 数据库设计预约系统的核心全在表结构里3.1 核心表清单我的数据库选了 utf8mb4 字符集避免用户昵称里的特殊字符在存储时报错。主要表如下表名作用关键字段t_user微信用户openid, nickname, phone, statust_room房间/区域name, location, open_time, close_time, seat_countt_seat座位room_id, seat_no, row_no, col_no, statust_reservation预约记录user_id, seat_id, reserve_date, start_time, end_time, status这里最需要注意的是 t_reservation 表。预约记录本身是流水数据但座位锁定和取消都依赖它。我写的建表脚本大概长这样CREATE TABLE t_reservation ( id bigint NOT NULL AUTO_INCREMENT, user_id bigint NOT NULL COMMENT 用户ID, seat_id bigint NOT NULL COMMENT 座位ID, reserve_date date NOT NULL COMMENT 预约日期, start_time time NOT NULL COMMENT 开始时间, end_time time NOT NULL COMMENT 结束时间, status tinyint NOT NULL DEFAULT 0 COMMENT 0待使用 1已签到 2已取消 3超时 4已完成, create_time datetime NOT NULL, PRIMARY KEY (id), UNIQUE KEY uk_seat_time (seat_id, reserve_date, start_time, end_time), KEY idx_user_date (user_id, reserve_date) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT座位预约记录表;那个唯一索引uk_seat_time是本表最关键的兜底设计。就算代码里出现并发数据库也会拒绝同一个座位同一时间段的重复插入这也是后面防重复预约最稳的一层。3.2 座位状态和预约状态到底怎么联动常见做法是用户提交预约时同时把 t_seat.status 改成“已占用”退出时改回“空闲”。这套逻辑简单但有一个坑如果用户超时没有签到预约状态虽然变成了“超时”座位状态如果没有同步更新就会一直占着。我推荐用“预约记录反查座位”的方式。座位页面查空闲座位的 SQL不是直接查 t_seat而是查出所有座位后再减去当天存在有效预约记录的座位。这样就不会出现两边状态不一致的问题。如果觉得反查 SQL 写起来复杂退一步可以做成定时任务每隔五分钟扫一次预约表把超时未签到的记录置为“超时”同时把对应座位改成“空闲”。两种方案都能用但你要能向评审解释清楚自己的选择。3.3 增删改查之外统计查询才是加分项图书馆管理员真正想看到的不是每条预约明细而是“今天哪个区域最满”“下午 14 点通常约了多少人”。用一条 group by 就可以统计每个房间的预约量SELECT r.id, r.name, COUNT(res.id) AS total FROM t_room r LEFT JOIN t_seat s ON r.id s.room_id LEFT JOIN t_reservation res ON s.id res.seat_id AND res.reserve_date CURDATE() GROUP BY r.id, r.name ORDER BY total DESC;这种统计 SQL 不复杂但能在文档和答辩里展示你理解业务数据比“我实现了用户的管理”这种描述高级得多。4. 小程序端与 Vue 管理端的核心功能拆解4.1 小程序登录用户从来不主动“注册”微信小程序不像网页那样有账号密码注册页。小程序端调用wx.login()拿到一个临时 code后端再用 code 去微信接口换 openid。openid 是每个用户在同一个小程序下的唯一标识用它作为业务主键最稳。wx.login({ success: (res) { if (res.code) { wx.request({ url: ${baseUrl}/api/user/login, method: POST, data: { code: res.code }, success: (resp) { const { token } resp.data.data; wx.setStorageSync(token, token); } }); } } });后端拿到 code 后用code2Session接口换 openid。注意这里的 code 是一次性的且有效期只有几分钟不能在前端写死。如果用户授权手机号还需要注意微信规定获取真实手机号必须用企业主体的小程序个人主体只能用“手机号快速验证组件”或者让用户手动输入。做毕设时我通常先让用户手动绑定手机号逻辑更简单且不依赖于企业认证。4.2 座位预约页的状态展示座位预约是小程序的核心页面我用的是二维网格布局每一个格子代表一个座位。座位状态用颜色区分绿色空闲、红色已预约、灰色维修。这个布局直接用 CSS Grid 实现就行不需要复杂组件。这里要说一个容易忽略的小屏适配点小程序顶部导航栏在不同机型上高度不一样尤其是刘海屏和灵动岛风格机型。如果想要自定义导航栏不要写死高度要在页面加载时读取胶囊按钮的位置动态计算const menu wx.getMenuButtonBoundingClientRect(); const navHeight (menu.top - statusBarHeight) * 2 menu.height;这个细节别看不起眼评审现场如果用真机投屏导航栏顶到状态栏上会非常显眼直接降低整体印象分。用户选择座位的交互流程是先选日期和时段再选区域再点座位。提交时后端做两件事校验座位是否被占、插入预约记录。前端提交后不要立刻刷新座位图等后端返回成功再刷新避免用户重复点击造成脏数据。4.3 Vue 管理端的表格与弹窗设计管理端的核心是“让管理员在三分钟内完成所有操作”。我用的 Element Plus 表格组件。房间管理和座位管理共用一套表单弹窗区别只是字段多少不同。这个场景就很适合用 Vue 的插槽来扩展表格列比如操作列里放入编辑、删除按钮不需要每个页面复制粘贴。预约记录页是最容易被忽略的页面因为它看起来就是一张表没啥好做。但管理员一定会按日期、按用户、按状态筛选所以表格上方至少要放三个筛选条件日期范围、用户关键词、预约状态。筛选不一定要专门写后端接口可以用 Element Plus 表格自带的 filter 先顶上但在文档里写清楚“适合数据量较小时使用”显得你考虑过数据量扩展的问题。5. 从源码到运行环境搭建、联调和部署避坑5.1 拿到源码后第一件事不是点启动很多人拿到交付包就直接打开工程点运行然后被一堆报错劝退。正确顺序是先看 README 或文档确认使用的 Spring Boot、JDK、Node 版本。在 MySQL 中新建数据库导入交付包里的 .sql 文件确认表和数据都已经建立。修改后端application.yml把数据库地址、用户名、密码改成本机的。用 IDEA 以 Maven 项目方式打开后端等待依赖下载完再启动。前端 Vue 项目在命令行执行npm install装完依赖再执行npm run dev。小程序用微信开发者工具打开AppID 可以先选测试号后台请求地址改成自己电脑的局域网 IP。这里最容易踩的坑是后端启动时直接报Failed to configure a DataSource原因就是 application.yml 的数据库密码没改或者数据库服务没启动。检查顺序固定是MySQL 是否运行 - 密码是否正确 - 数据库名是否存在。5.2 前后端联调时最容易被忽略的三个问题第一个是跨域。Vue 管理端跑在 5173 端口后端跑在 8080 端口两者端口不同就会触发跨域。最省事的方案是在后端加一个 CORS 配置类允许指定来源跨域。如果是 Spring Boot可以写一个 WebMvcConfigurer 实现类重写addCorsMappings允许所有来源跨域开发阶段足够用。第二个是 LocalDateTime 序列化问题。后端返回2025-03-20T10:30:00这种格式前端如果直接展示会很难看。Spring Boot 里可以统一配置spring: jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: GMT8第三个是小程序真机调试的域名校验。开发者工具里可以勾选“不校验合法域名”但真机预览时必须在小程序后台配置请求域名而且必须是备案过的 HTTPS 域名。这一块不是代码问题是配置问题提前两周就要处理不能等到答辩前一天。5.3 抓包定位接口问题的思路小程序端接口联调时遇到“前端没报错但数据不对”我习惯先抓包看真实请求。用 Charles 或 Whistle 这类抓包工具配置好手机代理后可以看到小程序发出去了什么参数、后端返回了什么内容。很多同学一遇到问题就怀疑后端其实最常见的是请求头没带 token或者请求体格式不是 JSON。我开始做小程序开发时也习惯先在开发者工具看 Network 面板但这个面板在小程序里有时不能完整展示某些细节尤其是微信基础库升级后工具里的调试信息可能和真机表现不一致。这时候真机抓包就是最有效的排查手段。注意抓包只能在调试自己项目时使用不要拿它去搞不该碰的接口。5.4 部署上线的最小方案毕设演示通常不需要真正的云服务器但如果老师要求“能通过手机访问”可以用一台云服务器部署。我的做法是后端用 Maven 打 jar 包上传到服务器。服务器安装 JDK 和 MySQL导入数据库。使用nohup java -jar library-admin.jar后台运行。Vue 管理端执行npm run build把 dist 目录扔到 Nginx 的 html 目录下。Nginx 配置反向代理把/api路径请求转发到 8080 端口。小程序端如果要上线还需要域名、SSL 证书以及在小程序后台配置请求合法域名。这个流程说快也快但光等审核就可能花两天所以一定要留出提前量。6. 二次开发建议与高频问题排查6.1 想让系统“看起来更难”加哪些功能最划算如果基础功能全部跑通还想加亮点我建议优先加“超时自动释放”和“违约记录”。超时释放的逻辑我已经在前面提过核心就是定时任务加两条 UPDATE。违约记录则是在 t_user 表加一个 violation_count 字段用户超时一次就加 1超过三次限制当天预约。这两块代码量不大但能体现出“业务闭环”和“规则意识”。另外可以加一个“公告管理”管理员在 Vue 端发布通知小程序首页读取最新一条展示。这样做的好处是让前后端又多了一条业务链路而且界面效果明显。公告表就三四个字段标题、内容、发布时间、状态一天就能做完。6.2 自查清单这些报错代表什么现象大概率原因处理建议后端启动报 DataSource 错误application.yml 数据库配置不对检查密码、库名、MySQL 服务Spring Boot 启动后接口 404Controller 扫描路径没覆盖确认启动类在包的根目录小程序页面白屏JS 报错或 baseUrl 配错先看 Console再抓包调用接口一直 401请求头没带 token检查 request 拦截器Vue 管理端 npm install 报错Node 版本太高或太低用 Node 16 或 18 重装数据库中文乱码连接串和表字符集不一致统一使用 utf8mb4 并在连接串加编码参数6.3 一个过来人的小提醒最后说点实际体会拿到这种带源码的项目最忌讳的就是“能跑就算完”。你至少要自己动手改一处页面、加一个字段、写一条查询哪怕只是把公告标题换成你自己定义的名字过程中都要把 Vue 组件、Spring Boot 接口、数据库表这三个层级串起来理解一遍。我当时带这套项目时给使用者留的训练题是在房间表里加一个“楼层”字段并让小程序首页按楼层筛选区域。这个需求会牵动 SQL、后端 DTO、Vue 页面、小程序四个地方。做完这一步你对这套 Spring Boot Vue 微信小程序系统的理解就已经超过大多数只会启动运行的人了。