简介这是一份面向毕业设计的微信小程序琴房管理系统完整项目适合计算机相关专业学生用于课程设计、毕业设计参考或练手。项目采用微信开发者工具搭配 Java 与 MySQL 实现涵盖学生端和管理员端两类用户学生可浏览琴房信息、公告、在线留言并登录后预约管理员可进行轮播公告、师生信息、留言审核及琴房类型与预约等后台管理。资源包共包含 1097 个文件压缩后大小 18.76MB文件类型以 png、svg 等静态资源vue、js 等前端代码class、java 等后端源码以及 wxml、wxss 等小程序页面文件为主还附带 sql 数据库脚本、bat 启动脚本和 mp4 演示视频便于直接导入部署和对照学习。已有 356 人学习下载整体目录结构清晰功能模块覆盖完整对理解前后端分离的小程序开发及权限管理流程有较高参考价值。1. 琴房管理系统第一步先问清楚“预约冲突”到底谁来管毕业设计选“琴房管理系统”这个微信小程序题目多数人第一反应是做一堆页面首页轮播图、琴房列表、预约按钮、个人中心。但真正到了开题答辩或者演示的时候老师问一句“两个学生同时预约同一间琴房你的系统怎么处理”很多人的源码就露馅了。这个题目的核心不是 UI而是预约状态机和并发冲突处理。你要交付的是一套能说明白“谁能约、约哪个时间段、什么时候可以取消、爽约怎么算”的小程序配套管理端查看订单和房间状态最后再录一段能讲清楚业务的演示视频。这套系统适合三类人需要完成微信小程序毕业设计的学生想给学校音乐教室/培训机构的琴房做预约管理的开发者以及想找一个“小程序 后端 管理端”全栈案例练手的人。技术选型上小程序端用原生框架就够了后端可以用 Spring Boot、Node.js 或者 Django关键不在于用什么框架而在于预约时间段的数据模型是否经得起并发和时间重叠的考验。下面我按自己带过项目的顺序从角色、数据库、接口、小程序代码、排错到答辩把整个落地路径拆开讲清楚。2. 数据库与接口设计房间、预约、计费三张表怎么定不打架2.1 角色与权限学生、教师、管理员可以做什么琴房管理系统的角色我一般建议拆成学生、教师、管理员三个而不是做一套复杂的 RBAC 权限模型。学生能做的事很有限浏览琴房、提交预约、取消未开始的预约、查看自己的历史记录和扣费情况。教师除了学生的基础权限之外还能预约专门留给教学的教室并且可以查看自己名下的排课时段。管理员负责维护琴房基础数据、审核预约、查看计费流水、处理异常订单。为什么不建议给每个角色建一张表因为登录凭证是同一个微信 openid只需要在用户表里加一个 role 字段登录后在服务端签发带有角色信息的 token小程序端根据 role 渲染不同的菜单和按钮。如果做成三套独立账号体系开发和演示视频都会变得很啰嗦。权限的校验一定要放在后端接口里做小程序端的按钮隐藏只是用户体验不能作为安全边界。角色划清之后紧接着要确定一个业务规则预约的最小时间粒度是多少。常见做法是 30 分钟或 1 小时以 30 分钟为例一天 8:00-22:00 就有 28 个可选时段。时间粒度决定了后面所有表的设计和前端日历网格的渲染方式所以先用一句话把它固定下来所有时段都是左闭右开例如 10:00-10:3010:30 可以约下一个人10:00 不能重叠。2.2 数据库表结构核心表只留五张别一上来就造十张表我第一次做琴房系统时建了十几张表后来发现一半是多余的。真正需要长期维护的只有五张用户表、琴房表、预约表、订单/计费表、教室排课表可选。如果你做的是带余额充值的版本再加一张余额变更流水表。表一旦建多小程序端和后端接口的开发量都会翻倍毕业设计周期内不划算。下面这组建表 SQL 是我沿用了几个项目的一套直接跑在 MySQL 5.7 以上版本可行-- 用户表学生、教师共用用 role 区分 CREATE TABLE user ( id INT NOT NULL AUTO_INCREMENT, openid VARCHAR(64) NOT NULL COMMENT 微信小程序唯一标识, name VARCHAR(50) NOT NULL DEFAULT , student_no VARCHAR(20) DEFAULT COMMENT 学号/工号, role TINYINT NOT NULL DEFAULT 1 COMMENT 1学生 2教师 3管理员, balance DECIMAL(10,2) NOT NULL DEFAULT 0 COMMENT 账户余额, status TINYINT NOT NULL DEFAULT 1 COMMENT 1正常 0冻结, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), UNIQUE KEY uk_openid (openid) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; -- 琴房表 CREATE TABLE room ( id INT NOT NULL AUTO_INCREMENT, name VARCHAR(50) NOT NULL COMMENT 琴房名称如 A101, building VARCHAR(50) NOT NULL DEFAULT , capacity TINYINT NOT NULL DEFAULT 1, room_type TINYINT NOT NULL DEFAULT 1 COMMENT 1练习房 2教学房, status TINYINT NOT NULL DEFAULT 1 COMMENT 1启用 0停用, PRIMARY KEY (id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; -- 预约表核心中的核心 CREATE TABLE booking ( id INT NOT NULL AUTO_INCREMENT, room_id INT NOT NULL, user_id INT NOT NULL, book_date DATE NOT NULL COMMENT 预约日期只存日期, start_time TIME NOT NULL, end_time TIME NOT NULL, status TINYINT NOT NULL DEFAULT 0 COMMENT 0待支付 1已预约 2已使用 3已取消 4爽约, source TINYINT NOT NULL DEFAULT 1 COMMENT 1小程序预约 2管理端代约, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), KEY idx_room_time (room_id, book_date, start_time, end_time), KEY idx_user_time (user_id, book_date) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; -- 订单/计费表 CREATE TABLE orders ( id INT NOT NULL AUTO_INCREMENT, order_no VARCHAR(32) NOT NULL COMMENT 订单号业务编号, booking_id INT NOT NULL, user_id INT NOT NULL, room_id INT NOT NULL, amount DECIMAL(10,2) NOT NULL DEFAULT 0, duration_minutes INT NOT NULL COMMENT 实际使用分钟数, status TINYINT NOT NULL DEFAULT 0 COMMENT 0未支付 1已支付 2已退款, pay_time DATETIME DEFAULT NULL, PRIMARY KEY (id), UNIQUE KEY uk_order_no (order_no) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;这套表的重点在 booking 表。预约冲突的检查不能只靠start_time 新结束时间 AND end_time 新开始时间这一条还要在同一个book_date和同一个room_id下判断并且只查状态为待支付和已预约的记录。索引建在room_id, book_date, start_time, end_time上就是为了让这个冲突查询走索引而不是全表扫描。订单表不直接记录“时段”而是记录“时长”因为计费价格可能变化订单表保存刷卡当时的价格快照避免以后改价导致历史账目对不上。2.3 接口约定前后端先定好这六个接口开发节奏会顺很多不要等到后端写完再定接口我会先把接口契约写在文档里小程序端和后端可以并行开发。毕业设计级别的琴房系统对外暴露的核心接口就六个登录、琴房列表、创建预约、取消预约、支付/模拟支付、开门。如果你加管理端再补一个预约查询和订单查询接口。接口格式统一用 JSON返回结构固定为code message data。例如创建预约的请求参数和后端响应如下// POST /api/booking/create { roomId: 1, bookDate: 2025-05-20, startTime: 10:00, endTime: 11:00 } // 成功后返回 { code: 0, message: ok, data: { bookingId: 101, status: 0, expireMinutes: 15 } }这里的expireMinutes是一个容易忽略但很加分的参数预约创建后如果 15 分钟内未支付系统自动释放时段。很多同学只做预约和支付却忘了释放超时未支付订单最后演示时发现某个时段永远被一个假订单占着。后端可以用定时任务扫表也可以在查询空闲时段时把超时未支付订单标记为已取消两种做法都能在演示时讲清楚你考虑了资源回收。3. 微信小程序端落地预约状态机、日历网格与扫码开门的可复现代码3.1 预约状态机把状态变化写在一个文件里避免到处散落魔法数字小程序端最常见的翻车不是页面不会写而是 status 字段到处写死数字改一个状态就要改十个地方。我建议在 utils 目录下建一个booking-status.js把状态和允许迁移的规则集中管理这样演示时被问到“如果用户支付后想取消怎么办”也能直接用代码回答。// utils/booking-status.js const BOOKING_STATUS { PENDING: 0, // 待支付 BOOKED: 1, // 已预约 USED: 2, // 已使用 CANCELED: 3, // 已取消 NO_SHOW: 4 // 爽约 }; // 状态迁移规则记录从当前状态能迁到哪些状态 const TRANSITIONS { [BOOKING_STATUS.PENDING]: [BOOKING_STATUS.BOOKED, BOOKING_STATUS.CANCELED], [BOOKING_STATUS.BOOKED]: [BOOKING_STATUS.USED, BOOKING_STATUS.CANCELED], [BOOKING_STATUS.USED]: [], [BOOKING_STATUS.CANCELED]: [], [BOOKING_STATUS.NO_SHOW]: [] }; function canTransition(from, to) { return TRANSITIONS[from] TRANSITIONS[from].includes(to); } module.exports { BOOKING_STATUS, canTransition };这个文件在页面里的用法是用户点击取消按钮时先拿到当前预约记录的 status调用canTransition(status, BOOKING_STATUS.CANCELED)返回 true 才发起取消请求。好处是后端返回非预期状态时前端能立刻发现并提示“当前状态不可操作”而不是出现按钮能点但请求失败的黑匣子。参数上PENDING需要在创建后 15 分钟内完成支付BOOKED直到预约开始前都可以取消开始后半小时没有扫码开门就自动转成NO_SHOW。3.2 用 view 网格实现琴房周视图顶部固定时间轴内容区横向滚动琴房预订页我推荐做成“左侧时间段 右侧琴房列”的横向滚动网格而不是复杂的 canvas 日历。原因有两个canvas 在滚动时层级问题多而且用户改周数时重新绘制麻烦。纯 view 实现就够用配合scroll-view横向滚动体验已经很接近成熟产品。下面是一个精简版的周视图数据结构生成逻辑核心是生成从本周一到本周日的日期数组再为每个琴房生成时段格子// pages/booking/index.js 节选 const DAY_MS 24 * 60 * 60 * 1000; const SLOT_MINUTES 30; function getWeekDates() { const now new Date(); const day now.getDay() 0 ? 7 : now.getDay(); // 周一1 const monday new Date(now.getFullYear(), now.getMonth(), now.getDate() - day 1); const dates []; for (let i 0; i 7; i) { const d new Date(monday.getTime() i * DAY_MS); dates.push({ date: formatDate(d), // 2025-05-20 weekday: 周 一二三四五六日[i] }); } return dates; } function buildSlots(rooms, dates, bookedList) { const slots []; rooms.forEach(room { dates.forEach(date { for (let t 8 * 60; t 22 * 60; t SLOT_MINUTES) { const start toTime(t); const end toTime(t SLOT_MINUTES); const booked bookedList.some(b b.roomId room.id b.date date.date b.startTime start ); slots.push({ roomId: room.id, date: date.date, start, end, status: booked ? disabled : free }); } }); }); return slots; }这段代码里的SLOT_MINUTES 30决定了每个格子的最小时间单位。营业时间用 8:00 到 22:00如果你管理的琴房有午休或固定归还没时段的规则可以再定义一个OPEN_MINUTES和CLOSED_SLOTS数组把不可预约时间段过滤掉。生成 slot 时服务端返回的bookedList应该只包含当天未来且状态为待支付/已预约的记录不要把已取消的记录混进来。disabled格子的跳转事件直接 return用户在界面上看到灰色就不会再点了。需要注意日期格式化函数formatDate不要用toISOString()因为toISOString()返回的是 UTC 时间。在东八区new Date(2025-05-20).toISOString()会变成前一天 16:00直接用会导致日期错位。我在这上面踩过坑后面避坑章节还会展开。3.3 对接支付与模拟支付毕业设计没有商户号怎么办毕业设计阶段很少能申请下来微信支付商户号因为小程序主体需要企业资质个人主体拿不到支付接口。所以大多数源码包里的做法是做一个模拟支付按钮前端先调后端payment/prepay接口后端不真的请求微信支付而是直接生成一笔已支付订单并把对应预约状态改成已预约。这里的实现思路我可以给你一个可复用的方案// 前端模拟支付请求 async function mockPay(bookingId, amount) { const res await wx.request({ url: ${baseUrl}/payment/mockPay, method: POST, data: { bookingId }, header: { Authorization: Bearer ${token} } }); if (res.data.code 0) { wx.showToast({ title: 支付成功, icon: success }); // 刷新预约状态 loadBookingDetail(bookingId); } }// 后端模拟支付接口Express 写法示意 router.post(/payment/mockPay, async (req, res) { const { bookingId } req.body; const booking await db.getBooking(bookingId); if (!booking || booking.status ! 0) { return res.json({ code: 400, message: 预约不存在或状态不正确 }); } // 计算金额按分钟数 * 单价 const minutes diffMinutes(booking.start_time, booking.end_time); const amount minutes * getRoomPrice(booking.room_id); await db.payOrder(bookingId, amount); res.json({ code: 0, message: ok }); });做这个模拟支付时前端页面里仍然要保留一个真实的“唤起收银台”的逻辑入口只是在一个假按钮下面写上“模拟支付”。答辩时老师问为什么不接真实支付你就能回答已经按微信支付的wx.requestPayment参数格式封装只需要在后端换成真实预下单接口并传入商户号即可切换生产环境。这个回答比直接说“个人主体没法申请”得分高很多。扫码开门是琴房系统另一个高频功能点。小程序端用wx.scanCode扫描贴在琴房门上的二维码二维码内容是一个 URL带 roomId 和校验 token然后调用/api/door/open接口后端校验当前用户在该时间段是否有状态为“已预约”的 booking校验通过才返回开门指令。真实项目里开门指令会发给门禁硬件或管理员的 WebSocket毕业设计只需要模拟一个“开门成功”的弹窗即可。4. 避坑琴房管理小程序最常见的 5 个翻车现场4.1 日期错位预约日期永远比实际早一天现象创建预约时选择 2025-05-20提交到后端后 MySQL 里存成了 2025-05-19或者展示时界面日期和数据库差一天。原因JavaScript 的new Date(2025-05-20)得到的是本地时区当天零点的 Date 对象但toISOString()会转成 UTC 时间。东八区等于new Date(2025-05-20).toISOString()得到2025-05-19T16:00:00.000Z。解决统一用YYYY-MM-DD字符串传输不在前端做 Date 对象转换传参。格式函数用本地时间拼接就好function formatDate(date) { const y date.getFullYear(); const m String(date.getMonth() 1).padStart(2, 0); const d String(date.getDate()).padStart(2, 0); return ${y}-${m}-${d}; }4.2 时间重叠判断漏掉边界条件现象预约 10:00-11:30另一个用户还能约 10:30-11:00导致一间琴房被两个订单覆盖。原因SQL 冲突条件只写了start_time new_end_time AND end_time new_start_time但没有限定book_date相同或者用了而没有用‘’导致刚好在边界值上出错。解决把重叠判断完整写成SELECT COUNT(*) FROM booking WHERE room_id ? AND book_date ? AND status IN (0, 1) AND start_time ? AND end_time ?;四个参数依次是屏房ID、预约日期、新结束时间、新开始时间。只要返回数量大于 0 就拒绝创建。这里start_time end_time的关系是左闭右开所以 10:00-10:30 和 10:30-11:00 两个时段不会重叠。4.3 未支付订单占坑现象演示时某间琴房全天被一个待支付订单占住其他人预约不进去而那个用户早已离开页面。原因创建预约时只写状态为待支付没有设置超时机制也没有定时任务释放。解决两条路。一是后端在查询空闲时段时先把创建时间超过 15 分钟且状态为 0 的预约改为已取消再返回可用列表二是更稳妥地加一张payment表小程序端支付轮询时如果 15 分钟内未支付就主动调接口释放。演示视频里我建议把超时时间从 15 分钟改小到 2 分钟这样录视频时能当场演示“不支付自动释放”。4.4 原生组件层级导致弹窗被遮挡现象预约成功弹窗打开时页面上方的map或canvas原生组件穿透了弹窗文字按钮被盖住。原因微信小程序里原生组件如 canvas、map、video 的层级高于普通 view即使弹窗 z-index 设得再高也无效。解决如果在琴房列表页用了 canvas 画海报或图形弹窗改用cover-view承载如果 canvas 只用来做展示把 canvas 节点在弹窗打开时隐藏关闭后再重新绘制。或者干脆用普通 view 模拟日历格子完全避开 canvas 原生组件这也是我推荐纯 view 方案的原因。4.5 一个微信号测试教师和学生角色不方便现象开发时同一个微信号登录后角色只能是学生演示视频里又想展示教师预约和管理员审核频繁切换账号很麻烦。原因后端把 openid 和角色绑定在 user 表里首次登录创建一条用户记录后角色就固定了。解决在开发者工具里用“添加编译模式”并指定不同的打开页面或者在登录接口加一个mockRole参数只在开发环境生效测试时模拟不同身份返回对应 token。真机上用微信扫码登录时再用测试账号手动改数据库角色。演示视频里可以直接说“这里我们用测试账号展示教师端功能”比现场切换登录强得多。5. 演示视频与答辩把源码讲成能通过评审的毕业设计5.1 演示视频的录制顺序先讲问题再讲界面最后补后台很多人录演示视频一上来就打开小程序点来点去老师不知道业务逻辑分数容易被压低。我的录制习惯是固定三段第一段用旁白说清楚系统要解决的问题比如“琴房管理最核心的是预约不冲突”第二段按“登录—浏览琴房—预约—支付—查看我的预约—扫码开门”的顺序操作小程序期间每做一步就用一句话解释当前状态从什么变成什么第三段切到 swagger 或 admin 管理页面展示订单列表和预约记录时间控制在 6-8 分钟。演示视频里要特别展示一个“冲突被拒绝”的场景用一个账号预约某个时段换一个账号预约同一时段小程序端提示“该时段已被预约”。这个 10 秒钟的操作比任何页面设计都能证明系统真的做了并发控制。另外视频结尾至少留一个界面展示数据库表变化比如新增预约后booking表多了一条记录说明前端和后端是真实连通的。5.2 答辩时最常被问的 3 个问题怎么答才不像背稿第一个问题是“为什么不用 uniapp 做”。别直接说“老师要求用原生”可以这样答原生小程序能直接调用扫码、蓝牙等能力且骨架轻后续要迁移到 uniapp 也不需要改太多业务逻辑因为预约状态机是纯 JavaScript 模块放哪个框架都能复用。这个回答把问题引到了代码分层上。第二个问题是“多个用户同时抢同一个时段怎么办”。如果只回答“后端判断时间重叠”老师会追问“并发时两个请求都查不到记录怎么办”。更好的回答是数据库层面对(room_id, book_date, start_time)加唯一约束或悲观锁创建预约时先SELECT ... FOR UPDATE锁住该琴房当天时段再插入记录。虽然毕业设计不一定真做但说出来就证明了你知道并发边界。第三个问题是“有没有做过真机测试”。如实回答即可但补一句验证方法用开发者工具的模拟支付跑通全流程后再用预览码真机扫码测试重点盯wx.scanCode和定位授权在真机上和开发工具的行为差异。我的个人习惯是把上面这三个问题的回答要点写在源码包的说明文档里做成“答辩 FAQ”。因为录演示视频那几天往往很紧张有现成的要点在现场就不容易卡壳。琴房项目真正难的不是代码而是把“谁能约、怎么收费、爽约了怎么处理”这几个规则想完整。规则一旦定清你甚至可以把前端的表格和后端的接口直接延伸成其他预约类系统比如会议室预约、排练厅预约。希望这套打法能帮你少走弯路顺利拿下毕业设计。本文还有配套的精品资源点击获取