简介：面向高校计算机相关专业毕业设计的微信小程序讲座预约系统完整项目，内含源码、说明文档与演示录像。系统基于微信开发者工具+Java+MySQL实现，分为学生和管理员两类角色：学生端可浏览讲座信息、查看轮播图/公告、在线留言、注册登录并预约讲座；管理员端则负责轮播公告管理、学生信息审核，以及讲座信息、预约记录和评论的管理，覆盖了小程序前端到Java后端再到MySQL数据库的完整闭环。压缩包共1303个文件，核心文件类型包括Vue/JS/WXML/WXSS前端页面、Java后端逻辑、SQL数据库脚本，附带PNG/JPG界面截图和MP4演示录像，整体约56.86MB，目录结构清晰，便于对照学习和二次开发。已有300人学习下载，适合作为毕业设计参考或小程序开发练手项目，可直接运行演示，也可根据说明文档快速理解模块设计。

1. 讲座预约小程序：毕设选题里被低估的「全链路」选项

如果把「微信小程序毕业设计-讲座预约系统」这类选题摊在桌面上，多数人的第一反应是「又是一个管理系统换皮」。但按源码、说明文档、演示录像配套交付的角度真正做下来，会发现它是小程序类毕设里少见的全链路选题：用户端和管理端都有，预约状态要流转，名额要防超卖，还涉及微信登录标识和核销签到，信息量一点不比传统 Web 毕设少。

它适合三类人：想快速交付、不想在部署环境上耗时间的；答辩怕被追问底层细节、需要拿真实业务逻辑挡问题的；以及准备走小程序方向、需要一个完整案例支撑作品集的人。前端是 WXML 加 JS，后端走云开发免运维，数据量在毕设量级完全罩得住。下面按一条主线走：先定架构和数据模型，再把登录、预约、取消、核销四条核心链路逐个写透，最后落到验收和答辩准备。整个过程可以直接对照着你手上的源码包和演示录像逐步复现。

2. 先定架构再写代码：微信云开发为什么是这次的最优解

做小程序毕设，「技术选型」必须排在写代码之前。选错后端，做到一半返工的成本远比你想的高。讲座预约系统的核心诉求是「预约名额不能被超卖」，这要求后端数据库支持事务或原子更新，同时对部署复杂度要求尽量低，毕竟毕设交付时间有限。

2.1 三种后端方案横向对比：云开发、自建服务器、第三方 BaaS

先看常见做法。很多传统毕设选的是自建服务器，比如 Node.js 或 Java 后端加 MySQL。事务很好做，名额扣减一个 UPDATE 语句就能保证不出错，但代价是得买云服务器、配域名、走备案流程，光环境准备就能耗掉一周。对只求交付和答辩的项目来说，这条路性价比很低。

第三方 BaaS（比如各种后端即服务平台）的问题在于数据访问在国内网络下不稳定，免费额度限制多，权限模型也比较死板，演示现场一旦网络波动就很被动。剩下就是微信云开发，也就是小程序云开发。它把云函数、云数据库、云存储打包在一起，免运维，事务、定时触发器这些关键能力都具备，学生免费额度足够撑起毕设演示。

我一般会直接选云开发，核心理由是「云函数写法与普通 Node.js 几乎一样，但省掉了运维」。毕设答辩关注的是业务逻辑和工程意识，不是你的服务器配置能力，把精力省下来花在预约流程和状态设计上更值。

2.2 数据模型设计：lectures、reservations、users 三张核心集合

云开发数据库是文档型的，集合相当于 MySQL 的表，文档相当于行。讲座预约系统不需要很复杂的表关系，三张核心集合加一张管理员集合就够。先看字段设计。

lectures 集合存讲座本身的信息，核心字段有：title（讲座标题）、speaker（主讲人）、location（地点）、startTime 和 endTime（时间）、capacity（总名额）、booked（已预约人数）、status（状态：open 可预约、closed 已关闭、finished 已结束）。预约相关的核心字段是 capacity 和 booked，所有并发控制都围绕这两个值做。

reservations 集合存预约记录，字段有：lectureId（关联讲座）、openid（预约人）、status（booked 待签到、checked 已签到、cancelled 已取消）、bookTime、cancelTime、checkTime。这里特意把预约状态设计成字符串而不是布尔值，因为后续核销、取消、名单导出都要按状态过滤，字符串比布尔值扩展性好。

users 集合存用户基础信息，字段尽量少：openid、nickname、studentId（学号，可后补）、createdAt。admins 集合只存管理员的 openid，用来做管理端权限判断。要注意的是，这个设计里预约人数冗余在讲座文档里，而不是通过查询 reservations 表 count 得到。为什么不直接用数组存预约人？文档型数据库的数组字段有长度和性能瓶颈，而 booked 加一、减一配合事务更新，是最简单可靠的方案。

2.3 项目目录结构与云环境初始化

拿到源码包后，先看目录结构。纯云开发的微信小程序项目一般长这样：

miniprogram/ app.js # 云开发初始化与全局登录 app.json pages/ index/ # 讲座列表页 detail/ # 讲座详情与预约/取消按钮 myreserve/ # 我的预约列表 admin/ # 管理端：发布讲座/预约名单 checkin/ # 管理员核销页 cloudfunctions/ login/ # 获取 openid 并初始化用户 book/ # 预约讲座（事务） cancel/ # 取消预约（事务） checkin/ # 核销签到（事务） closeLecture/ # 定时关闭已结束讲座 project.config.json

小程序端只负责页面渲染和调用云函数，所有涉及数据写入的操作都放在云函数里，这是后面避坑章节要展开的关键点。先看 app.js 里的云环境初始化，这是整个项目的地基：

// miniprogram/app.js App({ onLaunch() { if (!wx.cloud) { console.error('基础库版本过低，请使用 2.2.3 以上版本') return } wx.cloud.init({ env: 'lecture-dev-xxxxxx', // 云环境 ID，在云开发控制台首页可见 traceUser: true // 开启用户访问记录，便于排查 }) this.login() }, async login() { const { result } = await wx.cloud.callFunction({ name: 'login' }) this.globalData.openid = result.openid wx.setStorageSync('openid', result.openid) }, globalData: { openid: '' } })

env 参数填的是云开发环境 ID，不是环境名称。很多人在这一步把「环境名称」当成「环境 ID」填进去，结果所有云函数调用全部报错。在云开发控制台首页，环境 ID 是一串类似lecture-dev-xxxxxx的标识，复制时注意别带空格。traceUser 会在控制台生成用户访问明细，排查线上问题时很好用，强烈建议打开。

3. 核心功能落地：登录、预约、取消、核销一条线

数据模型定了，接下来是四条核心链路。这一章会给出可直接抄的代码，并解释每段代码里容易踩坑的参数和逻辑边界。预约系统的核心不只是「能约」，还要保证「约不超、约不错、能取消、能核销」。

3.1 用户登录：openid 是身份，学号只是补充

小程序没有传统意义上的账号密码体系。用户的唯一身份标识是 openid，由微信根据用户和小程序联合生成，同一用户在不同小程序里 openid 不同，但在你的小程序里永久不变。获取 openid 的正确姿势不是自己调接口换 session_key，而是直接在云函数里取：

// cloudfunctions/login/index.js const cloud = require('wx-server-sdk') cloud.init({ env: cloud.DYNAMIC_CURRENT_ENV }) exports.main = async () => { const { OPENID } = cloud.getWXContext() const db = cloud.database() const users = db.collection('users') const userRes = await users.where({ openid: OPENID }).get() if (userRes.data.length === 0) { // 首次登录：写入基础信息，学号等用户后续自愿补充 await users.add({ data: { openid: OPENID, nickname: '', studentId: '', createdAt: db.serverDate() } }) } return { openid: OPENID } }

cloud.DYNAMIC_CURRENT_ENV表示云函数运行时自动使用当前环境，不需要硬编码环境 ID，这样代码迁移到别的新环境时不用改。db.serverDate()生成的是数据库服务端时间，避免使用用户手机本地时间带来的偏差。返回 openid 后，前端把它存进 globalData 和本地缓存，后续所有预约、查询操作都以这个 openid 作为用户标识。

这里要澄清一个常见误区：学号不是登录凭证，只是用户自愿填写的补充信息。答辩时老师如果问「怎么确认是本人」，答案是 openid 由微信登录态保证；如果问「换手机后预约还在吗」，答案是 openid 不变，预约记录跟着 openid 走，跟设备无关。

3.2 预约与取消：用事务保证名额不超卖

预约是整个系统的核心中的核心。先看一个最常见的错误写法：先查讲座剩余名额，判断有余额再写入预约记录。这段「先查再写」的逻辑在单用户测试时完全正常，但两个用户同时抢最后一个名额时，两边都查到剩余 1，都通过校验，都执行写入，最后 booked 变成 2，超卖了。解决方式是把校验和写入放进同一个事务，让数据库保证中间态不可见：

// cloudfunctions/book/index.js const cloud = require('wx-server-sdk') cloud.init({ env: cloud.DYNAMIC_CURRENT_ENV }) const db = cloud.database() const _ = db.command exports.main = async (event) => { const { OPENID } = cloud.getWXContext() const { lectureId } = event try { const result = await db.runTransaction(async transaction => { // 1. 事务内读取讲座，拿到可信的最新数据 const lectureRes = await transaction.collection('lectures').doc(lectureId).get() const lecture = lectureRes.data // 2. 业务校验：讲座状态和名额 if (lecture.status !== 'open') return { success: false, msg: '讲座不在预约时间内' } if (lecture.booked >= lecture.capacity) return { success: false, msg: '名额已满' } // 3. 查重：同一个人同一场讲座已有有效预约则拦截 const dup = await transaction.collection('reservations').where({ lectureId: lectureId, openid: OPENID, status: _.in(['booked', 'checked']) }).count() if (dup.total > 0) return { success: false, msg: '您已预约过本场讲座' } // 4. 写入预约记录，同时讲座 booked 加一 await transaction.collection('reservations').add({ data: { lectureId: lectureId, openid: OPENID, status: 'booked', bookTime: db.serverDate() } }) await transaction.collection('lectures').doc(lectureId).update({ data: { booked: _.inc(1) } }) return { success: true } }) return result } catch (err) { return { success: false, msg: '预约失败，请稍后重试', error: err.message } } }

这段代码的关键点有三个。一是事务内所有读操作必须走transaction.collection()，不能混用db.collection()直接读，否则读到的数据不受事务保护。二是_.in(['booked', 'checked'])实现了防重复预约，已经签到的人也不能再次预约同一场。三是_.inc(1)是原子自增操作，booked 字段的更新不依赖读到的旧值，跟事务双保险。取消预约的逻辑方向相反，但同样需要事务保护：

// cloudfunctions/cancel/index.js exports.main = async (event) => { const { OPENID } = cloud.getWXContext() const { reservationId } = event const result = await db.runTransaction(async transaction => { const res = await transaction.collection('reservations').doc(reservationId).get() const record = res.data // 只能取消自己的预约 if (record.openid !== OPENID) return { success: false, msg: '无权操作' } // 只有待签到状态可以取消 if (record.status !== 'booked') return { success: false, msg: '当前状态不可取消' } await transaction.collection('reservations').doc(reservationId).update({ data: { status: 'cancelled', cancelTime: db.serverDate() } }) await transaction.collection('lectures').doc(record.lectureId).update({ data: { booked: _.inc(-1) } }) return { success: true } }) return result }

取消时把 booked 减一，释放出来的名额可以被其他用户预约。状态机上，只有 booked 状态允许取消，checked 之后的记录不可取消，这是为了避免已签到用户占用后又释放造成混乱。演示时先预约、再取消、再重新预约，正好覆盖这条状态流转路径。

3.3 管理端核销：预约二维码与状态流转

核销是讲座预约系统区别于普通报名表的地方。管理员需要确认「这个人确实到场了」。常见做法是用户端展示一个预约凭证码，管理端扫码后把预约状态从 booked 改成 checked。凭证码推荐用微信小程序码，用户不需要额外装别的 App，演示效果也好看：

// cloudfunctions/getQrcode/index.js const cloud = require('wx-server-sdk') cloud.init({ env: cloud.DYNAMIC_CURRENT_ENV }) exports.main = async (event) => { const { reservationId } = event // scene 参数最多 32 个可见字符，这里直接放预约记录 ID const result = await cloud.openapi.wxacode.getUnlimited({ scene: reservationId, page: 'pages/checkin/checkin', width: 280, checkPath: false }) // 返回图片 buffer，前端转 base64 后渲染成二维码 return result.buffer }

微信小程序码的scene字段有 32 字符的长度限制，云开发的文档 ID 足够短，直接放 reservationId 正合适。checkPath设为 false 表示用户扫码时自动进入指定 page 路径，不需要额外校验页面路径是否在小程序配置里声明过。前台拿到返回值后，用wx.arrayBufferToBase64转成图片数据展示。

核销动作本身放在管理员的 checkin 云函数里，判断管理员身份后做状态更新：

// cloudfunctions/checkin/index.js exports.main = async (event) => { const { OPENID } = cloud.getWXContext() const { reservationId } = event // 校验管理员身份 const adminRes = await db.collection('admins').where({ openid: OPENID }).get() if (adminRes.data.length === 0) { return { success: false, msg: '非管理员，无权核销' } } const result = await db.runTransaction(async transaction => { const res = await transaction.collection('reservations').doc(reservationId).get() const record = res.data if (record.status !== 'booked') return { success: false, msg: '当前状态不可核销' } await transaction.collection('reservations').doc(reservationId).update({ data: { status: 'checked', checkTime: db.serverDate() } }) return { success: true, lectureId: record.lectureId } }) return result }

核销完成后，前端可以跳转到该讲座的预约名单页，展示已签到列表。整个状态机就三态流转：booked 到 checked（核销）、booked 到 cancelled（用户取消）、checked 不可取消。这比传统 Web 管理系统的「报名-到场」两态多了一层可控性，答辩时能讲出东西。

4. 常见问题排查：这 5 个云开发调用坑会浪费你一晚上

云开发把运维成本降到很低，但它的坑不在服务器，而在「权限规则」「调用环境」「数据格式」这些容易被忽略的细节上。以下 5 条是我见过频率最高的翻车现场，每一条都能让你在演示前夜崩溃。

4.1 坑一：数据库权限默认「仅创建者可读写」，讲座列表永远是空的

现象：小程序端db.collection('lectures').get()返回空数组，云开发控制台里明明能看到数据。原因：云开发数据库集合的默认权限是「仅创建者可读写」，小程序端读取时没有管理员身份，非创建者读不到其他人写入的文档。解决：在云开发控制台进入该集合的权限设置，把 lectures 的读权限改成「所有用户可读」，写入权限保持「仅创建者可写」或全部走云函数。注意，改变权限后要重新编译小程序端，开发者工具里的缓存不会自动刷新。

4.2 坑二：env 没配对，所有云函数调用报 -501007

现象：wx.cloud.callFunction返回错误码 -501007，提示「invalid env」。原因：app.js 里wx.cloud.init的 env 填成了环境名称，或者复制时多带了空格。解决：回到云开发控制台首页，环境 ID 是一串带连字符的短标识，不是中文名称。如果是拷贝源码包的，还要确认该环境的数据库集合和云函数是否真的存在，很多毕设源码换了新环境但没重新部署云函数。

4.3 坑三：setData 在异步回调里没生效，页面白屏

现象：onLoad 里调用云函数，云函数返回数据后页面没有任何反应，但 console.log 能打出数据。原因：云函数调用是异步的，页面 onLoad 先执行完，数据返回后才触发回调，如果没在回调里 setData，数据到了也渲染不出来。解决：用 async/await 包住云函数调用，再把结果 setData。另外，setData 的 key 要用字符串路径，直接把整个对象塞进去会触发全量更新，数据量大时明显卡顿。

// pages/index/index.js Page({ async onLoad() { const db = wx.cloud.database() const res = await db.collection('lectures').get() this.setData({ lectures: res.data }) // 等 await 完成后再更新页面 } })

这段代码能跑通的前提是 lectures 集合读权限已放开。如果你在页面上查不到数据，先回 4.1 查权限。

4.4 坑四：云函数默认超时 3 秒，批量写操作直接挂

现象：云函数执行到一半返回 timeout，数据库部分写入成功造成数据不一致。原因：云函数默认超时时间是 3 秒，预约高峰时段并发上去，或者一次操作涉及多个集合读写，很容易超。解决：在云函数目录下的 config.json 里把超时调大，云函数重试策略选「不重试」。

{ "permissions": { "openapi": ["wxacode.getUnlimited"] }, "timeout": 10 }

timeout 单位是秒，毕设项目设 10 秒足够。这里有个隐藏点：云函数默认重试策略是「重试两次」，对于预约这类写操作，重试会导致重复写入，所以 config.json 里要显式把重试关掉。

4.5 坑五：日期显示差 8 小时，startTime 和 endTime 对不上

现象：讲座开始时间在管理端看是 19:00，小程序端显示 03:00。原因：db.serverDate()和new Date()写入数据库时按 UTC 存储，前端展示时用了本地时区转换，而日期字符串格式化时没做时区处理。解决：统一用一个格式化函数，获取到日期字段后先转成 Date 对象，再按 UTC+8 手动补齐时区偏移，或者直接用 dayjs 这类库做格式化，不要在多个页面各写一套。

这些坑的共同点是「本地跑得好好的，一部署就出问题」。排查时先看云开发控制台的日志面板，云函数执行日志和数据库请求记录都会列出来，比盲猜快得多。

5. 验收与答辩：按「能跑通、能讲清」标准做最后自检

功能写完不代表毕设完成，还得抗住演示和答辩两个环节。演示录像里的每一步操作，都要对应到代码里一段具体的逻辑；答辩时被问的问题，都要能在数据库和云函数层面说清楚。

5.1 功能自测用例表：8 个必测点

这 8 个用例覆盖了预约系统的主要状态迁移路径。建议每测一条，就在说明文档里对应记录一条测试结果，答辩时直接翻给老师看，比嘴上说「测过了」有说服力。

5.2 演示录像的录制脚本：三幕式录法

演示录像不要边录边想，提前写好脚本。我一般按三幕来录。第一幕是用户端全流程，时长控制在 3 分钟：进入首页看讲座列表，点进详情看信息，点击预约，展示预约成功反馈，切到「我的预约」确认状态。第二幕是取消与重约，1 分钟：在「我的预约」里取消刚约的讲座，再回来重新预约，展示状态从 booked 到 cancelled 再到 booked 的完整流转。第三幕是管理端操作，2 分钟：管理员发布一场新讲座，查看预约名单，用户展示预约码，管理员扫码核销，最后回名单页确认已签到。

录之前做三件事：把开发者工具的模拟器字体调大，方便老师看清；把系统通知关掉，避免微信消息弹出打断；用一台真机做演示，模拟器里的云调用环境和真机有差异，真机跑通才算稳定。录像里出错不要停，继续操作然后口头解释「这里权限配置我稍后展示」，比反复重录更显真实。

5.3 答辩被追问的 5 个高频问题

问题一：为什么用云开发不用传统后端？回答要点：数据量小、开发周期短、免运维，云函数写法和 Node.js 一致，业务逻辑没有缩水。问题二：并发预约怎么防止超卖？回答要点：事务保证读改一致，预约和名额更新在同一事务内完成，_.inc原子自增双保险。问题三：数据库权限怎么设计的？回答要点：讲座读取开放，写入走云函数，管理员用独立集合校验，预约记录按 openid 归属。问题四：用户身份怎么确认？回答要点：openid 是微信登录态下的唯一标识，学号只是补充绑定信息。问题五：如果用户量变大怎么办？回答要点：云开发自动扩容，数据库关键字段加索引，云函数调用走配额，足够支撑校园级并发。

这五个问题回答时不要背稿，用自己的话把事务和 openid 讲清楚，老师基本不会再往下深挖。

6. 三个不费力但加分的进阶能力

核心链路跑通后，还有几个工作量不大但能明显提升完成度的能力，适合在答辩前最后阶段加上。第一个是定时关闭过期讲座。在 closeLecture 云函数目录的 config.json 里配置定时触发器，让云函数每隔十分钟自动跑一次，把 startTime 早于当前时间且仍处于 open 状态的讲座改成 closed：

{ "triggers": [ { "name": "closeLectureTimer", "type": "timer", "config": "0 */10 * * * * *" } ] }

这个 cron 表达式是七位的，前六位是秒、分、时、日、月、星期，最后一位是年。0 */10 * * * * *表示每分钟的第 0 秒触发一次，每 10 分钟执行一轮。写错位数会导致触发器不生效，这是云开发定时器和 Linux crontab 最大的区别。

第二个是学号绑定。用户首次登录时 openid 已经写入，但学号是空的。可以在「我的」页面加一个绑定入口，用户输入学号后由云函数更新 users 集合，管理员导出名单时就能显示学号和院系。第三个是预约成功后的订阅消息通知，需要在小程序后台申请订阅消息模板，用户点击预约时弹出授权，授权通过后云函数调用cloud.openapi.subscribeMessage.send推送讲座提醒，这是演示录像里最显「项目完整度」的功能。

我自己的习惯是每次交毕设之前都把数据库里的讲座时间调成未来一小时，然后用一台手机把整个流程完整走一遍——预约、取消、重约、核销，中间不弹错、不超时，才敢开始录演示录像。这个习惯救过我两次，一次是发现云函数超时没调，一次是发现取消后名额没释放。最后说一句，做完这个系统，你能讲的不只是「我写了一个小程序」，而是「我设计了一个有状态流转、有并发控制、有权限边界的完整业务系统」，这比代码本身更值钱。希望帮到你。

本文还有配套的精品资源，点击获取