1. 项目拆解与整体设计思路1.1 这个系统到底在解决什么问题实验室排课系统这个题目在课程设计、毕业设计和实际实验室信息化改造里都属于高频需求。很多高校的实验课排课还停留在管理员手工排、微信群里喊、Excel表格来回传的阶段这么做最容易出两类问题一是时间冲突没人提前发现两门课撞了同一个实验室二是学生想预约实验时间得专门跑一趟实验室看空余安排效率很低。微信小程序天然适合解决这个场景。学生用手机就能查课表、提交预约申请教师能随时查看自己的实验课排布实验室管理员通过后台集中审批、排布和调整课表。整套系统的价值在于把“排课-预约-审批-通知-查询”这条链路全部线上化同时把实验室资源的使用情况透明化。如果你是在做课程设计或者毕设这个题目还有一个额外的好处功能边界清晰需求容易讲清楚技术栈覆盖了小程序前端、后端接口、数据库设计和排课算法不管在答辩还是展示环节都有的讲。对于有真实场景的实验室管理来说这套系统减负效果非常明显我见过不少实验室管理员拿到类似系统后最直观的反馈就是“终于不用天天对着Excel盯冲突了”。1.2 技术方案怎么选原生小程序还是云开发先说结论我实际做下来最推荐的是“原生微信小程序 Spring Boot后端 MySQL”这套组合。它最稳也最容易被导师和答辩老师认可因为前后端分离的结构清晰每个层次都能单独讲解。选微信原生小程序而不是uni-app或云开发核心原因有三点原生小程序文档齐全、社区案例多遇到问题基本都有现成答案。对于这类以业务管理为主的项目没必要为了跨端增加一层框架复杂度。云开发虽然能省掉后端服务器但排课系统的核心难点在冲突检测和排课逻辑上如果把这部分放在云函数里写调试起来反而麻烦不如本地后端直观。用Spring Boot在简历和答辩时更有说服力JPA或MyBatis连MySQL、写Service层做业务判断这是最主流且面试官熟悉的套路。之前有个学生找我帮他看方案一开始用云开发做了两个月最后卡在“同一时段多个请求同时约同一个实验室”的并发问题上云函数里加锁和事务处理对他来说太抽象了后来换成本地后端用数据库唯一索引配合业务层判断一下就解决了。排课这类强事务场景传统后端心里的底气比云开发足得多。如果你后端不熟悉JavaNode.js的Express或Koa也能胜任但我的建议是别在这上面纠结选你最有把握的那个把精力省给排课逻辑和页面交互。1.3 用户角色与完整业务流程这套系统我拆成了三类用户对应三种完全不同的操作视角学生端查看实验室空闲情况、按时间段提交预约申请、查看自己的预约记录和审批结果。教师端查看自己名下的实验课程安排、发起课程排课申请、管理选课学生名单部分需求里可选。管理员端维护实验室基础信息、对排课和预约做审批、处理冲突提示、发布调课通知。业务流程上最核心的一条链路是“学生或教师提交预约/排课申请 → 系统自动检测该时段是否空闲 → 冲突则拒绝并提示 → 不冲突则进入待审批状态 → 管理员确认后正式生效 → 课表更新并推送给相关用户”。这条链路就是整套系统的业务主线代码里的接口、数据库表、页面基本都围绕它转。需要特别说明一点实验室排课和普通教室排课有个很大的区别实验室往往有“设备依赖关系”。比如“单片机实验”只能在“嵌入式实验室”上而“化学实验”只能在“通风实验室”上。所以设计数据库时实验室表里除了名称和容量一定要加上“可承担实验类型”这个字段排课申请时也要带上课类型否则就会出现课程排到了错误实验室的荒唐情况。2. 核心功能模块与数据库设计2.1 功能清单与页面结构拆解功能模块我是按“用户端小程序 管理端后台”两块来组织的。小程序端页面尽量做到简单直接核心就四个Tab首页展示本周课表和空闲实验室、实验室列表查看各实验室详情和可用时段、预约页面选择时间、提交申请、我的查看预约记录和个人信息。管理端我建议做成网页用Vue Element Admin或者单独的管理页面都行。管理员在这个端主要做三件事维护实验室基础信息名称、位置、容量、设备类型、开放时段、对预约申请做审批通过或驳回、手动调整课表并处理冲突提示。功能优先级上如果工期紧下面的功能必须保证其他都可以往后放课表展示与查询核心中的核心预约/排课申请提交核心冲突自动检测核心审批流程核心基础数据维护支撑消息通知加分项数据统计加分项我见过不少同学一上来就去做统计图表结果基础排课逻辑反而出了大问题。记住排课系统的灵魂是“把时间、教室、课程对上并且不冲突”其他都是花架子。2.2 数据库表设计这几张表缺一不可数据库设计是整个系统最重要的地基。我直接给你看我在实际项目中维护过的表结构照着这个改就行。用户表的核心字段除了常规的openid、昵称、头像外一定要有role字段用int区分学生、教师、管理员。这里有个坑不要在用户表里直接写“学生”或“教师”这种字符串一旦角色名称要改你得改数据库所有记录用数字类型配合代码里的枚举常量扩展性完全不一样。实验室表必须包含lab_name、location、capacity、equipment_type、open_time、close_time。我当时做的时候还加了个lab_type字段专门用来存“可承担的实验类型”比如嵌入式、化学、物理、生物后面做排课匹配时全靠它。排课表是整个系统的核心表字段设计如下字段名类型说明idbigint主键course_namevarchar课程名称teacher_idbigint授课教师IDlab_idbigint实验室IDweek_startint开始周次week_endint结束周次week_typetinyint单周/双周/每周day_of_weekint星期几section_startint开始节次section_endint结束节次statustinyint待审核/已通过/已驳回/已取消applicant_typetinyint学生申请/教师申请我特别要提醒week_type这个字段这是很多人容易漏掉的。很多学校的实验室排课是按单周/双周轮换的比如“单周周四下午做数字电路实验”。如果不支持单双周模式遇到这种需求就傻眼了。数据库里用一个tinyint存1单周、2双周、0每周代码里判断的时候做一次取模运算就行。预约表其实和排课表结构类似只是表意不同排课表是管理员确认过的确定性安排预约表是用户发起、待审批的请求。我建议这两张表分开而不是用状态字段硬塞在同一张表里因为后续统计和查询时逻辑更清晰索引也好建。另外强烈建议加一张“课程-实验室关联表”用来限制某门课程只能预约特定类型实验室。别看它不显眼实际用起来特别好使能帮管理员减少一大半无效审核工作。2.3 接口设计的关键约定前后端联调时接口约定比接口数量更重要。我这边统一用的是JSON格式所有接口返回结构都长这样code业务状态码、message提示消息、data实际数据。code为0表示成功其他的分别对应参数错误、无权限、冲突、系统异常等。在小程序端所有请求我封装在request.js里自动带上token并统一处理错误提示。这里有个很实用的细节小程序wx.request的success回调里除了判断HTTP状态码还要判断返回的code字段因为很多同学只判断前者HTTP 200但业务code是冲突的时候页面还是显示成功这很坑。核心接口大概是这几个获取课表列表GET /api/schedule?week第几周rolestudent提交预约申请POST /api/appointment实验室查询GET /api/labs?type实验类型管理员审批POST /api/admin/review冲突检测POST /api/schedule/conflict做接口设计时别追求“一个接口干所有事”尽量做到职责单一。比如检查冲突的接口单独拎出来前端提交前可以先调一次做预检后端提交时再查一次做最终校验双重保险。3. 排课核心逻辑与实操实现3.1 排课冲突检测把时间看成一条数组这台系统的“技术含量”大半都压在冲突检测上。我的做法是把“一周可用时间”拆成一个二维数组横轴是星期几1到7纵轴是节次1到N然后在此基础上叠加周次信息。为什么要这么拆因为它符合直觉也特别容易可视化。你可以想象有一个大表格每行是一节课的时间槽每列是一间实验室排课本质上就是在这个二维格子矩阵里“找空位”。但凡有一个格子被占用了后来的课程就不能再塞进去。核心冲突检测逻辑我用Java写给你看逻辑本身并不复杂// 判断新排课是否与已有排课冲突 public boolean hasConflict(ScheduleRequest req, ListSchedule existingSchedules) { for (Schedule s : existingSchedules) { // 先判断是否同一实验室 if (!s.getLabId().equals(req.getLabId())) { continue; } // 再判断时间上是否有交集 if (isTimeOverlap(s, req)) { // 如果时间有交集还要看周次是否重叠 if (isWeekOverlap(s.getWeekStart(), s.getWeekEnd(), s.getWeekType(), req.getWeekStart(), req.getWeekEnd(), req.getWeekType())) { return true; } } } return false; }isTimeOverlap的判断逻辑是星期的交集 节次的交集。两个排课在同一星期且节次区间有重叠就说明在“本周这个时间片”上是撞车的。节次重叠判断公式其实很简单就是“开始时间的最大值 ≤ 结束时间的最小值”也就是两个区间只要满足Math.max(startA, startB) Math.min(endA, endB)就算重叠。周次重叠稍微绕一点因为要考虑单双周。我的做法是把周次展开成一组离散的整数集合比如单周模式下的1、3、5、7周然后求两个集合是否有交集。用HashSet存遍历比较就行代码简单效率也足够。数据库层面我给排课表加了一个唯一索引UNIQUE KEY (lab_id, day_of_week, section_start, week_type)。这个唯一索引是兜底方案即使代码层判断有漏洞数据库也能挡住明显的重复。这里必须说一个我自己踩过的坑刚开始我只判断了“时间完全相等”的情况结果两门课各占了同一时段的半节课数据库没拦住课表页面显示出来就特别诡异。后来才意识到排课冲突一定是区间重叠判断而不是相等判断。这个小教训对排课类系统特别典型。3.2 小程序端预约与课表渲染的实现细节小程序端的核心交互就两个选时间和看课表。选时间这块我建议用微信原生picker组件不要自己去封装日历控件。三种picker配合使用日期选择器选周次和星期多列选择器选节次范围再配一个选单双周的下拉框。常见的做法是让用户先选星期几再选开始节次和结束节次系统自动换算成对应的day_of_week和section_start、section_end。课表渲染这块有两个路线用grid样式画格子或者用canvas画。我的建议是grid因为课表是典型的“表格型信息”每个格子显示课程名、教师、实验室点击能看详情。用CSS Grid或Flex布局就能实现不必上canvascanvas虽然视觉效果好但事件绑定和自适应麻烦得多。前端渲染有一个性能大坑如果一周的课表数据量很大一次性往setData里塞全量数组页面会卡顿甚至报“setData数据过大”的警告。正确处理方式是只渲染可见范围比如按当前周的维度过滤后再setData或者用分包渲染思想先渲染星期一的课程用户切换星期时再动态加载。小程序端还要注意一个细节时间格式。后端返回的时间我统一用字符串“yyyy-MM-dd”格式前端picker选出来的也是这个格式两边对齐就不会出现“2024-09-01”和“2024/09/01”这种莫名其妙的匹配失败问题。这个问题看起来很幼稚但实际在接口联调时绝对是最常出现的问题之一。3.3 源码结构与调试环境准备拿到这套源码第一步不是急着跑而是先理清目录结构。我习惯的前后端结构是这样的根目录/miniprogram小程序前端代码包含pages、components、utils、api四层根目录/server后端Spring Boot工程包含controller、service、mapper、entity四层根目录/doc项目文档和数据库脚本根目录/sql初始化数据库的SQL脚本配置文件有两个地方要改小程序端的config.js里改接口baseURL后端application.yml里改数据库用户名密码。baseURL这里有个坑本地联调时填http://localhost:8080真机预览时要改成电脑的局域网IP比如http://192.168.1.100:8080并且微信开发者工具里要勾选“不校验合法域名”。调试顺序我一般建议“先后端、再前端、最后联调”。后端用Postman测接口确认数据正确了再写前端页面否则页面写完了接口有问题排查起来两个端来回跳效率极低。我在调试这个系统时的经验是先把管理端的排课接口测通再用小程序端去调用因为后台接口的返回结构业务复杂度高管好后端能提前消灭80%的问题。4. 常见问题与排查技巧实录4.1 预约并发冲突看起来没冲突提交就冲突这个场景描述起来很经典两个学生同时瞄上了同一间实验室的同一个时段后端第一次校验时都通过了结果两个人先后写入数据库就出现了双倍预约。如果你只有前端预检那这个问题一定会发生。我的解决方案是三层防护第一层前端提交前调一次冲突检测接口及时给出可视化的“该时段已被占用”提示改善体验。第二层后端Service层在写入前再次做冲突检查因为后端是可以拿到最新数据的。第三层数据库层面加唯一索引兜底就算前两层都漏了数据库也会拒绝其中一条记录。排课系统这种并发量级根本不到上消息队列的程度直接三层判断加数据库索引就是最可靠的方案。别整花活多整一个Redis缓存反而增加了不一致的风险。4.2 真机预览联调域名校验和网络问题怎么破小程序和普通网页调试最大的不同就是域名限制。开发工具里可以勾选“不校验合法域名”但是真机预览时这个选项不生效你需要在小程序管理后台把后端域名加入request合法域名列表还必须是在ICP备案过的域名。本地联调阶段有个讨巧的办法不用真机直接用开发者工具的“真机调试”功能它可以复用开发工具的网络环境给手机预览时接口直接访问局域网地址。如果一定要在手机上单独体验那就用“局域网IP 关闭防火墙”的方式临时顶一下但正式上线前肯定要换HTTPS域名。这中间最容易出的问题就是“request:fail”报错十个里面有八个是域名或IP没配对。排查顺序先确认后端能通过Postman访问再确认地址是局域网IP而不是localhost最后看开发者工具的“不校验合法域名”是否勾选。4.3 微信小程序端几个高频报错速查我整理了一份在实际调试中反复出现过的高频问题表你可以直接对照着排查报错现象根本原因解决办法setData数据过大一次性往data里塞了太多课表数据分页加载或按学校周次过滤后set页面出现undefined渲染时访问了不存在的字段在wxml中用wx:if判断对象是否存在提交报名但显示失败前端提交的参数和后端字段名不对应对齐接口文档中的参数命名时间显示错乱前后端时间格式不一致比如字符串斜杠和横杠统一使用“yyyy-MM-dd”格式picker选择无反应组件绑定的事件名拼写错误检查bindchange与bindconfirm是否混用授权弹窗反复出现用户拒绝过授权前端未做兜底在首次授权后调用wx.getSetting判断状态还有一个隐蔽问题值得单独说小程序冷启动和热启动时重新获取token的时机如果不对页面会出现“数据加载中但接口401”的尴尬状态。我的做法是在app.js的onLaunch里先确保拿token拿到之后再渲染首页并且给每个请求增加一个“token失效则自动刷新”的拦截逻辑。4.4 审核和交付时最容易忽视的坑文档要跟上很多同学做完源码就以为万事大吉结果交付的时候才发现文档拉胯。这套项目带的文档应该是三个需求文档画出业务流程图和用例图、数据库设计文档表结构说明ER图、部署文档环境要求、启动步骤、常见问题。我自己写文档有个习惯把部署步骤写成“重灾区注意”的格式比如“第一步必须做这个、第二步不要那样做”而不是写那种模棱两可的“配置好环境即可”。因为接手你项目的人大概率是下一个年级的学弟学妹他们不会猜你的意图只能按你写的步骤走。文档里最容易被忽略的是“默认账号密码说明”至少要把管理员账号写清楚否则收到源码的人第一步就卡在登录上。另外数据库初始化脚本一定要包含基础数据比如几个实验室样例和一周的空闲模板这样才能让系统启动后页面不空。5. 搭建过程中值得记住的几个经验这个系统从零到一完整做下来我最想提醒后面人的一点是先想清楚“时间怎么表达”再开始写代码。时间表达是排课系统的基础抽象用“周次星期节次单双周”这套模型去设计后面的冲突检测、课表渲染都会顺很多。其次别把精力浪费在不重要的页面上。有些同学花大量时间做酷炫的CSS动画结果业务逻辑一塌糊涂。排课系统的核心是数据和算法不是视觉表现小程序本身的美观保持整洁大方就够了。最后再分享一个调试时的小技巧如果你发现课表页面某个格子显示不正常先在控制台打印对应那条排课记录的所有字段八成是“week_type判断的边界问题”。我调试时还习惯给每条排课记录加一个“虚拟ID”就是排课表中字段拼接出来的字符串比如“W3-THU-S3-LAB5”看到这个ID就能快速判断一条记录是哪个时间、哪个实验室排查速度快到飞起。实验室排课系统这个项目麻雀虽小五脏俱全认真做完一遍你对小程序开发、后端接口设计、业务逻辑抽象和数据库建模的认识都会上一个台阶。照着上面的思路一步步来把冲突检测做好、把调试流程跑通源码文档调试三者齐全之后不管是交作业还是真实落地你都会非常从容。