直接开门见山说结论这套SpringBoot 微信小程序 Vue 前后端分离图书馆预约与占座系统是我近期交付给客户的一个完整毕设/课设项目包含小程序端源码、Vue管理后台源码、SpringBoot后端源码、数据库脚本、部署文档和远程调试服务。如果你正在找图书馆座位预约方向的参考项目或者手头有一个类似的预约/抢座/资源管理需求想快速落地这篇内容可以帮你把整个架构、业务流程、核心代码和踩坑点全部捋清楚。哪怕你完全没碰过微信小程序和SpringBoot照着下面的思路也能把这套东西跑起来并且搞明白每一层为什么要这么设计。标题里挂的前后端分离不是营销话术是这套项目真实的组织方式。SpringBoot后端只提供RESTful API小程序端和Vue管理后台各走各的HTTP请求互不干扰。这样做的好处很直接小程序端和学生端是两拨使用场景管理后台是另一拨管理场景三端共用一个业务核心开发和调试互不阻塞。下面我按项目拆解、技术选型、数据库设计、核心功能实现、调试实战、部署交付六个部分完整讲一遍。1. 项目整体设计与业务拆解1.1 图书馆占座的真实痛点项目究竟在解决什么问题图书馆座位预约不是拍脑袋想出来的需求是每一个高校图书馆都真实存在的管理难题。传统的占座模式下学生早上排队进馆用书包、水杯、甚至一张纸条占座占完又不一定来真正想学习的同学转了一圈找不到空位占座的人下午才出现。这种资源错配在考试周尤其严重图书馆管理员清理占座物品既得罪人又治标不治本。这套系统把占座从线下行为搬到了线上用规则替代自觉。核心业务流程就一条线学生在微信小程序里查看图书馆和座位图选择一个时间段预约某个座位预约成功后需要在规定时间内到馆签到签到后座位锁定给你离开时在小程序上点离座座位释放给下一个人。如果预约超时未签到系统自动取消并释放座位连续多次违约的学生会被限制预约。这个流程看起来简单但落地下来的业务细节不少同一个座位同一时间段只能被一个人预约这是并发问题学生临时有事需要取消预约这是状态流转问题管理员要查看哪些座位长期空置、哪些时段最拥挤这是数据统计问题。整套系统把这些逻辑全部收进了SpringBoot后端小程序端只做展示和交互Vue管理后台给图书馆管理员用来看数据、管座位、处理违规名单。1.2 三端协同的前后端分离架构各自负责什么这个项目把前后端分离执行得很彻底一共三个工程互不依赖只通过HTTP接口通信。SpringBoot后端跑在服务器上本地调试就是localhost:8080负责所有业务逻辑和数据持久化比如创建预约、校验座位状态、签到离座、统计报表。它不关心前端长什么样只暴露JSON格式的RESTful接口。小程序端跑在微信开发者工具里主要做这几件事微信登录拿openid、展示图书馆列表、展示座位图、提交预约、扫码/按钮签到、个人中心查看预约记录。小程序的特点是轻所有状态都要靠后端接口拿自己不做持久化只在本地缓存用户token和基本资料。Vue管理后台跑在浏览器里给图书馆管理员用。登录后能看到所有图书馆、座位、预约记录的列表可以增删改座位、查看某一天的预约情况、手动取消违规预约。管理后台用的UI组件库是Element Plus表格、弹窗、表单这些后台常用组件开箱即用开发效率很高。三端通过统一的API约定对接例如查询可用座位的接口是GET请求返回的内容是一个JSON数组里面包含座位ID、区域、状态、座位编号这些基础字段。前端拿到之后直接渲染成格子不需要知道后端数据库长什么样。这种组织方式的优势在团队协作时特别明显前端和后端可以并行开发只要提前把接口文档定好互相用Mock数据联调就行。1.3 功能模块地图从学生选座到管理员管理的完整链路把整个项目的功能模块拆开看一共五大块每块都能独立拎出来讲。用户模块负责登录和身份标识小程序端用微信授权登录后端通过openid识别唯一用户管理员账号则是账号密码登录。图书馆模块维护图书馆的基础信息比如名称、位置、开放时间、座位总数管理员在Vue后台维护这些数据。座席模块是核心座位属于某个图书馆每个座位有区域、编号、状态可用/占用/禁用。座位图在前端渲染成一个网格绿色的可以选红色的已经被预约灰色的被管理员禁用。预约模块是业务重头戏包含发起预约、取消预约、签到、离座四个动作每个动作都会改变预约记录的状态并同步更新座位的状态。统计模块提供给管理员按天、按周、按图书馆维度统计预约次数、签到率、座位利用率这些数据在Vue后台用表格和简单的图表展示。模块之间通过数据库表的外键关联比如预约记录表里有user_id、seat_id、library_id三个外键字段查询的时候一条SQL就把关联信息全带出来了。我建议你拿到项目源码后先不要急着跑代码把数据库ER图和接口文档对照着看一遍基本上整个项目就理解透了一小半。2. 技术栈选型SpringBoot、Vue与微信小程序为什么这么组合2.1 SpringBoot做后端核心优势不只是开发快SpringBoot这几年几乎成了Java Web项目的默认起点最大的好处是约定大于配置一个空的SpringBoot项目创建出来就能直接写业务接口不需要像老Spring那样配一堆XML。这个预约系统选SpringBoot核心考虑有三个。第一个是开发速度。项目里用到了SpringBoot Web、MyBatis-Plus、MySQL Driver、Lombok这几个starter一个座位的增删改查写起来非常快。MyBatis-Plus把单表的CRUD封装好了我们只需要写业务逻辑不需要写基础的SQL需要复杂查询的时候再在mapper.xml里写自定义SQL比如统计某个时段座位利用率一句GROUP BY就能搞定。第二个是社区生态和排错成本低。SpringBoot的项目遇到问题搜索引擎一搜基本能找到参考这对学生项目或者独立开发者来说非常重要卡住半天没人问真的很要命。第三个是java技术栈本身的稳定性作为一个要提交源码和文档的交付项目SpringBoot在后端选型上不会让评审老师挑出毛病。这里有一个实际的版本坑必须提醒你现在新建SpringBoot项目时Spring Initializr默认给的是SpringBoot 3.x要求JDK 17。如果你电脑上装的是JDK 8直接创建项目导入开发工具会报错。我交付的这个项目用的是SpringBoot 2.7.x JDK 1.8这是经过验证的稳定组合MyBatis-Plus的兼容性也最好。如果你自己从头搭建记得把pom.xml里的parent版本改成2.7.xJDK配成1.8后面会少很多麻烦。2.2 Vue管理后台Vue 3 Element Plus Vite的组合拳管理后台选Vue 3因为Vue的生态环境已经非常成熟而且Element Plus这个组件库就是为管理后台而生的。对比Vue 2Vue 3的Composition API让代码组织更清晰setup语法糖写起来比Options API简洁不少。项目里后台一共也就十来个页面用Vue Router管理路由用Pinia做全局状态存储登录用户信息和token用Axios请求后端接口整个结构非常清晰。这里说说Vue项目的工程化问题。你拿到源码之后在命令行先执行npm install安装依赖然后npm run serve启动开发服务器默认端口是5173Vite的默认端口不是Vue CLI的8080。开发阶段用Vite的代理功能把接口请求转发到后端地址也就是在vite.config.js里配置server.proxy把/api前缀的请求转发到http://localhost:8080这样前端不需要关心后端地址写在哪联调体验特别好。有一个常见问题是npm install速度慢或者卡住尤其是国内网络环境下拉取node_modules经常失败。我一般直接改用淘宝镜像源在项目目录下创建.npmrc文件写入registryhttps://registry.npmmirror.com然后再npm install基本一两分钟就能装完。还有的同学用npm install报vulnerabilities一堆错只要不是高危high/critical问题其实不影响运行不用过度纠结。2.3 微信小程序端原生开发还是uni-app这个项目怎么选小程序端在这个项目里用的是微信原生开发没有引入uni-app。为什么这么选因为这个项目不需要跨平台只要微信小程序能跑就行原生小程序的性能和调试体验是最好的。原生小程序的WXML、WXSS、JS三件套结构清晰微信开发者工具的调试器直接能看到所有组件和网络请求对于毕设演示来说完全够用。小程序端的核心页面有五个首页图书馆列表、选座页座位图网格、预约结果页、个人中心页、登录页。其中选座页是最复杂的要根据后端返回的座位数据动态渲染格子并且区分可用、占用、禁用三种状态。界面用微信小程序的flex布局加scroll-view实现顶部是图书馆信息和时间选择器下面是一排一排的座位格子点击可用座位会弹出确认预约的弹窗。这里涉及到一个很实际的适配问题微信小程序顶部导航栏高度不是固定值。iPhone X及以上的全面屏手机有刘海导航栏高度会变高如果你的自定义内容要贴合导航栏不能写死一个数字。处理方式是用wx.getSystemInfoSync()获取状态栏高度然后用胶囊按钮的位置计算出导航栏的实际高度动态设置样式。热词里有微信小程序顶部导航栏高度说明这个问题确实困扰了不少人后面调试章节我会展开讲。3. 数据库设计与预约状态机3.1 五张核心表的字段设计与关系整个项目的数据库一共六张表分别是用户表、图书馆表、座位表、预约记录表、违约记录表和管理员表。我直接贴核心设计你对照源码里的sql文件看会非常清晰。用户表user的关键字段是id、openid、nickname、avatar、student_no、phone、status。openid是微信用户在小程序里的唯一标识后端登录接口通过wx.login拿到的code向微信服务器换openid然后存入用户表。student_no是学号这个字段不是必填的但建议让学生绑定因为图书馆管理员需要按学号核验身份。图书馆表library的字段是id、name、location、open_time、close_time、seat_count、description。图书馆和座位是一对多关系一个图书馆下有多个座位。座位表seat最关键字段有id、library_id、area、seat_no、status。status是varchar类型值是AVAILABLE表示可用OCCUPIED表示占用DISABLED表示管理员禁用。座位不支持时间段维度同一时间整张座位只能被一个人预约这样设计是为了降低并发复杂度如果你后续要升级成分时段占座就得在座位表下面再挂一个时段表复杂度会翻倍。预约记录表reservation是核心中的核心字段包括id、user_id、seat_id、library_id、reserve_date、start_time、end_time、status、create_time、checkin_time、leave_time。status字段存的是预约状态PENDING待签到、ACTIVE已签到在座、COMPLETED正常结束、CANCELLED用户取消、TIMEOUT超时自动释放、ABNORMAL违约。一个用户同一时间段只能有一条状态为PENDING或ACTIVE的预约记录这个限制要在后端写入时做校验数据库层面也要建唯一索引兜底。3.2 预约状态机设计从创建到释放的完整流转状态机是整个预约系统最容易做错的部分很多半路接手别人项目的同学最后都是死在状态不闭合上。我先画一个简单的流转逻辑你不用背理解之后自然就记住了。预约创建后状态是PENDING。学生在小程序里选了座位提交预约后端先查这个座位当前有没有未结束的预约记录没有的话创建预约座位状态改成OCCUPIED同时给用户倒计时倒计时结束前必须到馆签到。签到动作触发后预约状态变成ACTIVE座位保持占用。正常离座时用户点离座后端把状态改成COMPLETED座位状态释放成AVAILABLE。如果用户一直不点离座闭馆时间到了后台定时任务会把所有ACTIVE状态强制变成COMPLETED并释放座位。超时和取消是两个单独的旁路。PENDING状态下用户可以在小程序里主动取消取消后状态是CANCELLED座位直接释放不产生违约记录。但如果超过签到截止时间还没有签到定时任务会把PENDING改成TIMEOUT座位释放同时给用户记一次违规。连续三次违规用户会被拉进黑名单限制预约一周。每一个状态变更都是一次UPDATE操作同时座位的状态也要跟着变。我用SpringBoot的Transactional事务注解把这两个更新绑在同一个事务里要么都成功要么都回滚不会出现预约记录显示了但座位没有锁住这种脏数据。这个事务边界极其重要写的时候务必留意。3.3 索引设计查询慢的隐患提前解决预约记录表是查询频率最高的表学生要查我的预约管理员要按天查所有预约系统要查当前座位是否被占三条查询路径都离不开reservation表。如果表里数据量到了几万条没有索引的查询会明显变慢所以这里必须建索引。我实际建的是这三个索引user_id status的联合索引用来查某个用户的当前预约seat_id status reserve_date的联合索引用来查某个座位某一天有没有预约冲突reserve_date status的联合索引给管理后台的统计查询用。MySQL的联合索引遵循最左前缀原则所以查询条件里如果没带第一个字段这个索引就用不上。建索引之前直接用EXPLAIN看执行计划type字段是ALL说明全表扫描改成index就说明索引生效了。还有一个细节是软删除。seat表和library表都加了deleted字段删除操作实际上是UPDATE deleted1而不是物理DELETE。这样做的好处是历史预约记录里的座位信息还能完整关联上不会因为座位被删导致Join查不到数据。MyBatis-Plus的TableLogic注解自带这个逻辑删除功能配置一下就能用。4. 核心功能实现预约接口、小程序选座与Vue后台对接4.1 后端预约接口的并发处理避免同一座位被重复预约后端接口是整个系统的核心我逐个讲一遍实现思路。预约创建接口是最容易出并发问题的地方两个学生同时点了同一个座位如果后端不做控制两个请求都查到座位空闲然后各自创建预约就出现了一张座位被两个人占的bug。解决方式我用了两层保险。第一层是数据库层面的唯一约束在reservation表上建了一个unique索引字段是seat_id reserve_date status的条件索引MySQL不支持条件索引所以实际是把status分成两个字段或者用状态枚举业务判断替代我这里用一个更通用的方案。第二层是代码层面的同步锁用synchronized关键字锁住座位ID级别的锁对象。创建一个静态的ConcurrentHashMapkey是seatIdvalue是一个锁对象预约时根据seatId取锁保证同一个座位的预约请求串行执行。两个同学抢同一个座位第一个请求执行完提交事务第二个请求才能查座位状态这时候已经查不到了直接返回座位刚被预约。不同座位的请求不受影响性能上没有明显损耗。签到和离座接口的写法比较直接签到的核心逻辑是校验预约状态是不是PENDING是的话更新为ACTIVE记录签到时间。离座是校验状态是不是ACTIVE更新为COMPLETED释放座位。两个接口各自只有一条UPDATE事务处理边界清楚。下面贴一个简化版的核心代码片段展示预约创建接口的写法省略了参数校验和异常处理具体看源码PostMapping(/api/reservation) public Result createReservation(RequestBody ReservationCreateDTO dto) { // 获取当前登录用户 Long userId UserContext.getUserId(); // 按座位维度加锁防止并发重复预约 synchronized (SeatLockUtil.getLock(dto.getSeatId())) { // 查询该座位当前的占用状态 LambdaQueryWrapperSeat seatWrapper new LambdaQueryWrapper(); seatWrapper.eq(Seat::getId, dto.getSeatId()); Seat seat seatMapper.selectOne(seatWrapper); // 座位被禁用直接拒绝 if (DISABLED.equals(seat.getStatus())) { return Result.error(该座位已被禁用); } // 查询该座位是否有未结束的预约 LambdaQueryWrapperReservation resWrapper new LambdaQueryWrapper(); resWrapper.eq(Reservation::getSeatId, dto.getSeatId()) .in(Reservation::getStatus, PENDING, ACTIVE); Long count reservationMapper.selectCount(resWrapper); if (count 0) { return Result.error(该座位已被预约); } // 校验用户是否已有预约 LambdaQueryWrapperReservation userWrapper new LambdaQueryWrapper(); userWrapper.eq(Reservation::getUserId, userId) .in(Reservation::getStatus, PENDING, ACTIVE); if (reservationMapper.selectCount(userWrapper) 0) { return Result.error(您已有进行中的预约请先结束); } // 创建预约记录锁定座位 Reservation reservation new Reservation(); reservation.setUserId(userId); reservation.setSeatId(dto.getSeatId()); reservation.setLibraryId(dto.getLibraryId()); reservation.setReserveDate(LocalDate.now()); reservation.setStartTime(LocalTime.now()); reservation.setEndTime(dto.getEndTime()); reservation.setStatus(PENDING); reservation.setCreateTime(LocalDateTime.now()); reservationMapper.insert(reservation); // 座位状态改为占用 seat.setStatus(OCCUPIED); seatMapper.updateById(seat); return Result.success(reservation.getId()); } }写这段代码时有几个细节需要注意。第一是查询座位状态和创建预约必须在同一个事务里并且锁的范围要覆盖整个事务否则锁释放了事务还没提交另一个线程进来还是读到旧数据。第二是用户已有未结束预约的校验不能省不然学生可以一次性预约好几个座位占座系统就失去意义了。第三是接口的返回格式要统一我和前端约定的是Result对象里面有code、message、data三个字段code为200表示成功其它都是异常前端拿到code之后统一弹Toast不单独处理每个错误场景。4.2 小程序端核心页面选座网格和预约交互的实现思路小程序端我挑两个最关键的页面讲分别是首页和选座页。首页的逻辑很直接onLoad的时候请求GET /api/library/list拿到图书馆列表渲染成卡片列表点击某个卡片跳转到选座页URL上带上library_id和library_name参数。选座页是整个小程序端最复杂的页面。页面结构是一个scroll-view内部用flex-wrap排列座位格子。每个格子是一个view组件根据座位的status字段动态绑定不同的样式类AVAILABLE是绿色背景、OCCUPIED是红色背景、DISABLED是灰色背景。用户点击绿色格子时弹出确认框显示座位编号、预约时段点确认后调用POST /api/reservation创建预约创建成功后跳转到预约成功页失败的话弹Toast显示后端返回的message。这里的交互细节有一个值得说的地方选座页面进入时请求一次座位列表用户操作过程中后端数据可能已经变化比如别人刚预约了这个座位所以每次点击格子时不能只依赖页面上的状态而是要在提交预约的接口里由后端重新校验。小程序端显示绿色只代表进入页面时它是可用的真正的可用性判断以后端接口返回为准。这也是前后端分离项目必须养成的习惯前端展示的数据只是缓存永远以服务端校验为最终结果。预约记录页和个人中心页相对简单就是调GET /api/reservation/my并分页渲染列表列表项显示预约日期、座位号、状态文字和对应操作按钮取消/离座。这里的取消和离座操作都需要二次确认避免学生误触。4.3 Vue管理后台Vue Router路由和接口联调Vue管理后台的页面不多登录页、首页仪表盘、图书馆管理、座位管理、预约管理、用户管理、违约记录一共七个页面。登录页输入管理员账号密码后端返回token和昵称前端用Pinia存储登录状态路由守卫里判断没有token就跳回登录页。Vue后台和接口对接时我会先把Axios实例封装好baseURL指向开发环境代理地址/api请求拦截器统一加上token请求头响应拦截器统一处理code不为200的情况弹个ElMessage提示错误。这样页面里写接口调用时非常简洁比如座位管理页新增座位只需要调seatApi.add(formData)成功之后刷新列表失败了ElMessage自动弹出后端的报错信息。这里有一个Vue后台开发的常见问题路由配置。vue-router在Vue 3里的写法是createRoutermode用hashhistory在部署到非根路径时会白屏hash模式没有这个问题。路由懒加载可以用import函数动态引入组件也就是const SeatManage () import(/views/SeatManage.vue)这样打包的时候每个页面单独成一个chunk首屏加载更快。热词里有vue路由vue插槽这些关键词说明很多人在Vue Router和组件化上吃过亏我这里顺便提一句后台的页面布局最好拆成公共组件比如Sidebar、Navbar、AppMain用插槽或者嵌套路由来组合不要在每一个页面重复写菜单栏。管理后台的表格数据量如果大建议直接用Element Plus的el-table加el-pagination分页组件后端接口要支持分页参数pageNum和pageSize返回结构统一成{total: 100, list: []}。这个分页结构在后端用MyBatis-Plus的Page对象返回非常方便一个new Page(pageNum, pageSize)加orderByDesc(create_time)就搞定了。5. 调试实战常见问题与排查技巧5.1 微信小程序、SpringBoot、Vue三端的典型问题速查表这个项目是三端联调任何一个环节出问题都可能导致功能跑不通。我把自己调试过程中遇到的、以及帮客户排查过的问题整理成一个速查表你遇到同类问题直接对照着查。问题现象可能原因解决方法小程序request请求失败报url not valid开发者工具里没勾选不校验合法域名详情-本地设置-勾选不校验合法域名、TLS版本以及HTTPS证书后端接口Postman能通小程序不通请求的URL写错了或者baseUrl没配对检查app.js里的baseUrl本地调试改成局域网IP不要用localhostnpm install报错ERR! code ERESOLVE依赖版本冲突一般出现在vue项目用npm install --legacy-peer-deps或者把node_modules删掉重新装微信登录拿不到codeappid没填或者开发者工具登录的不是项目Owner的微信号在project.config.json里检查appid基础库版本不能太低预约接口报该座位已被预约但明明显示绿色前端座位状态是缓存别人先抢了这属于正常情况刷新页面重新获取列表即可打包后Vue后台白屏路由模式用的history部署路径不对改用hash模式或者nginx配try_filesSpringBoot启动报Port 8080 was already in use端口被占用换端口或者杀掉占用进程数据库连不上Access deniedapplication.yml里的账号密码不对检查MySQL用户名密码确认localhost的端口是3306这个表里最值得展开说的是第一个问题。微信小程序开发工具默认对request请求的域名有校验必须是HTTPS并且ICP备案过的域名。本地调试阶段域名还没上线必须在开发者工具的详情-本地设置里勾选不校验合法域名否则request一启动就报错。很多同学第一次接触小程序一上来就卡在这里其实压根不是代码问题是工具配置问题。5.2 联调排查三板斧日志、Postman、断点调试三端联调出问题时我一般按固定顺序排查先看后端日志再看接口返回最后看前端控制台。后端SpringBoot的日志里如果打了异常堆栈根据异常类型定位错误基本八九不离十没有异常但返回结果不对就用Postman单独发起一次HTTP请求排除前端因素Postman通了说明后端没问题问题在前端请求参数或者处理逻辑。在实际调试过程中我发现很多前端同学习惯在代码里console.log(数据, 数据)之后打开小程序开发工具的Console面板看打出来的内容。这个习惯没问题但记得正式提交前把console.log删掉至少把调试用的日志打上DEBUG标签不要提交一堆console出来交付时观感很差。小程序端的调试还有两个好用的小工具Network面板看网络请求的耗时和返回体Storage面板看本地缓存的数据。出现页面数据不对的情况先看Network里的接口返回对不对再排查渲染逻辑90%的问题都在这一步定位。Vue后台同理浏览器F12的Network和Vue Devtools工具可以让问题缩小到组件内部。5.3 微信小程序几个高频适配问题导航栏高度和手机号获取热词列表里出现了微信小程序顶部导航栏高度和微信小程序登录获取手机号这两个高频问题我实际项目中都踩过单独拿出来讲一下。顶部导航栏高度问题出现在自定义导航栏的场景。如果你用了navigationStyle: custom小程序页面顶部就是空的需要自己画一个导航栏。不同机型的系统状态栏高度不一样直接写死一个px值会在部分手机上错位。我的处理方式是在App.vue或页面onLoad里动态获取用wx.getSystemInfoSync().statusBarHeight拿到状态栏高度再用wx.getMenuButtonBoundingClientRect()拿到右上角胶囊按钮的坐标信息导航栏高度 胶囊按钮的top (胶囊高度 - 状态栏高度) / 2 状态栏高度。这段逻辑建议封装成一个公共方法所有页面共用一个导航栏组件不要每个页面自己写一遍。手机号获取的问题更敏感一些2023年之后微信小程序获取用户手机号需要企业主体的小程序个人开发者没有这个权限。如果是个人项目的学生建议不要在登录环节强制获取手机号用微信授权昵称头像学号输入就足够了。学号本身比手机号更适合图书馆场景管理员核对起来也更顺手。如果你确实需要手机号那是小程序后台的权限配置问题需要在mp.weixin.qq.com里开通获取手机号接口权限而且不能是个人主体。6. 部署上线与源码使用说明6.1 本地把整个项目跑起来的完整步骤拿到源码后第一次跑项目我建议严格按照下面的顺序操作能省很多冤枉时间。第一步安装基础环境和工具JDK 1.8、Maven 3.6、MySQL 5.7或8.0、Node.js 16、微信开发者工具最新版、IDEA或者你习惯的Java IDE、VSCode可选用于Vue和小程序。这些工具缺一不可版本尽量按我推荐的来特别是JDK版本SpringBoot 2.7在高版本JDK下运行也会有一堆兼容性警告。第二步初始化数据库。用Navicat或命令行执行根目录下的library_booking.sql文件这个脚本会创建数据库和所有表同时插入一些测试数据几个图书馆、几十个座位、一个管理员账号。脚本执行成功后在SpringBoot后端的application.yml里改数据库连接信息改成你自己的MySQL账号密码然后启动后端项目。启动成功的标志是控制台出现Started LibraryApplication和一排Tomcat started on port(s) 8080。第三步启动Vue后台。进入vue-admin目录npm install装依赖npm run serve启动浏览器访问localhost:5173。管理员账号密码就写在脚本里一般是admin / admin123登录后能看到所有管理功能。第四步启动小程序。微信开发者工具里导入miniprogram目录在app.js里把baseUrl改成http://localhost:8080如果是真机调试改成你电脑的局域网IP手机和电脑连同一个WiFi。执行编译在开发者工具里就能看到小程序界面了。这里要注意微信开发者工具导入项目时要选择小程序项目不是公众号网页AppID可以先用测试号。6.2 源码目录结构和文档怎么看拿到的东西通常是一个压缩包解压后里面有几块内容我帮你理一下怎么看最有效率。根目录下通常有backendSpringBoot后端、miniprogram微信小程序、vue-adminVue管理后台、doc文档四个目录。doc里一般包含三份东西数据库设计文档、接口文档、部署说明。数据库设计文档对应的是ER图和表结构说明接口文档列出每一个接口的请求方式、参数、返回示例部署说明是环境配置和运行步骤。我的经验是先读接口文档再对照后端controller代码最后再翻前端页面。接口文档是后端和前端之间的契约理解了契约就理解了两端的协作方式。读后端代码时按controller - service - mapper的顺序从上往下读不要先从mapper开始那样容易陷入细节出不来。核心的业务逻辑集中在service层比如预约状态机、座位锁、定时任务这些代码值得细看。如果调试遇到问题需要远程协助先把自己的环境信息准备好JDK版本、MySQL版本、Node版本、哪个模块启动失败、控制台报错截图。把这三件套提供出来远程调试基本一轮就能定位问题。6.3 从毕设项目到真实落地的几个扩展方向如果你拿这个项目不是为了交作业而是真的想部署到校内使用有几个地方必须加强。第一个是HTTPS和域名微信小程序正式上线要求所有请求域名必须HTTPS而且域名要ICP备案SSL证书可以从云服务商免费申请。第二个是对象存储如果后面要做头像上传、违纪证明上传之类的功能建议用云存储比如阿里云OSS而不是存本地磁盘不然服务器的存储空间撑不住。第三个是定时任务的高可用现在的定时任务写在SpringBoot里单机部署还行如果以后要集群部署定时任务就要考虑分布式锁不然多个节点会重复执行释放任务。功能扩展方面可以加一个时段预约模式把座位按时间段拆分成多个可预约单元比如上午8点到12点、下午1点到5点这样座位的利用率会成倍提升。对应的数据库表要加一个seat_time表预约记录表里加上period_id字段后端的状态校验逻辑也要同步调整。还可以加一个暂离功能允许学生临时离开30分钟锁不释放超过30分钟座位自动释放这个逻辑类似抢座续时需要增加一个暂离状态和定时任务扫描。最后的几个实操心得这套预约与占座系统前前后后我迭代了三四轮第一版的时候我连小程序自定义导航栏都没搞对测试机上一个页面顶部重叠一个页面错位后来才用动态获取状态栏高度的方法解决。后面帮客户调试的过程中遇到最多的还是环境问题而不是代码逻辑问题——版本不匹配、端口占用、依赖装不上真正业务逻辑出bug的次数反而不多。所以我的建议是拿到任何源码先花半天时间把环境跑通再开始改代码不然永远在环境都没起来的状态里空转。还有一个小建议预约状态机是整个项目最核心的部分也是评审老师最爱问的地方。你拿到源码之后我建议自己手动画一遍状态流转图把PENDING、ACTIVE、COMPLETED、CANCELLED、TIMEOUT之间的关系理清——什么状态下能取消、什么状态下能签到、超时之后座位归不归公共池这些边界条件都能说出来项目答辩基本稳了。后续如果想在这个项目上继续扩展优先考虑分时段预约和暂离续时两个方向这是最贴近真实图书馆需求的两个功能也是最能体现你深入理解业务的两个加分项。