简介：本资源是一套完整的基于微信小程序的图书馆座位再利用系统源码，面向高校开发者、毕业设计学生及小程序初学者，解决传统图书馆座位闲置率高、预约流程低效、状态更新滞后等实际管理痛点。压缩包共1156个文件，涵盖148个JavaScript逻辑文件、117个Vue组件、88个Java后端接口、64个WXSS样式与62个WXML结构文件，辅以319张PNG图标和162个SVG矢量资源，完整呈现前后端分离架构；整体大小为14.33MB，结构清晰，含bat一键部署脚本与.bak备份文件，便于学习调试与二次开发。已有186人下载学习，读者可直接运行调试、理解预约核心流程（如实时座位释放、微信通知触发、超时自动释放）、掌握小程序+Java后端+数据库协同开发模式，并参考后台数据分析模块优化运营策略。
1. 座位再利用的痛点与产品逻辑推导
1.1 占座乱象到底有多严重
做这个项目之前，我蹲了学校图书馆整整一周。高峰期大概在早上八点到晚上十点，真实情况是这样的：一楼大厅座位看起来全满，实际上真正坐着的人不到六成。有些座位早上被人用一本书、一个水杯占住，到了下午两三点都没人回来；走廊那边的单人自习位更夸张，有人甚至拿便利贴写"此座已占"就再也没出现过。图书馆管理员每天要花大量时间清理超时占座物品，清理完还有人投诉东西丢了，管理矛盾特别突出。
所以当有人说"做一个图书馆座位预约小程序"的时候，我第一反应是：预约只是手段，再利用才是核心。系统真正要解决的不是"帮大家排队占座"，而是把那些被占而不用、占而晚用的座位资源重新盘活，让真正想学习的人能坐下。这个定位直接决定了后面所有表结构和状态机的设计方向。
1.2 "再利用"三个字的业务规则推导
很多课设项目在需求阶段就翻车了，因为只想着"能做出来"就行，没有仔细推导业务规则。我当时把"再利用"拆成了三条硬规则：
第一，座位不能无限时占有。预约一个座位之后，必须在一定时间内签到，超时不签到就自动释放，这就是"预约-签到"机制。第二，学习过程中人走座空，要给其他人捡漏机会。比如临时离开超过一定时间，座位应该被标记为"暂离"，超过阈值就让其他用户可申请"座位转移"。第三，已经签到的座位，如果连续在一段时间内没有活跃状态，系统应该主动回收。
这三条规则听起来简单，但每一条都会牵涉到状态机、定时任务、消息推送。比如"暂离"状态，用户点一下"暂离"之后，座位会被锁定十五分钟还是三十分钟？这个阈值定多少才合理？我在实际项目里做了一个可配置的参数表，把签到时限、暂离时限、回收判断都放到配置表里，而不是写死在代码中，方便图书馆管理员按实际人流调整。
1.3 用户角色与核心流程定义
这个系统的用户角色我分成了三类：学生用户、管理员、系统超级管理员。学生用户拥有的操作是：查看座位图、预约座位、签到、暂离、释放、查看个人预约记录。管理员拥有的是：管理图书馆与座位数据、查看实时占用情况、手动释放违占座位、调整配置参数。超级管理员则管管理员的账号权限分配。
核心流程我用业务语言描述一下：用户进入小程序，选择图书馆和楼层，看到座位布局图，绿色代表可预约、红色代表已占用、灰色代表暂时不可用。点击绿色座位后进入预约确认页，选择使用时段（可选两小时、四小时、全天），提交后生成预约记录，状态为"待签到"。用户到馆后在座位附近点击签到，状态变为"使用中"。如果用户需要短时间离开，点"暂离"，状态变成"暂离中"，倒计时结束时若未回来，座位重新释放回可预约池。如果用户在"使用中"连续超过预先设定的休眠时间没操作，前端会提醒，后端会触发自动回收。
完整流程走一遍之后，数据库和接口的设计就有了明确依据。这也是为什么我不建议一上来就写代码，先把流程用文字或者手绘图理清楚，后面至少能省一半的修改时间。
2. 数据库表设计与座位状态机
2.1 基础表结构清单
这个项目的表结构并不复杂，但每张表都有需要留意的字段。我最终采用的是一套适合课设规模又能支撑真实运行的表设计，清单如下：
用户表（user）：openid、昵称、头像、学号、学院、手机号、信用分、创建时间。
图书馆表（library）：图书馆名称、楼层数、开放时间、座位总数、管理员id、状态。
座位表（seat）：所属图书馆id、楼层、排号、列号、座位类型（普通位/靠窗位/电源位/研讨间位）、当前状态、当前用户id、当前预约记录id、二维码标识。
预约记录表（reservation）：用户id、座位id、预约日期、开始时间、结束时间、状态（待签到、已签到、暂离、已完成、超时取消、主动取消、已回收）、签到时间、释放时间、违约标记。
配置参数表（config）：参数名、参数值、说明，例如signin_timeout_minutes、temporary_leave_minutes、idle_recycle_minutes。
管理员日志表（admin_log）：管理员id、操作类型、操作对象、操作时间、备注。
在MySQL中，预约记录表建议加上idx_user_id_date和idx_seat_id_date两个联合索引。原因很直接：用户查找"我今天的预约"按 user_id + date 查，座位查询"今天的占用情况"按 seat_id + date 查，这两个是最高频的查询路径。课设规模下数据量不大，不加索引也能跑，但加上索引可以让你在答辩护环节多一个可讲的技术亮点。
2.2 座位状态的设计哲学
座位表里最容易被忽视的就是"当前状态"字段。我见过不少同学用一堆冗余状态来标记座位，比如"已预约""已签到""暂离""已释放""违规"，结果每次状态流转都要写大量的if-else，一旦漏掉某个组合就出bug。
我的做法是把座位状态分为两层：座位物理状态和座位业务状态。物理状态就三种：可用、占用、停用（比如座位损坏或被管理员锁定）。业务状态则通过"当前用户id"+"当前预约记录id"这两个字段来体现。也就是说，座位状态压根不用存"暂离中"这种标记，只要查到当前预约记录的状态是"暂离"，就能推导出座位当前处于暂离状态。
这个设计的好处是：状态机只在预约记录表里维护，座位表永远只关心"这个位置现在有没有人"。查询座位图的时候，一条SQL join 预约记录表就能同时拿到座位颜色和当前使用者信息。后面做定时任务自动回收时，也只需要扫描预约记录表，不需要反查座位表，逻辑简单很多。
2.3 预约记录的字段细节与时间戳处理
预约记录的几个字段要特别说清楚。
第一个是预约日期和具体时段。我建议预约日期用yyyy-MM-dd的 DATE 类型，开始时间和结束时间用 DATETIME 类型。为什么不用时间戳 int？因为MySQL里DATE直接支持日期函数操作，做"查询今天所有预约"的时候条件写DATE(reservation_date) = CURDATE()就行，阅读性和维护性都好很多。如果用时间戳，还要做时区和零点换算，课设阶段容易自己给自己挖坑。
第二个是签到时间和释放时间。这两个字段允许为空，但这恰恰是所有状态流转判断的关键。判断一条预约是否超时未签到，不能直接看当前时间是否晚于"开始时间"，而是要看"签到时间是否为NULL"。因为预约可能选择的是"上午10点开始"，但用户可能提前五分钟在系统里签到了，如果只用现在时间对比开始时间，判断就乱了。我代码里的判空逻辑是这样的：
if (reservation.getSignTime() == null) { // 尚未签到，判断当前时间是否超过签到截止时间 if (now > reservation.getStartTime() + signinTimeout) { // 触发超时取消 } } else { // 已签到，继续判断是否暂离超时等 }这个细节看起来小，但非常容易错。很多第一次写这种系统的同学把"超时未签到"和"开始时间过了没签到"混为一谈，结果用户提前进了馆、提前点了签到，反而被判定为异常记录。
2.4 状态变更时的并发考虑
座位预约最怕的就是两个人同时抢同一个座位。我在真实开发的时候，一开始用的是"先查询座位状态，再插入预约记录"的逻辑，结果用两个手机同时抢同一个座位，两个人居然都成功预约了。原因很简单：查询和插入之间不是原子操作。
解决方案有两种。一种是在座位表上加version乐观锁字段，更新时UPDATE seat SET version = version + 1 WHERE seat_id = ? AND version = ?，如果影响行数为0说明被别人抢了。另一种更直接：在预约记录表加唯一索引，比如UNIQUE KEY uk_seat_date_period (seat_id, reservation_date, period_type, reservation_status)，但这里有个问题，因为预约记录状态会从"待签到"变成"已完成"，索引会把不同的状态当成不同记录，破坏唯一约束的意图。
我最终采用的是先在座位表上的"状态锁"思路：插入预约记录前，先执行UPDATE seat SET current_status = '占用' WHERE seat_id = ? AND current_status = '可用'，只有当影响行数为1时才允许插入预约记录，否则提示"座位已被预约"。这样既不用引入复杂的事务锁，又能保证在并发情况下不会出现超卖。配合MySQL InnoDB的行锁和一条SELECT ... FOR UPDATE，在高并发下也能稳定运行。课设答辩时能讲清楚这个思路，已经在"并发处理"层面超出大多数项目了。
3. 小程序端核心页面与交互拆解
3.1 图书馆列表与座位地图（canvas/地图组件选型）
小程序端的入口页面是图书馆列表。这里每个卡片显示图书馆名称、当前可用座位数、总座位数、开放状态。数据来源是后端提供的聚合接口，比如"查询全校各馆当前占用概览"。一个容易踩的坑是：不要在卡片上直接显示座位明细列表，数据量太大，接口响应慢。聚合统计在SQL里用GROUP BY library_id一次性查出，响应控制在100ms以内。
座位地图是整个前端最核心也最纠结的部分。微信开发者工具里有一个 canvas 组件，支持绘制座位格子。我最初用canvas自己画座位图，确实能做到比较灵活的自定义效果，比如靠窗区域加个蓝色边框、电源座位画一个小闪电图标。但 canvas 在真机上的渲染性能有些不稳定，特别是座位数超过100个时，快速滚动会有卡顿。后来我改用view标签加 CSS Grid 布局来实现座位图：每个座位是一个固定宽高的小方块，通过背景色表达状态，点击事件直接绑定在方块上。实测下来，渲染性能和交互流畅度都比 canvas 方案好，而且自定义右键菜单、座位类型图例也更容易实现。
如果你更习惯用wx.chooseLocation或者地图选座的方式也可以，但我个人觉得图书馆这种室内场景用地图组件反而麻烦——室内没法直接用经纬度定位，还得自己去维护坐标映射关系，没必要。热搜词里有人问"微信小程序可以使用天地图画地图组件吗"，我的建议是：室外场景可以，室内座位图别用地图组件，用 Grid 布局最省心。
3.2 预约选座流程中的表单细节（单选框）
预约确认页涉及的信息不多：座位号、预约时段、签到截止时间。这页最容易出问题的是"时段选择"。我用的是微信小程序原生的radio-group，把"两小时""四小时""全天"做成三个单选项。这里有一个真实的坑：radio-group的bindchange事件在真机上有时不会触发，尤其是当radio组件的disabled属性被动态设置时。我第一次开发时，桌面开发者工具里一切正常，一到真机就发现选择时段没反应。
排查后发现原因在于：给radio-group绑定 change 事件后，我在回调里又去修改了同一批 radio 的某个属性，导致事件循环异常。解决方案是改用view加自定义选中态来实现单选框——每个时段用view包裹，点击时切换选中样式，同时把选中值存储到data里。这套方案在任何端上都不会有事件问题，而且样式控制更灵活，想做成胶囊样式、卡片样式都行。
预约确认后，前端要展示的还有"签到倒计时"。这块设计我放在后面单独讲，因为它涉及定时器管理，是前端最容易出内存和状态问题的模块。
3.3 签到倒计时与定时器的正确用法
签到倒计时的需求是这样：用户预约成功后，页面显示"请在某时某分前完成签到"，并且有一个实时倒计时。开发者工具里用setInterval每秒更新一次剩余时间，看起来很简单，但有两个隐患。
第一，setInterval回调里如果每秒都调用this.setData，在低端安卓机上会造成页面频繁重渲染，耗电且容易卡顿。正确做法是：每秒只更新秒数，分钟和小时的变化在秒数到达0时才更新；或者干脆用一分钟为粒度，倒计时只显示分钟数，每分钟刷新一次。对于课设来说，我推荐第一种——一个interval每秒执行，但setData的数据量很小，页面只绑定一个文本节点，实测性能可以接受。
第二，也是最容易忽视的：倒计时在后台会被系统挂起。用户预约成功后，把小程序切到后台回消息，再切回来，会发现倒计时突然跳了一大截。因为微信小程序在后台时，JavaScript 的执行会被系统暂停，setInterval也停了；回到前台后，定时器恢复，但时间已经过了好几分钟，界面上显示的剩余时间可能是负的。
解决方式是用"时间戳差值"而不是"递减计数"。每次启动倒计时时记录一个目标时间戳expireTimestamp，倒计时函数每次执行时计算expireTimestamp - Date.now()的差值，而不是简单地剩余秒数 - 1。这样即使定时器在后台暂停了一个小时，回前台后首次执行就能计算出正确的剩余时间，不会出现负数或者跳秒。这个经验是我在真机测试时发现的，如果你写类似系统，建议一开始就按时间戳差值来设计。
3.4 请求层封装与登录态管理
小程序的网络请求封装，我建议统一放在utils/request.js里，每个接口调用不要直接wx.request。封装时至少要做到三件事：统一baseURL前缀、统一携带token或session_key、统一处理错误码和401跳转登录。
登录态这块，微信小程序有wx.login获取code，然后把code发到后端换openid，后端返回一个自定义session_token作为登录凭证。我们需要在小程序端把openid或者session_token存储在wx.setStorageSync里，每次请求时在 header 里带上。一个小技巧是：不要在每次业务请求里手动拿token，在封装函数里自动拼上，这样后面加接口时不需要重复处理。
还要注意wx.request的默认请求超时时间是60秒，但在信号不稳定的图书馆角落，建议显式设置timeout: 10000左右，配合加载提示，用户体验会好很多。接口失败时，我会在拦截器里统一wx.showToast显示后端返回的错误信息，避免页面里到处重复写showToast。
3.5 顶部导航栏高度的适配问题
热搜词里有个问题很典型："微信小程序顶部导航栏高度"。自定义导航栏的时候，不同机型的状态栏高度不一样，直接写死一个数值就会出现适配问题。正确做法是：用wx.getWindowInfo()（老版本是wx.getSystemInfoSync()）拿到statusBarHeight，然后导航栏总高度 = statusBarHeight + 44px（这个44px是胶囊按钮的典型高度参考值，也可以根据实际计算）。
我经常用的是这种写法：
const windowInfo = wx.getWindowInfo(); const statusBarHeight = windowInfo.statusBarHeight; const navigationBarHeight = 44; const totalHeight = statusBarHeight + navigationBarHeight;然后把totalHeight动态设置给自定义导航栏的style。注意，如果用了navigationStyle: custom，页面顶部会延伸到状态栏区域，所有内容都要往下留出导航栏高度，否则内容会被刘海屏遮挡。这个坑在真机预览时特别明显，开发者工具模拟器反而不太容易暴露。
4. 后端接口设计与预约状态流转规则
4.1 接口清单
后端接口按模块划分，清单如下：
- 用户模块：
POST /api/user/login（code换token）、GET /api/user/info、PUT /api/user/credit - 图书馆模块：
GET /api/library/list（全部馆概览）、GET /api/library/{id}（详情与楼层列表） - 座位模块：
GET /api/seat/map?libraryId=xx&floor=xx（座位图数据）、GET /api/seat/detail?seatId=xx - 预约模块：
POST /api/reservation/create、POST /api/reservation/signIn、POST /api/reservation/temporaryLeave、POST /api/reservation/cancel、POST /api/reservation/release - 查询模块：
GET /api/reservation/my?date=xx（我的预约记录）、GET /api/seat/occupied?libraryId=xx - 管理模块：
POST /api/admin/seat/forceRelease（管理员强制释放）、PUT /api/admin/config（修改配置参数）、GET /api/admin/overview（统计面板）
这些接口比较常规，但预约状态的流转是其中最容易写错的。我重点说几个核心接口的实现细节。
4.2 核心接口：预约与签到的时序细节
POST /api/reservation/create请求体大概是这样的：座位id、预约日期、开始时间、结束时间。后端处理逻辑：
- 校验用户是否已有"待签到"或"使用中"的预约记录，有则拒绝，避免一个用户同时占用多个座位。
- 校验座位在目标时间段是否已被占用，用座位表当前状态字段判断，而不是查预约记录。
- 执行
UPDATE seat SET current_status='占用', current_user_id=?, current_reservation_id=? WHERE seat_id=? AND current_status='可用'。 - 影响行数为1则插入预约记录，状态为"待签到"，否则返回"座位已被抢占"。
第一步的用户校验很容易漏掉。如果不校验，用户可以在同一时段预约两个座位，这违背了"再利用"的基本原则。其实校验逻辑很简单，在预约记录表按 user_id 和时间段查一下有没有未完成记录即可。
签到的接口POST /api/reservation/signIn更简单但时序很重要。用户点签到按钮时，前端会发送预约记录id。后端要做两件事：检查当前时间是否在签到截止时间之前（超过则返回"已超时，座位已释放"），然后更新预约状态为"已签到"，同时更新sign_time字段。这两步要在同一个事务里。如果先更新状态后检查时间，会出现逻辑漏洞：超时用户点击签到，状态已经变了才报错，前端可能会出现短暂的"签到成功"又变回"已释放"的错乱UI。
4.3 超时释放是怎么实现的（定时任务）
自动释放违占座位的任务，我用 Spring Boot 的@Scheduled注解实现，每隔一分钟扫描一次预约记录表，找出两类记录处理：
第一类是"待签到"且当前时间已超过start_time + signin_timeout_minutes的记录，处理动作是把预约状态改为"超时取消"，同时把座位状态置回"可用"，清空current_user_id和current_reservation_id。
第二类是"暂离中"且当前时间已超过leave_start_time + temporary_leave_minutes的记录，处理动作是把预约状态改为"已回收"，座位置回"可用"，同时对用户信用分做一次扣减。
关于任务的执行频率，设置为一分钟一次比较合适。太频繁比如每十秒扫描，会消耗数据库资源；太慢比如每十分钟扫描，用户体验又会有明显延迟（明明人走了十分钟了座位还显示占用）。一分钟算是一个平衡值。
还有一个问题是分布式环境定时任务的重复执行。如果系统部署了多个实例，@Scheduled会同时触发，导致重复处理。课设阶段一般单机部署，不用考虑这个问题，但如果想更进一步，可以用 Redis 分布式锁或者配置一个ShedLock组件来保证只有一个实例执行。面试时提到这一点，是一个加分的扩展点。
4.4 防重复预约与并发控制
并发场景我前面提过，这里展开讲一下具体的实现路径。创建一个预约接口，最核心的防超卖代码其实只需要三条SQL：
-- 原子占座：只要返回影响行数为1，就可以继续创建预约记录 UPDATE seat SET current_user_id = #{userId}, current_reservation_id = #{reservationId} WHERE seat_id = #{seatId} AND current_status = 'AVAILABLE';这条SQL利用了 MySQL 的乐观锁思路，WHERE current_status = 'AVAILABLE'保证只有座位当前是空闲状态时才会更新成功。两个用户同时提交，InnoDB 的行锁会让第二条UPDATE等待，等第一条提交后，第二条发现current_status已经变成OCCUPIED，影响行数为0，直接返回失败。
这在并发请求测试中实测有效：我模拟50个用户同时抢同一个座位，最终只有1个成功创建预约，其余49个都返回"手慢了，座位被抢"。
另一个容易被忽视的问题是"预约已存在"的校验。即使做了座位状态原子更新，用户如果用一个POST请求快速重复点击，还是可能创建出两条预约记录（座位状态第一次更新成功，第二次因为座位已经占用失败，但如果接口没有严格按照状态判断，可能会出现边界问题）。稳妥做法是在预约记录表上做唯一索引约束：(user_id, reservation_date, type)中type取NORMAL类型，保证同一个用户同一天只有一条普通预约记录。再加一个(seat_id, reservation_date, periodType)的唯一索引，保证同一个座位同一天同一个时段只有一条预约。双重约束之后，即使代码逻辑有漏洞，数据库也会兜底。
5. 从开发到真机调试的踩坑记录
5.1 开发者工具正常、真机白屏的问题
热搜词里有句话让我印象很深："uniapp做微信小程序在手机上预览没问题，但是在微信开发者上是白片"。我虽然没有直接用 uniapp，但是用原生小程序开发时也遇到过类似的场景：开发者工具里一切正常，一扫码上真机，页面白屏。
这个问题的排查链路一般是：先看 console 有没有报错。真机上有些错误不会像开发者工具那样弹出来，需要打开调试模式（右上角胶囊按钮里点"开发调试"），让手机上显示vConsole。我那次遇到的白屏原因是：页面里用了一个自定义组件，组件引用的图片资源路径用的是相对路径../../images/seat.png，开发者工具能自动转成可访问的URL，但真机上图片域名没有在小程序后台配置为合法下载域名，导致图片加载失败，页面渲染异常。
解决方式是：所有涉及图片、音频等静态资源的URL，要么显式使用https://的线上地址并且在小程序管理后台配置 downloadFile 合法域名，要么就用base64内嵌小图标。课设阶段我强烈建议图标尽量用base64或者少量https资源，避免本地路径引发的真机兼容问题。
还有一次白屏是因为我在onLoad里做了一个很重的wx.request，后端接口超时了 60 秒，前端一直停留在 loading 状态，看起来像白屏。后来给请求加了timeout: 8000和错误提示，体验就好多了。
5.2 日志与调试：像抓包一样看请求
热搜词里"微信小程序抓包""bp怎么抓微信小程序的包"这类问题特别多。说实话，日常开发阶段我一般不用外部代理工具抓包，微信开发者工具自带的 Network 面板已经能看所有请求的请求头、响应体、状态码，足够定位绝大多数问题。需要看真机上的请求，也只需要在真机上打开调试模式，vConsole 的 Network 面板就能看到。
只有遇到"开发者工具正常、真机请求失败"这种特殊问题，我才会考虑用代理工具抓包。重点看三点：请求的域名是否配置了合法域名、请求的 header 里是否带了正确的 content-type、请求body是否因为 JSON 序列化而多了一层转义。大多数"真机请求失败"都逃不过这三个原因，不需要真的上抓包工具。
5.3 倒计时在真机后台被挂起的问题
前端倒计时的问题前面讲了时间戳差值方案，这里再补充一个跨端场景。如果同一个用户在小程序里开了多个页面，比如一边看座位图一边开着预约详情页，两个页面都有倒计时定时器，后台挂起的问题会变得更加隐蔽。最好的做法是：把倒计时的状态提升到app.globalData或者用全局事件总线来管理，任何页面恢复前台时重新从后端获取最新的预约状态，而不是依赖本地定时器继续跑。
后端接口GET /api/reservation/my?date=today每次页面onShow时调用一次，既刷新了倒计时，也修正了可能被其他端（比如管理员强制释放）更新的座位状态。这种"以服务器时间为准"的设计，虽然牺牲了一点点实时性，但换来了逻辑上的绝对正确，值得在项目里坚持。
5.4 信号弱场景下的请求失败处理
图书馆通常是人流密集区，WiFi 信号参差不齐，移动网络也会因墙体厚度出现断崖式下降。用户点"签到"时如果网络请求失败，体验会很差。我的处理是：签到请求失败时不直接提示"签到失败"，而是弹出一个"重试/稍后再说"的操作面板，同时在后端做幂等处理——同一预约记录重复接收签到请求时，返回当前状态而不是再次报错。这样即使用户请求超时重试，也不会因为重复签到而产生脏数据。
这个幂等处理在后端实现非常简单：签到接口先查预约记录状态，如果已经是SIGNED_IN，直接返回成功且不更新任何字段。前端收到成功回调后刷新页面即可。
6. 源码目录结构与二次开发建议
6.1 推荐目录结构
如果你拿到源码准备在此基础上改，或者准备自己从零搭，我推荐的小程序端目录结构长这样：
miniprogram/ ├── app.js ├── app.json ├── app.wxss ├── pages/ │ ├── index/ // 图书馆列表 │ ├── seatmap/ // 座位图 │ ├── reserve/ // 预约确认 │ ├── my/ // 我的预约 │ └── admin/ // 管理端 ├── components/ │ ├── seat-grid/ // 座位格子组件 │ └── countdown-bar/ // 倒计时条组件 ├── utils/ │ ├── request.js // 请求封装 │ ├── auth.js // 登录态管理 │ └── format.js // 时间格式化工具 └── images/后端推荐结构（以 Spring Boot 为例）：
src/main/java/com/example/library/ ├── controller/ ├── service/ ├── mapper/ ├── entity/ ├── config/ └── common/这个结构的好处是页面和组件分离、独立工具函数收敛到 utils，管理端页面单独放。课设阶段项目规模不大，不推荐过度分层，比如 controller 里处理业务逻辑也完全可以接受，但如果你打算后续扩展成完整商用系统，service 层还是必要的。
6.2 如何扩展成一个真正能落地的系统
如果这是你的课设或者毕设，答辩时被问到"你的系统还能怎么优化"，可以从这几个方向展开：
一是接人脸识别或校园一卡通接口。目前签到是纯点击操作，存在"代签"漏洞。对接校园卡或者人脸识别后，可以做到人到场才能签到，这是图书馆座位"再利用"最扎实的一环。
二是信用的分维度体系。目前信用分只简单扣减，可以进一步细化：迟到一次扣5分，超时未签到一次扣10分，连续一周无违约加5分，积分低于60分限制预约。这些规则和数据字段在现有表结构上扩展成本很低。
三是可视化统计面板。管理端增加座位利用率曲线（按小时统计每个座位的占用率）、热门馆时段分析、违约高发时段热力图。有了这些数据，图书馆管理员调整开放时间、预约时限配置就有依据了。这部分需要额外建一张"座位使用记录表"或者定时把预约快照写入统计表，属于比较大的功能，但能显著提升项目的完整度和答辩说服力。
6.3 几个值得写进代码注释里的细节
最后分享几个代码层面的小细节。
第一，所有时间字段统一用yyyy-MM-dd HH:mm:ss格式，不要混用时间戳和字符串。前后端交互时，日期格式统一由后端格式化好返回，前端不参与时间运算（除了倒计时差值）。
第二，openid是敏感信息，前端请求登录时后端拿到code后换取的openid只存在服务端，前端拿到的应该是一个自定义token，不要把openid明文返回给前端。虽然课设项目不一定被攻击，但这个习惯值得养成。
第三，小程序端的配置项集中放在app.js的globalData里，比如apiBaseUrl、请求超时时间、页面版本号。发布上线前改域名只需要改一处，而不是全局搜索替换。
第四，小程序端wx.setStorageSync存储的数据不要放太多，比如座位图数据每次加载都存一份，很容易把本地缓存撑爆，而且容易拿到过期数据。我的策略是：座位图数据不缓存，每次进入页面实时请求；图书馆列表这种变化不频繁的数据，缓存5分钟，提升首屏速度。
写在最后：这个项目带给我的实际体会
做这个座位再利用系统的过程中，我最大的感受是：这类"看起来很简单"的小程序，真正做得稳一点也不容易。它的难点不在某个高深的技术点，而在于业务规则要清楚、状态流转要严谨、真机上的坑要提前想好。把座位从"预约"到"再利用"的每一条路径都走通，并且处理掉并发、超时、后台挂起这些边界情况，你学到的已经不只是一个课设，而是一套完整的项目思维。
如果你准备拿这个方案做毕业设计或者自己练手，我建议从数据库表设计开始，先把状态机画出来，再动手写代码。刚开始可能觉得慢，但是后面面对"怎么改都改不完的bug"时，你会发现前面省下的时间全都值了。
最后再分享一个小技巧：给小程序加一个"常见问题"页面，里面写清楚"为什么要签到""暂离时间多久""超时有什么后果"。这样既能减少管理员被反复问同一个问题的概率，又能在答辩时展示你的产品思维——这在小程序开发者里面，真的不多见。
本文还有配套的精品资源，点击获取
