最近有个准备做毕设的同学拿了一套“SpringBoot基于微信小程序的四六级小助手系统”源码来问我说想看懂、想跑通、还想跟导师讲清楚里面到底做了些什么。这类小系统在毕业设计选题里非常常见技术栈不复杂但麻雀虽小五脏俱全——SpringBoot 负责后端接口微信小程序负责前端页面再把单词、真题、错题、模拟考试这些学习场景串起来就是一个很典型的全栈实战项目。我花了两个晚上把整套代码从头到尾过了一遍跑通了数据库、后端和小程序三端也踩了几个不大不小的坑。这篇就顺着项目拆解、架构设计、功能实现、部署排错这几个角度把“四六级小助手系统”讲透。不管你是想拿它做毕设还是单纯想学 SpringBoot 小程序怎么配合这篇都能给你一个明确的下手路径。1. 项目拆解这套四六级小助手到底做了什么1.1 一句话说清系统定位“四六级小助手系统”本质上是一个面向大学生、CET-4/CET-6 备考场景的轻量级学习工具。它前端跑在微信小程序里用户打开就能用不需要下载 App也不用单独注册账号后端跑在 SpringBoot 服务上负责所有业务逻辑和数据存取。它能做的事用大白话讲就是三个背单词、刷真题、看学习记录。你再往细里拆还能拆出每日单词打卡、乱序测试、模拟试卷、自动判分、错题本、练习记录、积分排行这些常见功能点。这些功能听着多但落到代码层面其实都是“用户 题库 记录”三张核心数据在流转。标题里的 LW在毕设语境下一般指“论文文档”包含需求分析、数据库设计、功能设计这些章节。整套资源也就是拿到手之后有源码、有文档、有部署说明能让你从 0 到 1 把系统跑起来并且能跟老师讲明白每一步为什么这么做。1.2 为什么选 SpringBoot 微信小程序而不是纯网页很多人在选题时会犹豫同样一套学习系统为什么不做成 Vue 网页或者直接用 Android这背后的选型逻辑其实很值得掰扯一下。首先是使用场景。四六级备考是典型的碎片化场景学生在自习室、食堂排队、晚上睡觉前都可能刷几道题。微信小程序不用安装打开即用用完就关学习记录自动同步这种“低门槛、高频次”的模式比打开电脑访问网页要舒服很多。其次是开发成本。如果做纯网页你自己得搞定浏览器适配和手机端响应式布局如果做原生 App光打包、上架、审核这一套流程就能耗掉大半个月。而微信小程序天然自带账号体系不需要开发者自己做验证码注册、找回密码那一套后端只需要对接微信登录省下的工作量非常可观。我整理了一个选型对比表格大家可以直观感受一下对比项纯网页Vue/React微信小程序原生 App (Android)开发门槛中需要搞定移动端适配低官方开发工具开箱即用高需要掌握原生语言和打包发布账号体系自己实现注册登录微信授权省心第三方登录需自己集成用户触达要自己拉流量微信生态内传播需下载安装流失率较高适合场景后台管理、PC 用户学生、碎片化学习高频重型应用毕设难度中等中等偏易答辩亮点好做较高工期风险大对毕业设计而言选 SpringBoot 微信小程序还有一个隐藏优势它同时覆盖了“后端开发”和“移动端开发”两个方向答辩时能讲的东西非常丰富。你既可以说自己设计了 RESTful API也可以说你解决了小程序体验优化问题还能讲一讲数据表关系如何支撑业务。相比纯后端管理系统的选题这类项目的技术广度和可展示性都要强不少。2. 系统架构与核心设计思路2.1 前后端分离下的整体数据流这套系统的整体结构是标准的前后端分离模式我建议你在看代码之前先把下面这条数据流在脑子里过一遍小程序端发起请求 → 微信服务器换取用户身份 → 后端 SpringBoot 接收请求 → 业务层处理逻辑 → 数据层访问 MySQL → 返回统一 JSON → 小程序渲染页面换句话说小程序不直接连接数据库所有数据查询都走后端接口。比如用户想查看今天的背单词计划前端就调/api/word/plan这个接口后端查 word 表把今天该学的单词列表返回给前端前端再用 WXML 渲染出来。在这个架构下后端接口起着“中间层”的作用一是隐藏数据库结构不暴露敏感字段二是把业务逻辑集中管理不管以后小程序改版还是新增管理后台接口可以复用三是在接口层做参数校验和权限控制避免非法请求直接打到数据库上。如果你打开源码一般会在src/main/java下面看到controller、service、mapper三层结构。这是最常见的 SpringBoot 分层方式controller 接收参数并返回结果service 写业务规则mapper 操作数据库。相当于饭店里的服务员负责传菜厨师负责做菜采购员负责买菜各管一摊出问题也好定位。2.2 数据库表结构设计要点数据库是一套项目的命脉我挑几张三、草核心表给大家拆一下。实际项目里表名可能不同但思路都是一样的。用户表user字段类型说明idbigint主键openidvarchar(64)微信唯一标识nicknamevarchar(50)昵称avatarvarchar(255)头像gendertinyint性别study_daysint连续学习天数total_scoreint当前个人积分create_timedatetime注册时间单词表word是四六级系统的核心资产。通常字段有id、word、translate、phonetic、example、category四级/六级还可以加word_type用于标识名词、动词、形容词等。有些项目还会做“词根词缀”字段方便扩展。做题记录表exam_record承担着统计职责。它要记录用户某一次刷题用了哪套试卷、答了多少题、对了几题、花费多少秒字段一般有record_id、user_id、paper_id、question_count、correct_count、duration、create_time。这张表是判断用户学习效果的主要依据也是后面做错题本和排行榜的数据来源。答错题汇总表wrong_book设计上有一些讲究。最简单的设计就是记录user_id和question_id再加一个wrong_count统计错误次数以及last_wrong_time记录最近一次做错的时间。这样既能做去重又能按错误次数给用户推复习优先级。这里我要特别提醒一个新手容易犯的错不要把错题本设计成“用户答错一次就插入一条记录”那会导致同一个题目在表里出现很多条。正确思路是当用户做错时先去查这张表有没有相同 user_id question_id 的记录有就让错误次数加一没有才插入新记录。2.3 小程序页面结构与自定义导航栏适配再来看小程序端的页面组织。四六级小助手一般会有这几个主要页面首页、背单词页、刷题页、我的页面。如果你用原生小程序开发常见的目录结构是这样pages/ ├── index/ # 首页展示学习进度和今日推荐 ├── word/ # 单词学习与打卡 ├── exam/ # 真题练习与模拟考试 ├── wrong/ # 错题本 └── user/ # 个人中心、登录、排行这种 tabBar 结构在交互上最稳用户一进来就知道该在哪里点。“微信小程序顶部导航栏高度”是大家绕不开的适配问题尤其做自定义导航栏时。原生导航栏没法改背景色也没法塞自定义组件所以很多项目都选择自定义导航栏。但自定义导航栏需要自己算状态栏高度和胶囊按钮位置我贴一段常用代码const getNavBarInfo () { const menu wx.getMenuButtonBoundingClientRect() const systemInfo wx.getSystemInfoSync() const statusBarHeight systemInfo.statusBarHeight const navBarHeight (menu.top - statusBarHeight) * 2 menu.height return { statusBarHeight, navBarHeight, menu } }这段代码的原理很直接状态栏高度就是手机系统顶部那条信号时间电池栏的高度胶囊按钮右上角那三个点是微信固定的所以通过getMenuButtonBoundingClientRect()拿到的胶囊位置就能反推自定义导航栏应该占多高、文字应该垂直居中到什么位置。这个方法在 Android 和 iOS 上兼容性都很好做自定义导航栏时直接抄这一段就够用。3. 核心功能模块的实现思路3.1 背单词模块词库、学习计划与打卡逻辑背单词功能是整个系统里最能体现产品设计能力的模块技术上却比较简单。核心就是控制好“词库来源”和“学习节奏”。词库来源一般是两种一种是开发阶段手动维护把四级大纲词汇、六级大纲词汇整理成 SQL 文件通过INSERT INTO word批量导入另一种是后台预留管理功能管理员通过页面上传 Excel后端解析后批量写入。我建议初学阶段先用手动 SQL 导入的方式简单直接不会因为文件解析问题卡住整个项目。学习计划逻辑一般围绕“每日新词数量 复习数量”来做。比如用户设置每天新学 20 个词那么后端查询时会按“用户今天还没学过的单词优先 之前学过但已超过复习间隔的单词”这两个条件拉数据。你可以提前在 service 层做一个查询方法核心 SQL 大致长这样SELECT * FROM word WHERE category 四级 AND id NOT IN (SELECT word_id FROM word_study_record WHERE user_id 1) LIMIT 20打卡逻辑的核心是“当天首次学习即算打卡成功”后端通过查询word_study_record中是否存在当天的记录来判断。打卡数据再拿去更新用户表的study_days和积分表这样积分排行也就有了数据来源。3.2 刷题与模拟考试题库结构、判分逻辑与计时刷题模块的设计难点在于题目类型的区分。四六级真题题型有听力、阅读、翻译、写作。听力题和阅读题属于客观题选项固定答案固定比较适合自动判分翻译和写作是主观题系统只能记录用户写的答案让用户自己对照参考答案判分严格说没办法做到完全智能评判。题库表question的关键字段包括paper_id、question_type、content、option_a、option_b、option_c、option_d、answer、analysis、score。客观题的答案字段存一个大写字母比如“C”判分时拿用户提交的答案和它做字符串匹配就可以。模拟考试功能在实现时需要一个“随机出题”的算法。比较常见的做法是后端在用户点击“开始考试”时从题库里按题型随机抽取若干题比如听力 10 题、阅读 10 题拼成一份临时试卷。这里我建议把临时试卷存到一张user_paper表而不是每次提交答案时再临时拼这样即使用户中途退出重新进入也还能恢复上次的答题内容。计时功能要分为前端计时和后端计时。前端计时能展示一个倒计时提示用户后端计时则用于判断超时比如考试超过 40 分钟自动交卷。在作答记录表里统一保存start_time和submit_time后续做学习效率分析时才有可靠的数据。3.3 错题本去重、错误次数与薄弱项统计错题本不是简单的“把错题列出来”它的价值在于“基于错题数据做分析”。所以我建议你在实现时不止要存题目 ID还要存错误次数和知识点标签。举个例子某一道阅读题做错以后记录里能知道它属于“细节理解题”还是“主旨大意题”。当错题本里某类题型的错误次数明显偏高系统就可以在首页提示用户“你的阅读理解主旨题正确率偏低建议加强练习”。这个逻辑用 SQL 就能实现以wrong_question_type分组统计 count 排序即可不需要复杂的算法。在做错题本功能时还有一个容易被忽略的细节用户第一次做错第二次做对了这道题应该从错题本里移除还是保留我的建议是保留但把状态标记为“已掌握”并保留历史错误次数。因为用户可能只是蒙对了保留错误记录有助于周期性复习。当错误次数达到阈值并且连续做对三次才真正从错题本移除。3.4 用户体系与积分排行激励用户连续学习做学习类小程序光有功能还不够还得有激励手段。这套系统常见的做法是积分 排行。用户签到得积分、背完单词得积分、正确率达到 80% 以上额外得积分这些积分汇总到排行榜上营造一种“和同学比着学”的氛围。积分表设计一般有score_id、user_id、type、score、create_time。type 字段标识积分来源比如 1 代表签到2 代表每日任务3 代表模拟考试。显示排行榜时后端对 user 表按total_score排序取前 20 名即可。这里有一个交互层面的小技巧排行榜不应该只展示前 20 名还需要把当前用户自己的排名也显示出来。不然用户发现自己不在榜单上很容易失去参与感。实现方式可以先用 SQL 取出所有用户积分排序的列表再在 Java 代码里二分查找或循环比对出当前用户的排名。4. 前后端对接中的关键细节4.1 微信登录流程与 Token 会话管理微信小程序登录是整套系统第一步要打通的环节。很多新手会误以为“小程序里拿到了用户昵称头像就叫登录”实际上真正的登录逻辑是这样的小程序端调用wx.login()微信返回一个临时code。小程序把code发给 SpringBoot 后端后端拿着code、小程序的 AppID 和 AppSecret 去请求微信的jscode2session接口换取openid。这个openid才是用户在当前小程序里的唯一身份标识。后端拿到openid后先查用户表如果已经存在就直接登录成功如果不存在就自动创建一个新用户。随后生成一个自定义 token可以用 UUID 或 JWT返回给前端前端把 token 存起来之后的请求都带上这个 token后端通过 token 识别当前用户。下面这段是后端处理登录的伪代码核心流程一目了然PostMapping(/login) public Result login(RequestBody LoginDTO dto) { // 1. 用 code 换 openid String openid wxService.code2Session(dto.getCode()); // 2. 查询或创建用户 User user userService.findOrCreate(openid); // 3. 生成 token 并缓存 String token UUID.randomUUID().toString().replace(-, ); // 4. 返回前端 return Result.success(token); }登录状态管理的坑在于 token 有效期。我不建议把 token 设置得太长比如永久有效或 30 天有效这会埋安全隐患也不建议设置太短用户可能正背到一半就要重新登录。比较合理的设置是 7 天有效用户 7 天内打开小程序不用重复登录超过 7 天再去请求接口时后端返回 401前端引导用户重新登录。4.2 小程序请求封装统一入口、错误提示与登录态刷新小程序原生wx.request用起来很原始每个页面都要写一遍 success、fail 等回调代码会非常冗长。我强烈建议在开发前就封装好一个request.js把所有公共逻辑集中管理比如 baseUrl 拼接、请求头 token、统一错误码处理、加载动画控制等。下面是一个比较实用的请求封装模板const request (url, method GET, data {}) { return new Promise((resolve, reject) { wx.request({ url: getApp().globalData.baseUrl url, method, data, header: { Content-Type: application/json, token: wx.getStorageSync(token) || }, success: (res) { if (res.data res.data.code 200) { resolve(res.data.data) } else if (res.data res.data.code 401) { wx.removeStorageSync(token) wx.navigateTo({ url: /pages/login/login }) reject(res.data) } else { wx.showToast({ title: res.data.message, icon: none }) reject(res.data) } }, fail: (err) { wx.showToast({ title: 网络异常请稍后重试, icon: none }) reject(err) } }) }) }封装完成以后页面里的调用就变得非常清爽。比如获取单词列表const list await request(/api/word/list, GET, { category: 四级 })这套封装的思路并不复杂但它能解决很多纯新手项目里“每个页面都在重复处理错误提示、登录失效”的混乱问题。做到前后端返回格式统一前端一行if (res.data.code 200)就能判断请求是否成功维护性会大幅提升。4.3 SpringBoot 接口设计统一返回体、参数校验与跨域后端接口设计有没有章法直接决定前端对接能不能顺利推进。我见过很多毕设项目的接口返回特别随意有的接口返回 true/false有的返回字符串有的直接把整个实体对象丢出去前端对接时写一堆判断容易出 bug。规范的做法是设计一个统一的返回体类比如ResultT包括三个字段code、message、data。成功时 code 为 200业务失败时 code 为 400 或 500登录失效是 401。前端拿到响应后只看 code 就能知道请求结果不用关心 data 里到底返回了什么。public class ResultT { private Integer code; private String message; private T data; public static T ResultT success(T data) { ResultT result new Result(); result.setCode(200); result.setMessage(success); result.setData(data); return result; } }参数校验这块也不要依赖前端后端要做二次防御。比如用户提交的答题参数里questionId为空或者answer不是 A/B/C/D 中的一种后端应该在 service 层或通过注解直接拦截。使用 SpringBoot 自带的Validated加 DTO 上的NotBlank、NotNull注解就能省掉一大部分手工判断。跨域问题主要在开发阶段出现。小程序请求后端不涉及浏览器跨域但如果你单独做了一个后台管理页面或者用 Swagger 在线调试跨域就会冒出来。后端增加一个全局跨域配置类允许所有来源访问开发时能少掉很多无谓的阻碍。5. 从源码到跑通搭建与部署全流程5.1 本地开发环境准备清单拿到源码以后第一步别急着跑先检查环境。SpringBoot 项目的运行环境比较固定我列出需要准备的清单组件版本建议用途JDK1.8 或 11运行 SpringBootMaven3.6依赖管理MySQL5.7 或 8.0数据存储IntelliJ IDEA2020导入和运行项目微信开发者工具最新稳定版运行小程序Node.js可选个别构建工具需要这里有个容易掉坑的地方SpringBoot 版本和 JDK 版本的匹配。如果项目用的是 SpringBoot 2.7而你本地装的是 JDK 17启动时大概率会报 CGLIB 或反射相关的异常。遇到这种问题最省事的办法是安装 JDK 8 或者 11并把 IDEA 里项目的 SDK 切换过去不要上来就折腾升级 SpringBoot 版本。5.2 后端启动三步曲建库、改配置、启动主类后端启动的完整流程可以压缩成三步。第一步建库。拿到项目以后先在源码目录里找 SQL 文件常见文件名是cet_helper.sql或者database.sql。打开 MySQL 客户端执行CREATE DATABASE cet_helper DEFAULT CHARACTER SET utf8mb4;然后把 SQL 文件导入mysql -u root -p cet_helper cet_helper.sql导入完成后用 Navicat 或命令行检查一下表数量确认至少有用户、单词、试卷、题目这几张核心表再往下走。第二步改配置。打开src/main/resources/application.yml把数据库连接信息改成你自己本地的账号密码。我截取一段典型的配置spring: datasource: url: jdbc:mysql://localhost:3306/cet_helper?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai username: root password: 123456 driver-class-name: com.mysql.cj.jdbc.Driver特别提醒serverTimezone参数不要漏不加的话 MySQL 8.0 以上版本经常会报时区错误。如果你用的是 MySQL 5.7可以保留也可以去掉不影响核心流程。第三步启动。在 IDEA 里找到带有SpringBootApplication注解的主类右键 Run。启动日志里看到 “Started Application in xxxx seconds” 就说明后端已经起来了。此时可以访问http://localhost:8080/api/health这类接口测一下通没通通常会返回一个 JSON 对象。5.3 小程序端配置与真机调试注意事项后端跑通以后把小程序源码导入微信开发者工具。第一件要做的事是改 AppID。如果你的源码里用的是别人的 AppID直接预览会提示没有权限需要换成自己注册的小程序 AppID使用测试号也可以。第二件事是改后端地址。开发者工具本地调试时默认可以使用http://localhost:8080但要注意两点一是微信开发者工具需要勾选“不校验合法域名”因为本地调试的域名没有备案也没有配置到后台白名单二是真机预览时手机不能通过localhost访问电脑上的后端这里有两种解决办法方法步骤适用场景电脑开热点将手机和电脑连同一局域网后端地址改成电脑局域网 IP例如 http://192.168.1.100:8080本地真机调试部署到云服务器后端部署到公网小程序请求公网 HTTPS 接口正式发布、演示你自己做毕设演示时用第二种方法会更稳妥。因为现场环境可能没有局域网而且局域网 IP 换一个网段就失效了提前部署到服务器能避免答辩当天翻车。5.4 服务器上线部署打包、上传、运行与防火墙服务器部署本质上并不复杂核心就三条命令打包、上传、运行。先在 IDEA 里执行 Maven 的package命令生成可执行 jar 包目标文件位于target/cet-helper-0.0.1-SNAPSHOT.jar。然后将 jar 包上传到服务器推荐放在/opt/app/目录。最后用nohup命令后台启动nohup java -jar /opt/app/cet-helper-0.0.1-SNAPSHOT.jar \ --spring.profiles.activeprod /opt/app/logs/app.log 21 启动完成后访问http://服务器公网IP:8080/api/health测试。如果访问不通先查一下服务器安全组和防火墙是否放行了 8080 端口firewall-cmd --list-ports firewall-cmd --zonepublic --add-port8080/tcp --permanent firewall-cmd --reload如果你买的是云服务器还要记得在云控制台的安全组规则里添加入方向规则放行 8080 端口。这一步漏掉前端永远连不上后端但你自己在服务器上 curl 又是通的非常容易误判成小程序代码问题。5.5 只有 Jar 包没有源码怎么快速反推项目结构网上不少资源只提供了编译好的 jar没有原始源码或者源码已经找不到了。这种时候可以通过反编译工具快速了解项目结构和接口路径。Java 项目反编译在类结构还原上效果很不错JD-GUI 和 CFR 都是常用的工具拖入 jar 包就能看到 Controller、Mapper 等类的轮廓。不过我要提醒一句反编译的主要价值是帮助你“看懂技术实现、复现接口清单”用它做二次开发没有问题但不能拿去重新销售或冒用别人的成果。尤其是毕业设计场景一定要保留原始源码的版权边界论文查重和代码查重都是过硬的坎。我自己遇到这种“只有 jar 没源码”的求助时一般建议先列出 Controller 层的RequestMapping路径表再根据路径反推数据库表名最后再考虑要不要重新建一个工程。这个过程耗时不少远不如直接拿到一份结构完整的源码来得省事。6. 常见问题与排查技巧实录6.1 启动与联调报错速查表代码跑不起来的情况90% 都集中在几个固定问题上。我把实战中遇到过的高频报错整理成一张速查表方便你对照排查报错现象常见原因解决办法后端启动报数据库连接失败数据库密码错误、库名不对、MySQL 没启动检查 application.yml 配置确认连接地址和账号密码启动报端口被占用8080 端口被其他程序占用netstat -ano小程序请求报 request:fail后端没启动、后端地址写错先用浏览器访问接口测试确认后端可访问再调前端真机预览无法请求后端手机和电脑不在同一网络改用同一局域网或部署到服务器页面加载数据为空token 过期、接口路径不对检查 token 是否过期打开调试面板看请求 URL中文乱码数据库的连接字符集配置错误url 加 characterEncodingutf8并确认表字段为 utf8mb4JDK 版本冲突SpringBoot 2.x 搭配 JDK 17切换项目 SDK 到 JDK 8 或 11微信登录 40001 错误AppID 或 AppSecret 错误检查小程序后台配置确认不是测试号密钥6.2 二次开发与功能扩展建议如果时间允许我建议你在基础功能之上做几个“低成本高关注度”的扩展答辩时非常提分。第一个推荐做的是“学习数据报表”。现在系统里有做题记录、错题记录、单词学习记录这些数据本身就是报告数据。增加一个统计接口按周聚合用户的做题数量和正确率前端用柱状图或环形图展示从功能到视觉都有很大的展示空间。第二个推荐做的是“听力音频播放”。四六级听力是刚需你可以在题目表里增加audio_url字段在题目详情页嵌入小程序原生的音频播放组件。这类外接资源不需要复杂开发但产品体验瞬间提升一个档次。第三个能力允许的话可以接入大模型接口做“主观题智能评分”。把用户的作文或翻译提交给大模型让它给出评分和建议。这不是教学系统必需的功能但从技术演示角度看能很直观地展示你对最新技术的敏感性评委也愿意多聊几句。6.3 项目上线运营的几个提醒这最后一个部分我想聊聊跑通之外的事情。如果你后续真的要把这个小程序发布上线有几点必须提前准备一是小程序后台要配置服务器域名白名单而且必须是 HTTPS 协议二是后端接口要做好基础的安全防护比如登录 token 校验、接口频率限制不能裸奔三是数据库要定期备份防止误操作或服务器故障导致学习数据丢失。对毕设来说做到前两点就能让你的项目“看起来像正经产品”而不只是一个本地跑通的 demo。我个人的经验是拿到这类源码后不要着急启动跑通先花半小时把数据库脚本和接口清单整理一遍。数据库脚本决定了系统里有什么数据接口清单决定了前端能调什么功能这两样东西理清了整条系统的骨架也就出来了。这个习惯帮我避开了好多次“跑起来才发现业务逻辑全乱”的尴尬场面。这套四六级小助手系统本身并不复杂但它串起了一个完整应用开发链路吃透它再去做更复杂的系统就有底气了。
最近有个准备做毕设的同学拿了一套“SpringBoot基于微信小程序的四六级小助手系统”源码来问我说想看懂、想跑通、还想跟导师讲清楚里面到底做了些什么。这类小系统在毕业设计选题里非常常见技术栈不复杂但麻雀虽小五脏俱全——SpringBoot 负责后端接口微信小程序负责前端页面再把单词、真题、错题、模拟考试这些学习场景串起来就是一个很典型的全栈实战项目。我花了两个晚上把整套代码从头到尾过了一遍跑通了数据库、后端和小程序三端也踩了几个不大不小的坑。这篇就顺着项目拆解、架构设计、功能实现、部署排错这几个角度把“四六级小助手系统”讲透。不管你是想拿它做毕设还是单纯想学 SpringBoot 小程序怎么配合这篇都能给你一个明确的下手路径。1. 项目拆解这套四六级小助手到底做了什么1.1 一句话说清系统定位“四六级小助手系统”本质上是一个面向大学生、CET-4/CET-6 备考场景的轻量级学习工具。它前端跑在微信小程序里用户打开就能用不需要下载 App也不用单独注册账号后端跑在 SpringBoot 服务上负责所有业务逻辑和数据存取。它能做的事用大白话讲就是三个背单词、刷真题、看学习记录。你再往细里拆还能拆出每日单词打卡、乱序测试、模拟试卷、自动判分、错题本、练习记录、积分排行这些常见功能点。这些功能听着多但落到代码层面其实都是“用户 题库 记录”三张核心数据在流转。标题里的 LW在毕设语境下一般指“论文文档”包含需求分析、数据库设计、功能设计这些章节。整套资源也就是拿到手之后有源码、有文档、有部署说明能让你从 0 到 1 把系统跑起来并且能跟老师讲明白每一步为什么这么做。1.2 为什么选 SpringBoot 微信小程序而不是纯网页很多人在选题时会犹豫同样一套学习系统为什么不做成 Vue 网页或者直接用 Android这背后的选型逻辑其实很值得掰扯一下。首先是使用场景。四六级备考是典型的碎片化场景学生在自习室、食堂排队、晚上睡觉前都可能刷几道题。微信小程序不用安装打开即用用完就关学习记录自动同步这种“低门槛、高频次”的模式比打开电脑访问网页要舒服很多。其次是开发成本。如果做纯网页你自己得搞定浏览器适配和手机端响应式布局如果做原生 App光打包、上架、审核这一套流程就能耗掉大半个月。而微信小程序天然自带账号体系不需要开发者自己做验证码注册、找回密码那一套后端只需要对接微信登录省下的工作量非常可观。我整理了一个选型对比表格大家可以直观感受一下对比项纯网页Vue/React微信小程序原生 App (Android)开发门槛中需要搞定移动端适配低官方开发工具开箱即用高需要掌握原生语言和打包发布账号体系自己实现注册登录微信授权省心第三方登录需自己集成用户触达要自己拉流量微信生态内传播需下载安装流失率较高适合场景后台管理、PC 用户学生、碎片化学习高频重型应用毕设难度中等中等偏易答辩亮点好做较高工期风险大对毕业设计而言选 SpringBoot 微信小程序还有一个隐藏优势它同时覆盖了“后端开发”和“移动端开发”两个方向答辩时能讲的东西非常丰富。你既可以说自己设计了 RESTful API也可以说你解决了小程序体验优化问题还能讲一讲数据表关系如何支撑业务。相比纯后端管理系统的选题这类项目的技术广度和可展示性都要强不少。2. 系统架构与核心设计思路2.1 前后端分离下的整体数据流这套系统的整体结构是标准的前后端分离模式我建议你在看代码之前先把下面这条数据流在脑子里过一遍小程序端发起请求 → 微信服务器换取用户身份 → 后端 SpringBoot 接收请求 → 业务层处理逻辑 → 数据层访问 MySQL → 返回统一 JSON → 小程序渲染页面换句话说小程序不直接连接数据库所有数据查询都走后端接口。比如用户想查看今天的背单词计划前端就调/api/word/plan这个接口后端查 word 表把今天该学的单词列表返回给前端前端再用 WXML 渲染出来。在这个架构下后端接口起着“中间层”的作用一是隐藏数据库结构不暴露敏感字段二是把业务逻辑集中管理不管以后小程序改版还是新增管理后台接口可以复用三是在接口层做参数校验和权限控制避免非法请求直接打到数据库上。如果你打开源码一般会在src/main/java下面看到controller、service、mapper三层结构。这是最常见的 SpringBoot 分层方式controller 接收参数并返回结果service 写业务规则mapper 操作数据库。相当于饭店里的服务员负责传菜厨师负责做菜采购员负责买菜各管一摊出问题也好定位。2.2 数据库表结构设计要点数据库是一套项目的命脉我挑几张三、草核心表给大家拆一下。实际项目里表名可能不同但思路都是一样的。用户表user字段类型说明idbigint主键openidvarchar(64)微信唯一标识nicknamevarchar(50)昵称avatarvarchar(255)头像gendertinyint性别study_daysint连续学习天数total_scoreint当前个人积分create_timedatetime注册时间单词表word是四六级系统的核心资产。通常字段有id、word、translate、phonetic、example、category四级/六级还可以加word_type用于标识名词、动词、形容词等。有些项目还会做“词根词缀”字段方便扩展。做题记录表exam_record承担着统计职责。它要记录用户某一次刷题用了哪套试卷、答了多少题、对了几题、花费多少秒字段一般有record_id、user_id、paper_id、question_count、correct_count、duration、create_time。这张表是判断用户学习效果的主要依据也是后面做错题本和排行榜的数据来源。答错题汇总表wrong_book设计上有一些讲究。最简单的设计就是记录user_id和question_id再加一个wrong_count统计错误次数以及last_wrong_time记录最近一次做错的时间。这样既能做去重又能按错误次数给用户推复习优先级。这里我要特别提醒一个新手容易犯的错不要把错题本设计成“用户答错一次就插入一条记录”那会导致同一个题目在表里出现很多条。正确思路是当用户做错时先去查这张表有没有相同 user_id question_id 的记录有就让错误次数加一没有才插入新记录。2.3 小程序页面结构与自定义导航栏适配再来看小程序端的页面组织。四六级小助手一般会有这几个主要页面首页、背单词页、刷题页、我的页面。如果你用原生小程序开发常见的目录结构是这样pages/ ├── index/ # 首页展示学习进度和今日推荐 ├── word/ # 单词学习与打卡 ├── exam/ # 真题练习与模拟考试 ├── wrong/ # 错题本 └── user/ # 个人中心、登录、排行这种 tabBar 结构在交互上最稳用户一进来就知道该在哪里点。“微信小程序顶部导航栏高度”是大家绕不开的适配问题尤其做自定义导航栏时。原生导航栏没法改背景色也没法塞自定义组件所以很多项目都选择自定义导航栏。但自定义导航栏需要自己算状态栏高度和胶囊按钮位置我贴一段常用代码const getNavBarInfo () { const menu wx.getMenuButtonBoundingClientRect() const systemInfo wx.getSystemInfoSync() const statusBarHeight systemInfo.statusBarHeight const navBarHeight (menu.top - statusBarHeight) * 2 menu.height return { statusBarHeight, navBarHeight, menu } }这段代码的原理很直接状态栏高度就是手机系统顶部那条信号时间电池栏的高度胶囊按钮右上角那三个点是微信固定的所以通过getMenuButtonBoundingClientRect()拿到的胶囊位置就能反推自定义导航栏应该占多高、文字应该垂直居中到什么位置。这个方法在 Android 和 iOS 上兼容性都很好做自定义导航栏时直接抄这一段就够用。3. 核心功能模块的实现思路3.1 背单词模块词库、学习计划与打卡逻辑背单词功能是整个系统里最能体现产品设计能力的模块技术上却比较简单。核心就是控制好“词库来源”和“学习节奏”。词库来源一般是两种一种是开发阶段手动维护把四级大纲词汇、六级大纲词汇整理成 SQL 文件通过INSERT INTO word批量导入另一种是后台预留管理功能管理员通过页面上传 Excel后端解析后批量写入。我建议初学阶段先用手动 SQL 导入的方式简单直接不会因为文件解析问题卡住整个项目。学习计划逻辑一般围绕“每日新词数量 复习数量”来做。比如用户设置每天新学 20 个词那么后端查询时会按“用户今天还没学过的单词优先 之前学过但已超过复习间隔的单词”这两个条件拉数据。你可以提前在 service 层做一个查询方法核心 SQL 大致长这样SELECT * FROM word WHERE category 四级 AND id NOT IN (SELECT word_id FROM word_study_record WHERE user_id 1) LIMIT 20打卡逻辑的核心是“当天首次学习即算打卡成功”后端通过查询word_study_record中是否存在当天的记录来判断。打卡数据再拿去更新用户表的study_days和积分表这样积分排行也就有了数据来源。3.2 刷题与模拟考试题库结构、判分逻辑与计时刷题模块的设计难点在于题目类型的区分。四六级真题题型有听力、阅读、翻译、写作。听力题和阅读题属于客观题选项固定答案固定比较适合自动判分翻译和写作是主观题系统只能记录用户写的答案让用户自己对照参考答案判分严格说没办法做到完全智能评判。题库表question的关键字段包括paper_id、question_type、content、option_a、option_b、option_c、option_d、answer、analysis、score。客观题的答案字段存一个大写字母比如“C”判分时拿用户提交的答案和它做字符串匹配就可以。模拟考试功能在实现时需要一个“随机出题”的算法。比较常见的做法是后端在用户点击“开始考试”时从题库里按题型随机抽取若干题比如听力 10 题、阅读 10 题拼成一份临时试卷。这里我建议把临时试卷存到一张user_paper表而不是每次提交答案时再临时拼这样即使用户中途退出重新进入也还能恢复上次的答题内容。计时功能要分为前端计时和后端计时。前端计时能展示一个倒计时提示用户后端计时则用于判断超时比如考试超过 40 分钟自动交卷。在作答记录表里统一保存start_time和submit_time后续做学习效率分析时才有可靠的数据。3.3 错题本去重、错误次数与薄弱项统计错题本不是简单的“把错题列出来”它的价值在于“基于错题数据做分析”。所以我建议你在实现时不止要存题目 ID还要存错误次数和知识点标签。举个例子某一道阅读题做错以后记录里能知道它属于“细节理解题”还是“主旨大意题”。当错题本里某类题型的错误次数明显偏高系统就可以在首页提示用户“你的阅读理解主旨题正确率偏低建议加强练习”。这个逻辑用 SQL 就能实现以wrong_question_type分组统计 count 排序即可不需要复杂的算法。在做错题本功能时还有一个容易被忽略的细节用户第一次做错第二次做对了这道题应该从错题本里移除还是保留我的建议是保留但把状态标记为“已掌握”并保留历史错误次数。因为用户可能只是蒙对了保留错误记录有助于周期性复习。当错误次数达到阈值并且连续做对三次才真正从错题本移除。3.4 用户体系与积分排行激励用户连续学习做学习类小程序光有功能还不够还得有激励手段。这套系统常见的做法是积分 排行。用户签到得积分、背完单词得积分、正确率达到 80% 以上额外得积分这些积分汇总到排行榜上营造一种“和同学比着学”的氛围。积分表设计一般有score_id、user_id、type、score、create_time。type 字段标识积分来源比如 1 代表签到2 代表每日任务3 代表模拟考试。显示排行榜时后端对 user 表按total_score排序取前 20 名即可。这里有一个交互层面的小技巧排行榜不应该只展示前 20 名还需要把当前用户自己的排名也显示出来。不然用户发现自己不在榜单上很容易失去参与感。实现方式可以先用 SQL 取出所有用户积分排序的列表再在 Java 代码里二分查找或循环比对出当前用户的排名。4. 前后端对接中的关键细节4.1 微信登录流程与 Token 会话管理微信小程序登录是整套系统第一步要打通的环节。很多新手会误以为“小程序里拿到了用户昵称头像就叫登录”实际上真正的登录逻辑是这样的小程序端调用wx.login()微信返回一个临时code。小程序把code发给 SpringBoot 后端后端拿着code、小程序的 AppID 和 AppSecret 去请求微信的jscode2session接口换取openid。这个openid才是用户在当前小程序里的唯一身份标识。后端拿到openid后先查用户表如果已经存在就直接登录成功如果不存在就自动创建一个新用户。随后生成一个自定义 token可以用 UUID 或 JWT返回给前端前端把 token 存起来之后的请求都带上这个 token后端通过 token 识别当前用户。下面这段是后端处理登录的伪代码核心流程一目了然PostMapping(/login) public Result login(RequestBody LoginDTO dto) { // 1. 用 code 换 openid String openid wxService.code2Session(dto.getCode()); // 2. 查询或创建用户 User user userService.findOrCreate(openid); // 3. 生成 token 并缓存 String token UUID.randomUUID().toString().replace(-, ); // 4. 返回前端 return Result.success(token); }登录状态管理的坑在于 token 有效期。我不建议把 token 设置得太长比如永久有效或 30 天有效这会埋安全隐患也不建议设置太短用户可能正背到一半就要重新登录。比较合理的设置是 7 天有效用户 7 天内打开小程序不用重复登录超过 7 天再去请求接口时后端返回 401前端引导用户重新登录。4.2 小程序请求封装统一入口、错误提示与登录态刷新小程序原生wx.request用起来很原始每个页面都要写一遍 success、fail 等回调代码会非常冗长。我强烈建议在开发前就封装好一个request.js把所有公共逻辑集中管理比如 baseUrl 拼接、请求头 token、统一错误码处理、加载动画控制等。下面是一个比较实用的请求封装模板const request (url, method GET, data {}) { return new Promise((resolve, reject) { wx.request({ url: getApp().globalData.baseUrl url, method, data, header: { Content-Type: application/json, token: wx.getStorageSync(token) || }, success: (res) { if (res.data res.data.code 200) { resolve(res.data.data) } else if (res.data res.data.code 401) { wx.removeStorageSync(token) wx.navigateTo({ url: /pages/login/login }) reject(res.data) } else { wx.showToast({ title: res.data.message, icon: none }) reject(res.data) } }, fail: (err) { wx.showToast({ title: 网络异常请稍后重试, icon: none }) reject(err) } }) }) }封装完成以后页面里的调用就变得非常清爽。比如获取单词列表const list await request(/api/word/list, GET, { category: 四级 })这套封装的思路并不复杂但它能解决很多纯新手项目里“每个页面都在重复处理错误提示、登录失效”的混乱问题。做到前后端返回格式统一前端一行if (res.data.code 200)就能判断请求是否成功维护性会大幅提升。4.3 SpringBoot 接口设计统一返回体、参数校验与跨域后端接口设计有没有章法直接决定前端对接能不能顺利推进。我见过很多毕设项目的接口返回特别随意有的接口返回 true/false有的返回字符串有的直接把整个实体对象丢出去前端对接时写一堆判断容易出 bug。规范的做法是设计一个统一的返回体类比如ResultT包括三个字段code、message、data。成功时 code 为 200业务失败时 code 为 400 或 500登录失效是 401。前端拿到响应后只看 code 就能知道请求结果不用关心 data 里到底返回了什么。public class ResultT { private Integer code; private String message; private T data; public static T ResultT success(T data) { ResultT result new Result(); result.setCode(200); result.setMessage(success); result.setData(data); return result; } }参数校验这块也不要依赖前端后端要做二次防御。比如用户提交的答题参数里questionId为空或者answer不是 A/B/C/D 中的一种后端应该在 service 层或通过注解直接拦截。使用 SpringBoot 自带的Validated加 DTO 上的NotBlank、NotNull注解就能省掉一大部分手工判断。跨域问题主要在开发阶段出现。小程序请求后端不涉及浏览器跨域但如果你单独做了一个后台管理页面或者用 Swagger 在线调试跨域就会冒出来。后端增加一个全局跨域配置类允许所有来源访问开发时能少掉很多无谓的阻碍。5. 从源码到跑通搭建与部署全流程5.1 本地开发环境准备清单拿到源码以后第一步别急着跑先检查环境。SpringBoot 项目的运行环境比较固定我列出需要准备的清单组件版本建议用途JDK1.8 或 11运行 SpringBootMaven3.6依赖管理MySQL5.7 或 8.0数据存储IntelliJ IDEA2020导入和运行项目微信开发者工具最新稳定版运行小程序Node.js可选个别构建工具需要这里有个容易掉坑的地方SpringBoot 版本和 JDK 版本的匹配。如果项目用的是 SpringBoot 2.7而你本地装的是 JDK 17启动时大概率会报 CGLIB 或反射相关的异常。遇到这种问题最省事的办法是安装 JDK 8 或者 11并把 IDEA 里项目的 SDK 切换过去不要上来就折腾升级 SpringBoot 版本。5.2 后端启动三步曲建库、改配置、启动主类后端启动的完整流程可以压缩成三步。第一步建库。拿到项目以后先在源码目录里找 SQL 文件常见文件名是cet_helper.sql或者database.sql。打开 MySQL 客户端执行CREATE DATABASE cet_helper DEFAULT CHARACTER SET utf8mb4;然后把 SQL 文件导入mysql -u root -p cet_helper cet_helper.sql导入完成后用 Navicat 或命令行检查一下表数量确认至少有用户、单词、试卷、题目这几张核心表再往下走。第二步改配置。打开src/main/resources/application.yml把数据库连接信息改成你自己本地的账号密码。我截取一段典型的配置spring: datasource: url: jdbc:mysql://localhost:3306/cet_helper?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai username: root password: 123456 driver-class-name: com.mysql.cj.jdbc.Driver特别提醒serverTimezone参数不要漏不加的话 MySQL 8.0 以上版本经常会报时区错误。如果你用的是 MySQL 5.7可以保留也可以去掉不影响核心流程。第三步启动。在 IDEA 里找到带有SpringBootApplication注解的主类右键 Run。启动日志里看到 “Started Application in xxxx seconds” 就说明后端已经起来了。此时可以访问http://localhost:8080/api/health这类接口测一下通没通通常会返回一个 JSON 对象。5.3 小程序端配置与真机调试注意事项后端跑通以后把小程序源码导入微信开发者工具。第一件要做的事是改 AppID。如果你的源码里用的是别人的 AppID直接预览会提示没有权限需要换成自己注册的小程序 AppID使用测试号也可以。第二件事是改后端地址。开发者工具本地调试时默认可以使用http://localhost:8080但要注意两点一是微信开发者工具需要勾选“不校验合法域名”因为本地调试的域名没有备案也没有配置到后台白名单二是真机预览时手机不能通过localhost访问电脑上的后端这里有两种解决办法方法步骤适用场景电脑开热点将手机和电脑连同一局域网后端地址改成电脑局域网 IP例如 http://192.168.1.100:8080本地真机调试部署到云服务器后端部署到公网小程序请求公网 HTTPS 接口正式发布、演示你自己做毕设演示时用第二种方法会更稳妥。因为现场环境可能没有局域网而且局域网 IP 换一个网段就失效了提前部署到服务器能避免答辩当天翻车。5.4 服务器上线部署打包、上传、运行与防火墙服务器部署本质上并不复杂核心就三条命令打包、上传、运行。先在 IDEA 里执行 Maven 的package命令生成可执行 jar 包目标文件位于target/cet-helper-0.0.1-SNAPSHOT.jar。然后将 jar 包上传到服务器推荐放在/opt/app/目录。最后用nohup命令后台启动nohup java -jar /opt/app/cet-helper-0.0.1-SNAPSHOT.jar \ --spring.profiles.activeprod /opt/app/logs/app.log 21 启动完成后访问http://服务器公网IP:8080/api/health测试。如果访问不通先查一下服务器安全组和防火墙是否放行了 8080 端口firewall-cmd --list-ports firewall-cmd --zonepublic --add-port8080/tcp --permanent firewall-cmd --reload如果你买的是云服务器还要记得在云控制台的安全组规则里添加入方向规则放行 8080 端口。这一步漏掉前端永远连不上后端但你自己在服务器上 curl 又是通的非常容易误判成小程序代码问题。5.5 只有 Jar 包没有源码怎么快速反推项目结构网上不少资源只提供了编译好的 jar没有原始源码或者源码已经找不到了。这种时候可以通过反编译工具快速了解项目结构和接口路径。Java 项目反编译在类结构还原上效果很不错JD-GUI 和 CFR 都是常用的工具拖入 jar 包就能看到 Controller、Mapper 等类的轮廓。不过我要提醒一句反编译的主要价值是帮助你“看懂技术实现、复现接口清单”用它做二次开发没有问题但不能拿去重新销售或冒用别人的成果。尤其是毕业设计场景一定要保留原始源码的版权边界论文查重和代码查重都是过硬的坎。我自己遇到这种“只有 jar 没源码”的求助时一般建议先列出 Controller 层的RequestMapping路径表再根据路径反推数据库表名最后再考虑要不要重新建一个工程。这个过程耗时不少远不如直接拿到一份结构完整的源码来得省事。6. 常见问题与排查技巧实录6.1 启动与联调报错速查表代码跑不起来的情况90% 都集中在几个固定问题上。我把实战中遇到过的高频报错整理成一张速查表方便你对照排查报错现象常见原因解决办法后端启动报数据库连接失败数据库密码错误、库名不对、MySQL 没启动检查 application.yml 配置确认连接地址和账号密码启动报端口被占用8080 端口被其他程序占用netstat -ano小程序请求报 request:fail后端没启动、后端地址写错先用浏览器访问接口测试确认后端可访问再调前端真机预览无法请求后端手机和电脑不在同一网络改用同一局域网或部署到服务器页面加载数据为空token 过期、接口路径不对检查 token 是否过期打开调试面板看请求 URL中文乱码数据库的连接字符集配置错误url 加 characterEncodingutf8并确认表字段为 utf8mb4JDK 版本冲突SpringBoot 2.x 搭配 JDK 17切换项目 SDK 到 JDK 8 或 11微信登录 40001 错误AppID 或 AppSecret 错误检查小程序后台配置确认不是测试号密钥6.2 二次开发与功能扩展建议如果时间允许我建议你在基础功能之上做几个“低成本高关注度”的扩展答辩时非常提分。第一个推荐做的是“学习数据报表”。现在系统里有做题记录、错题记录、单词学习记录这些数据本身就是报告数据。增加一个统计接口按周聚合用户的做题数量和正确率前端用柱状图或环形图展示从功能到视觉都有很大的展示空间。第二个推荐做的是“听力音频播放”。四六级听力是刚需你可以在题目表里增加audio_url字段在题目详情页嵌入小程序原生的音频播放组件。这类外接资源不需要复杂开发但产品体验瞬间提升一个档次。第三个能力允许的话可以接入大模型接口做“主观题智能评分”。把用户的作文或翻译提交给大模型让它给出评分和建议。这不是教学系统必需的功能但从技术演示角度看能很直观地展示你对最新技术的敏感性评委也愿意多聊几句。6.3 项目上线运营的几个提醒这最后一个部分我想聊聊跑通之外的事情。如果你后续真的要把这个小程序发布上线有几点必须提前准备一是小程序后台要配置服务器域名白名单而且必须是 HTTPS 协议二是后端接口要做好基础的安全防护比如登录 token 校验、接口频率限制不能裸奔三是数据库要定期备份防止误操作或服务器故障导致学习数据丢失。对毕设来说做到前两点就能让你的项目“看起来像正经产品”而不只是一个本地跑通的 demo。我个人的经验是拿到这类源码后不要着急启动跑通先花半小时把数据库脚本和接口清单整理一遍。数据库脚本决定了系统里有什么数据接口清单决定了前端能调什么功能这两样东西理清了整条系统的骨架也就出来了。这个习惯帮我避开了好多次“跑起来才发现业务逻辑全乱”的尴尬场面。这套四六级小助手系统本身并不复杂但它串起了一个完整应用开发链路吃透它再去做更复杂的系统就有底气了。
