ARTICLE DETAIL

资讯详情

深耕网站建设与运营推广的一线实战洞察。

微信小程序考试报名系统毕设开发全攻略:从Spring Boot后端到数据库设计

微信小程序考试报名系统毕设开发全攻略:从Spring Boot后端到数据库设计 又到了一年一度的毕业设计开题季。每年这个时候总有学弟学妹来问我“小程序方向的毕设到底怎么做感觉网上教程一堆但真正要落地一套考试报名系统又无从下手。”说实话基于微信小程序的考试信息报名系统确实是近几年计算机专业毕业设计里性价比很高的选题——它既不像纯管理系统那样枯燥又不像电商平台那样业务复杂核心流程清晰、技术栈主流、演示效果好非常适合作为本科阶段的综合训练。这篇博文我就把这套系统的完整设计思路、关键代码实现和我在实际开发中踩过的坑一次性讲清楚想选这个题或者正在做这个题的同学可以直接对照着落地。1. 选题定位与整体方案设计1.1 明确定位这套系统到底解决什么问题考试信息报名系统的本质是把“考试通知发布—考生浏览查询—在线填写报名—后台审核管理”这条传统线下流程搬到微信生态里。听起来简单但真正设计时要考虑的东西比想象中多得多——用户角色如何区分、考试名额如何控制、重复报名怎么拦截、审核状态如何流转、数据怎么导出统计。这些业务问题是评审老师关注的重点也是拉开分数差距的地方。先给这套系统定个清晰的产品定位它面向两类用户一类是考生C端通过微信小程序完成注册登录、浏览考试公告、选择考试项目、填写报名信息、查看审核结果另一类是管理员B端负责维护考试信息、处理报名申请、统计报名数据、发布系统公告。常见的毕设还会加一个“超级管理员”角色用来管理普通管理员但如果时间和精力有限一个管理员角色完全够用角色体系过度设计反而容易在答辩时被追问。从功能边界上看这套系统的核心闭环是“发布考试 → 考生报名 → 管理员审核 → 结果反馈”。我建议把业务范围严格锁定在这个闭环内不要贪多比如支付功能、准考证打印功能如果指导老师没有明确要求放在“扩展功能”里说明即可。原因很简单毕设答辩时间通常只有10分钟把主流程做透、做出亮点远比铺一堆半成品功能更有价值。1.2 技术方案怎么选原生小程序还是uni-app后端用什么这是同学们问得最多的一个问题。在微信小程序的搜索热词里“uniapp开发微信小程序”和“微信小程序项目实例”一直热度很高这说明很多人纠结于前端技术路线的选择。我的建议比较直接如果这个毕设不只是“做完就行”而是希望代码结构清楚、后续还能扩展优先考虑原生微信小程序开发。原生框架的组件体系和调试工具最成熟WXML WXSS JS 的结构也最容易向答辩老师解释清楚。而 uni-app 的优势是一套代码多端复用适合你未来有 H5 或 App 发布需求的情况但代价是某些微信原生能力需要条件编译处理反而增加排查成本。后端技术栈我推荐 Spring Boot MyBatis Plus MySQL搭配 Maven 做依赖管理。说实话这套组合在国内高校的项目实践里占有率极高网上资料丰富遇到问题基本都能搜到现成方案。Spring Boot 自带内嵌 Tomcat部署时一个 jar 包直接跑起来比传统的 SSH 框架省太多事。MyBatis Plus 把单表 CRUD 的代码省略到极致可以把更多精力放在业务逻辑设计上。这里要特别回答一个高频问题为什么不用微信云开发云开发确实把后端、数据库、存储都托管了开发效率极高但有个实际风险——评审老师可能会问“你如何保证数据安全性”“数据库索引怎么设计”“事务怎么处理”云开发把这些底层能力都封装好了你反而回答不上来。毕设的本质是展示你对完整软件工程流程的掌握自己写一套 Spring Boot 后端哪怕代码不够优雅至少整个数据流和业务逻辑是你亲手控制的。2. 系统功能拆解与数据库设计2.1 双端功能清单与角色权限划分在设计功能模块之前先把用户角色和权限边界搞清楚。这套系统需要三种角色考生、管理员、超级管理员。考生能做的事全部集中在微信小程序端包括微信授权登录、浏览通知公告、查看考试列表与详情、在线填写报名信息、查看个人报名记录和审核状态。管理员在管理后台维护考试信息新增、编辑、上下架、审核报名记录、导出报名名单同时管理考生账号状态。具体功能清单可以这样列小程序端微信登录授权、考试分类浏览、考试详情查看、报名表单填写与提交、我的报名记录、审核状态查询。管理端管理员登录、考试信息管理增删改查与上下架、报名审核通过/驳回、报名数据导出Excel、公告管理、基础数据统计。这里有一个容易忽略的设计点考试审核状态流转。报名记录的状态我用四个枚举值表示待审核、已通过、已驳回、已取消。考生在前端只能看到“待审核/已通过/已驳回”管理员在后端可以把“待审核”改为“已通过”或“已驳回”考生自己只能取消“待审核”状态的报名。状态机的设计虽然简单但能让业务流程非常清晰写代码和答辩都有据可依。2.2 数据库表设计与关键字段说明数据库设计是毕业设计评审的重点环节。这套系统的最小表集合是四张表用户表、考试表、报名表、公告表。我给每张表补充了核心字段方便你直接参考建表。用户表sys_user的关键字段包括id、openid微信唯一标识、nickname、avatar、real_name、id_card、phone、role0考生/1管理员/2超级管理员、status0正常/1禁用、create_time。其中 openid 必须加唯一索引这是登录鉴权的基础。real_name、id_card、phone 这些字段是在用户首次报名时补充的所以要用可空字段设计。考试表exam_info的核心字段有id、title、category、exam_date、exam_time、location、total_quota总名额、remaining_quota剩余名额、registration_start、registration_end、description、status0未发布/1已发布/2已结束、create_time。这里的名额设计是后续并发控制的基础后面我会专门讲。报名表exam_registration包含id、user_id、exam_id、registration_time、status0待审核/1通过/2驳回/3取消、remark审核备注。重点来了user_id 和 exam_id 必须建立联合唯一索引这是防止同一考生重复报名同一场考试的最底层防线比任何业务判断都可靠。公告表sys_notice相对简单id、title、content、create_time、status。公告主要解决“考试信息变更如何通知到考生”的问题前端做一个轮询或者页面加载时拉取最新公告列表即可。3. 小程序前端开发实录3.1 登录授权与用户身份绑定微信小程序登录的完整流程是前端调用 wx.login 获取临时 code把 code 发送到后端后端调用微信的 code2Session 接口换取 openid 和 session_key后端用 openid 去用户表查记录如果不存在就自动注册一个新用户存在则直接返回业务 token前端把 token 存进本地缓存后续所有请求都带上这个 token。在实际开发中有个非常容易踩的坑直接在页面的 onLoad 里调用 wx.login但如果用户拒绝授权或者网络异常整个流程就卡死了。我的做法是把登录逻辑封装成 Promise在 app.js 的 onLaunch 里调用并且做一层“登录态缓存判断”——如果本地已有 token 且没有过期直接跳过登录流程。// utils/auth.js function login() { return new Promise((resolve, reject) { wx.login({ success: (res) { if (res.code) { wx.request({ url: ${baseURL}/user/login, method: POST, data: { code: res.code }, success: (resp) { if (resp.data.code 200) { wx.setStorageSync(token, resp.data.data.token) resolve(resp.data.data) } else { reject(new Error(登录失败)) } }, fail: reject }) } else { reject(new Error(获取code失败)) } }, fail: reject }) }) }关于“新版头像昵称填写能力”需要提一句微信从某个基础库版本开始收紧了 getUserProfile 的调用权限直接弹窗获取用户头像昵称的方式已经被调整。现在比较稳妥的做法是让用户在小程序内自己填写昵称、选择头像或者干脆不在登录阶段采集头像昵称等用户报名时再采集真实姓名和身份证号。毕设阶段登录只需要 openid 建立账号映射即可姓名身份证在报名表单里收集这样避免了很多不必要的麻烦。3.2 考试列表与报名表单实现细节考试列表页是小程序端的核心页面。我的做法是用一个首页承载考试分类 tab 和考试卡片列表考试卡片展示标题、时间、地点、剩余名额和报名截止时间四要素。这里有一个交互细节值得注意剩余名额为 0 时卡片上的“立即报名”按钮要置灰且点击无效不能让用户进了详情页才看到名额已满否则体验很差。报名表单是另一个容易出问题的地方。考试报名的核心要填的信息一般是考生真实姓名、身份证号、手机号、所在单位或学校、报考科目如果考试包含多个科目这里用单选框组件实现。身份证号要做格式校验手机号要做 11 位校验这些前端校验逻辑写清楚一方面减少无效数据进入后端另一方面也是毕设代码里的一个小亮点。单选框在小程序里直接使用 radio-group 和 radio 组件但要注意 radio 的 label 关联写法让用户点击整个选项区域都能触发选中而不是只能点那个小圆圈。日期选择器使用 picker 组件modedate但要注意一个难点微信小程序的 picker 返回的是字符串格式的日期如果你要比较“报名截止日期”建议统一用时间戳比较避免字符串比较带来的格式问题。3.3 请求封装与全局配置小程序的 wx.request 是回调风格的写起来很容易陷入“回调地狱”。我的做法是把请求封装成 Promise统一处理 token 注入、HTTP 状态码和业务状态码并且对 401 场景做全局处理——token 过期时自动重新登录并重发原请求。这个封装不仅是开发体验的提升在答辩时也可以作为一个“系统设计亮点”讲出来。关于“微信小程序顶部导航栏高度”这个热点词我多说一句很多同学做列表页时希望导航栏和状态栏颜色统一实际开发中经常遇到 iPhone 刘海屏和 Android 状态栏高度不一致导致布局错位的问题。最简单的方案是用 wx.getSystemInfo 获取 statusBarHeight再用 wx.getMenuButtonBoundingClientRect 获取菜单按钮位置动态计算导航栏高度而不是硬编码一个数值。// app.js 中动态计算导航栏高度 const systemInfo wx.getSystemInfoSync() const menuButton wx.getMenuButtonBoundingClientRect() this.globalData.statusBarHeight systemInfo.statusBarHeight this.globalData.navBarHeight menuButton.height (menuButton.top - systemInfo.statusBarHeight) * 2另外还遇到过一个问题小程序开发时默认的 request 合法域名校验非常烦人。开发阶段可以在开发者工具里勾选“不校验合法域名”但真机预览时没法用这个选项。我的建议是直接申请一个 HTTPS 域名或者用本地局域网 IP 关闭域名校验的方式联调但一定要记住https://协议是必须的这是微信的硬性要求。还有一个冷知识是 request 的并发上限是 10 个如果页面同时发起太多请求会出现莫名失败的诡异现象封装请求时最好加一个简单的请求队列控制。4. 后端接口设计与业务逻辑实现4.1 RESTful 接口设计与统一返回结构后端接口设计有一套约定俗成的规范用 RESTful 风格把资源路径和 HTTP 方法对应起来。核心接口如下功能点请求方式接口路径说明登录换tokenPOST/api/user/login通过微信code换取openid并生成token获取考试列表GET/api/exam/list分页查询已发布的考试获取考试详情GET/api/exam/{id}考试详情剩余名额提交报名POST/api/registration提交考试报名申请查询我的报名GET/api/registration/my当前用户的报名记录取消报名PUT/api/registration/cancel/{id}仅待审核状态可取消管理员审核PUT/api/registration/review通过/驳回备注原因每个接口的返回值都使用统一的 Result 结构包含 code200成功/400业务失败/401未登录/500系统错误、message提示信息、data业务数据。这个结构是后端最重要的“门面”全程统一会让前后端联调顺畅很多。4.2 报名事务与防止超卖的核心逻辑这套系统里最有含金量的业务逻辑是考试名额的控制。假设一个考试就剩最后一个名额两个考生同时点击报名如果没有并发控制两人都会显示报名成功但名额已经超了。这个问题的本质和电商秒杀超卖是一样的解决办法主要有三种数据库悲观锁SELECT FOR UPDATE、数据库乐观锁版本号/剩余名额条件更新、Redis 分布式锁。毕设系统一般还没到上 Redis 的规模我推荐用“数据库乐观锁 事务”的组合。具体做法是报名操作放在一个事务里先检查报名记录是否已存在依赖联合唯一索引兜底然后用条件更新语句扣减剩余名额Transactional public Result submitRegistration(RegistrationDTO dto) { // 1. 检查考试是否存在且已发布 ExamInfo exam examMapper.selectById(dto.getExamId()); if (exam null || exam.getStatus() ! 1) { return Result.error(考试不存在或未发布); } // 2. 检查是否在报名时间内 // 3. 条件更新扣减剩余名额remaining_quota 0 作为乐观锁条件 int updateCount examMapper.reduceQuota(dto.getExamId()); if (updateCount 0) { throw new ServiceException(名额已满); } // 4. 插入报名记录依赖联合唯一索引防止重复报名 // 5. 如果插入重复捕获异常并回滚名额扣减 }这里最关键的是第 3 步UPDATE exam_info SET remaining_quota remaining_quota - 1 WHERE id ? AND remaining_quota 0如果影响行数为 0说明名额已经没了直接抛异常回滚这比先 SELECT 再 UPDATE 要安全得多。联合唯一索引则保证同一个 user_id 和 exam_id 只能出现一条报名记录数据库层面把重复报名彻底堵死。这个方案虽然简洁但能挡住绝大多数并发问题放到毕设里已经属于非常亮眼的设计。面试或答辩时常会追问一个问题“为什么不用 SELECT FOR UPDATE”我的回答思路悲观锁在数据库层面锁行并发量高时容易造成锁等待而且需要放到事务里事务范围控制不好还会带来长事务问题。乐观锁用版本号或条件更新适合这种“写多读多但单次操作快”的场景。你可以只答“我用的是条件更新 唯一索引”再解释一句“适合毕设这个量级的并发场景”就已经很完整了。4.3 管理员端的数据统计与导出管理端是容易显得“功能单薄”的部分建议在统计和导出上适当加料。管理员首页可以做一个简单的仪表盘总考试数、总报名数、待审核数、今日新增报名。报名记录列表要支持按考试筛选、按状态筛选并且提供导出 Excel 功能。Excel 导出不用引入太重的依赖用 Apache POI 的简单 API 就能实现。导出时要注意一个细节报名表里存储的是 user_id导出时必须 JOIN 用户表把真实姓名、身份证号、手机号带出来。我见过不少同学导出时只导出 id 列表被老师当场质疑数据可用性这种低级错误真的不要犯。5. 毕设中的高频问题与排查技巧实录5.1 真机调试与网络请求的常见故障我在做这个项目的过程中遇到最多的不是业务逻辑问题而是微信环境特有的坑。第一个是“网络请求失败”问题尤其是 iOS 机型上失败率明显更高。排查思路从这几个维度入手确认用的是 HTTPS 域名、确认 TLS 版本在 1.2 以上、确认证书链完整、确认没有使用自签名证书。很多同学在开发阶段手动点了“不校验域名”就忽略了证书问题一到真机就暴露尤其是 Android 手机频繁出现 certificate verify failed八成是证书链问题。另外还遇到过一个冷门情况同一个域名在 iOS 上请求间歇性失败后来排查发现是请求并发数超过了微信的限制客户端并发请求太多导致超时。第二个常见问题是 wx.setStorageSync 缓存数据过期导致页面数据错乱。微信小程序的缓存没有内置的自动过期机制但考试报名系统里考试列表、公告这类变化频率低的数据非常适合做缓存我建议自己封装一个带过期时间的缓存工具。约定好 key 的命名规范数据 key 加前缀防止和登录 token 混淆这也是一个很好的代码规范加分项。5.2 表单与组件使用中的细节坑小程序端有一个坑让我印象特别深在表单里使用 picker 做日期选择时如果把 start 和 end 参数绑定到 data 中的字段一定要用“YYYY-MM-DD”格式字符串如果后端返回的是时间戳前端要先格式化成日期字符串再传给 picker否则组件会异常。人体工学角度线上。这类“格式问题”是最容易让新手浪费一下午的我的建议是前端所有日期交互都统一用日期字符串只有传给后端做比较时才转成时间戳。另外报名表单页面的键盘弹起问题也值得注意。在 iPhone 上如果页面上有多个 input键盘弹起会遮挡下面的输入框用户输入体验很差。解决办法是给页面配置disableScroll: true同时监听键盘高度动态调整输入框位置或者干脆把报名表单做成多个独立的短页面一页只填一项信息虽然开发量稍大但用户体验好得多。毕设答辩演示时这个细节会让老师觉得你是真做过产品的而非只是在跑 demo。5.3 答辩演示的准备重点到了答辩阶段很多同学只顾着讲代码忽略了演示流程这是很可惜的。我的建议是准备好一份“演示脚本”按这个顺序走先展示小程序端首页和考试列表 → 演示报名流程重点展示名额扣减和审核状态变化→ 切到管理后台审核通过 → 回到小程序端看到状态更新 → 最后打开数据统计页面展示报名数据。演示时主动讲出“这里我用了数据库唯一索引防止重复报名”“这里我用条件更新解决名额超卖”这些设计点给老师留出追问空间。老师通常对“用户密码怎么加密”“怎么防止 SQL 注入”“接口怎么验权”这类问题感兴趣提前准备好答案基本就稳了。写在最后的经验分享这套系统做完之后我个人感触最深的一点是毕业设计真正考察的不是你用了多新的技术而是你有没有把一个完整业务闭环做到逻辑自洽。考试信息报名系统麻雀虽小五脏俱全小程序端、后端、数据库三层紧扣从微信登录到报名审核再到名额控制每个环节都有值得展开的设计细节。你把这套系统的完整链路吃透哪怕只是照着本文的思路落地一版答辩和后续的工作面试都够用了。最后再分享一个小技巧如果你时间充裕给报名审核加一个微信订阅消息通知审核结果直接推送到考生微信这个小亮点在答辩时非常加分而且微信开发者平台申请订阅消息模板也不复杂值得一试。
返回列表