简介这份资源是面向高校学生与Java初学者的一份完整毕业设计文档主题为基于微信小程序的四六级词汇学习系统帮助备考四六级的用户随时随地进行词汇管理与学习。文档围绕系统分析、功能设计与技术实现展开涵盖微信开发者工具、小程序框架与目录结构、Java语言、MySQL数据库及SSM框架等关键技术并包含需求分析、可行性分析、系统设计与实现等完整章节可作为课程设计或毕业设计的参考模板。资源包共1个docx文件大小约3.79MB内容结构完整、目录清晰便于按章节查阅与二次修改。目前已有30人学习下载适合需要小程序开发实战案例、想了解SSM与小程序结合方式或正在准备相关论文与答辩的读者参考借鉴。1. 从一份 docx 到能跑的小程序四六级词汇系统到底要解决什么每年四六级报名前后总有一批同学在群里问「有没有那种能按高频词、真题词分类背单词的小程序」。市面上背单词 App 不少但要么广告多要么词库和四六级考纲对不上要么强制付费。于是「基于微信小程序的四六级词汇系统」这类课程设计题目就冒出来了——它看起来是个学生作业实际上是一个完整的全栈落地场景微信小程序做前端Java 做后端MySQL 存词库和用户数据SSM 框架把三层串起来。这个系统的核心诉求很明确用户打开小程序就能查词、背词、做测试后台能管理词库和用户记录。它适合三类人一是正在做课程设计或毕业设计的同学需要一个能讲清楚架构、能演示、能写进论文的完整项目二是想从零学微信小程序 Java 后端的开发者需要一个有真实业务逻辑的练手项目三是英语老师或培训机构想低成本搭一个内部用的词汇工具。接下来我会按「架构怎么定 → 数据库怎么建 → 后端怎么写 → 小程序怎么调 → 坑在哪」的顺序把这条链路拆开讲清楚。2. 架构选型为什么是微信小程序 SSM而不是 uniapp 或 Spring Boot2.1 前端为什么选原生微信小程序而不是 uniapp热词里「uniapp 开发 微信小程序 vs android/ios/鸿蒙」被反复搜说明很多人卡在选型这一步。我的判断是如果目标平台只有微信小程序原生开发更稳。uniapp 的优势是一套代码多端发布但代价是引入了一层编译转换遇到小程序原生组件比如picker、canvas时经常要写条件编译调试成本反而更高。四六级词汇系统不需要跨端用户就在微信里用原生小程序的wx.request、wx.setStorageSync、scroll-view这些 API 直接调没有中间层。原生小程序的目录结构也简单pages放页面utils放请求封装app.json配路由和 tabBar。一个查词页、一个背词页、一个测试页、一个个人中心四个页面就能撑起核心功能。页面间传参用wx.navigateTo的 query 或者全局getApp().globalData不需要引入状态管理库。2.2 后端为什么用 SSM 而不是 Spring BootSSMSpring Spring MVC MyBatis是很多高校课程设计的标配原因很实际教材用它老师熟悉它答辩时不会被问「你这个 Spring Boot 自动配置原理是什么」。从技术角度看SSM 把控制层、业务层、持久层分得很清楚applicationContext.xml里配数据源、事务、MyBatis 的SqlSessionFactory虽然 XML 多但每一步都看得见适合用来理解「一个请求从 Controller 到 Mapper 到底经过了什么」。如果你已经熟悉 Spring Boot完全可以换成 Spring Boot MyBatis少写一堆 XML。但如果你是要交课程设计或者想顺着教材的节奏走SSM 的「笨重」反而是优点——它逼你把每个 Bean 的依赖关系搞清楚。下面给一个典型的 SSM 分层结构src/main/java/com/vocab/ ├── controller/ // 接收小程序请求 │ ├── WordController.java │ └── UserController.java ├── service/ // 业务逻辑 │ ├── WordService.java │ └── impl/WordServiceImpl.java ├── mapper/ // MyBatis 接口 │ └── WordMapper.java ├── entity/ // 实体类 │ └── Word.java └── util/ // 工具类 └── Result.java这个结构里controller只负责参数校验和返回 JSONservice写业务规则比如「每天最多背 50 个新词」mapper对应 SQL。小程序端拿到的统一是Result对象包含code、msg、data三个字段前端根据code判断成功还是失败。2.3 数据库为什么用 MySQL 而不是 SQLite 或 MongoDB词库数据是典型的结构化数据单词、音标、释义、例句、词频、考频字段固定关系明确。MySQL 的关系模型和索引机制正好匹配这种场景。比如按「高频词」筛选就是WHERE frequency_level high加个索引就能快速返回。SQLite 适合单机但小程序后端要支持多用户并发SQLite 的写锁会成为瓶颈。MongoDB 的文档模型对词库来说反而多余因为每个单词的字段都一样不需要动态 schema。MySQL 安装配置教程、Linux 安装 MySQL、rpm 安装 MySQL 这些热词说明很多人在环境搭建上就卡住了。我的建议是本地开发用 Windows 安装包或者 Docker 起一个 MySQL 8.0服务器部署用apt或yum装版本保持一致。字符集统一用utf8mb4否则音标里的特殊字符会乱码。3. 数据库设计词库表、用户表、记录表怎么建才不返工3.1 三张核心表的字段与索引四六级词汇系统的数据模型不复杂但字段设计直接影响后面查询和统计的效率。我一般会建三张核心表word词库、user用户、study_record学习记录。下面是我实际用过的建表语句-- 词库表存四六级单词及考频信息 CREATE TABLE word ( id INT NOT NULL AUTO_INCREMENT, word VARCHAR(64) NOT NULL COMMENT 单词, phonetic VARCHAR(64) DEFAULT NULL COMMENT 音标, meaning VARCHAR(512) NOT NULL COMMENT 中文释义, example VARCHAR(512) DEFAULT NULL COMMENT 例句, level TINYINT NOT NULL DEFAULT 4 COMMENT 4四级 6六级, frequency INT DEFAULT 0 COMMENT 真题出现次数, tag VARCHAR(32) DEFAULT NULL COMMENT 高频/核心/认知, PRIMARY KEY (id), UNIQUE KEY uk_word_level (word, level), KEY idx_level_freq (level, frequency) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; -- 用户表微信 openid 做唯一标识 CREATE TABLE user ( id INT NOT NULL AUTO_INCREMENT, openid VARCHAR(64) NOT NULL COMMENT 微信 openid, nickname VARCHAR(64) DEFAULT NULL, daily_goal INT DEFAULT 20 COMMENT 每日目标词数, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), UNIQUE KEY uk_openid (openid) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; -- 学习记录表记录每个用户对每个词的状态 CREATE TABLE study_record ( id INT NOT NULL AUTO_INCREMENT, user_id INT NOT NULL, word_id INT NOT NULL, status TINYINT DEFAULT 0 COMMENT 0未学 1已学 2已掌握, wrong_count INT DEFAULT 0 COMMENT 答错次数, last_study_time DATETIME DEFAULT NULL, PRIMARY KEY (id), UNIQUE KEY uk_user_word (user_id, word_id), KEY idx_user_status (user_id, status) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;word表的uk_word_level唯一索引保证同一个单词不会在四级和六级里重复插入idx_level_freq让「按考频排序取前 N 个」的查询走索引。study_record的uk_user_word保证一个用户对一个词只有一条记录更新时用INSERT ... ON DUPLICATE KEY UPDATE避免重复插入。3.2 词库数据从哪来怎么导入词库是这类系统的命脉。常见做法是找一份四六级大纲词汇表Excel 或 CSV整理成word表的字段格式然后用LOAD DATA INFILE或者写个 Java 的POI解析脚本批量插入。热词里「java poi word 能生成图表吗」说明有人想用 POI 操作 Word但这里我们只需要读 Excel用EasyExcel或POI的XSSFWorkbook就够了。// 用 EasyExcel 读取词库 Excel 并批量插入 public void importWords(String filePath) { ListWord wordList EasyExcel.read(filePath) .head(Word.class) // 表头映射到 Word 字段 .sheet() .doReadSync(); // 分批插入每批 500 条避免单条 SQL 过长 for (int i 0; i wordList.size(); i 500) { ListWord batch wordList.subList(i, Math.min(i 500, wordList.size())); wordMapper.batchInsert(batch); } }head(Word.class)要求 Excel 表头名称和Word类的字段名一致或者用ExcelProperty注解指定。分批插入是因为 MySQL 的max_allowed_packet默认 4MB一次插几万条会报PacketTooBigException。每批 500 条是经验值太小了事务提交次数多太大了 SQL 拼接字符串容易超长。3.3 学习记录的更新策略为什么不用先查后插背单词时用户每点一次「认识」或「不认识」都要更新study_record。如果先SELECT判断是否存在再决定INSERT还是UPDATE并发下会有竞态条件。更稳的做法是用INSERT ... ON DUPLICATE KEY UPDATEINSERT INTO study_record (user_id, word_id, status, wrong_count, last_study_time) VALUES (#{userId}, #{wordId}, #{status}, #{wrongCount}, NOW()) ON DUPLICATE KEY UPDATE status VALUES(status), wrong_count wrong_count VALUES(wrong_count), last_study_time NOW();VALUES()函数取的是INSERT子句里准备插入的值这样一条 SQL 就完成了「存在则更新不存在则插入」。wrong_count用累加而不是覆盖因为用户可能多次答错同一个词。这个写法在 MySQL 5.7 和 8.0 都支持但 8.0.20 之后推荐用别名写法不过VALUES()仍然可用。4. 后端接口与小程序请求封装从登录到背词的全链路4.1 微信登录换 openid 的接口怎么写小程序端调用wx.login()拿到临时code传给后端后端用codeappidsecret调微信接口换openid。这一步是必须的因为openid是用户在小程序里的唯一标识。后端接口大概长这样PostMapping(/login) public Result login(RequestBody LoginDTO loginDTO) { String url https://api.weixin.qq.com/sns/jscode2session ?appid appId secret appSecret js_code loginDTO.getCode() grant_typeauthorization_code; // 用 RestTemplate 或 HttpClient 发起 GET 请求 String response restTemplate.getForObject(url, String.class); JSONObject json JSON.parseObject(response); String openid json.getString(openid); if (openid null) { return Result.error(登录失败); } // 查用户是否存在不存在则注册 User user userService.findByOpenid(openid); if (user null) { user new User(); user.setOpenid(openid); userService.insert(user); } // 生成 token 返回给小程序可以用 JWT 或简单 UUID 存 Redis String token tokenService.generateToken(user.getId()); return Result.success(token); }appId和appSecret不要硬编码在代码里放到config.properties或者环境变量。restTemplate要配超时微信接口偶尔会慢不设超时会把 Tomcat 线程占满。返回的token小程序存在wx.setStorageSync(token, token)后续请求放在 header 里。4.2 小程序端请求封装统一处理 token 和错误原生小程序的wx.request是回调式的每个页面都写一遍success、fail很啰嗦。我一般会在utils/request.js里封装一层 Promise// utils/request.js const BASE_URL https://your-domain.com/api; function request(options) { return new Promise((resolve, reject) { wx.request({ url: BASE_URL options.url, method: options.method || GET, data: options.data || {}, header: { content-type: application/json, token: wx.getStorageSync(token) || }, success(res) { if (res.data.code 200) { resolve(res.data.data); } else if (res.data.code 401) { // token 过期重新登录 wx.removeStorageSync(token); wx.navigateTo({ url: /pages/login/login }); reject(res.data); } else { wx.showToast({ title: res.data.msg, icon: none }); reject(res.data); } }, fail(err) { wx.showToast({ title: 网络异常, icon: none }); reject(err); } }); }); } module.exports { request };这个封装做了三件事拼 baseURL、带 token、统一处理code。code 401时清 token 并跳登录页避免用户卡在过期状态。wx.showToast的icon: none是为了显示长文本默认的success图标只能显示两行。4.3 背词页的核心逻辑队列、进度、本地缓存背词页是用户停留最久的页面。我的做法是进入页面时从后端拉一批待学单词比如 20 个存到data.wordList用currentIndex标记当前第几个。用户点「认识」就currentIndex点「不认识」除了currentIndex还要把词加到一个wrongList里本轮结束后再复习一遍。// pages/study/study.js Page({ data: { wordList: [], currentIndex: 0, showMeaning: false }, onLoad() { this.loadWords(); }, loadWords() { request({ url: /word/today, data: { limit: 20 } }) .then(list { this.setData({ wordList: list, currentIndex: 0 }); // 缓存到本地断网时还能看 wx.setStorageSync(todayWords, list); }) .catch(() { // 请求失败读缓存 const cache wx.getStorageSync(todayWords); if (cache) this.setData({ wordList: cache }); }); }, onKnow() { this.submitRecord(this.data.wordList[this.data.currentIndex].id, 1); this.next(); }, onDontKnow() { this.submitRecord(this.data.wordList[this.data.currentIndex].id, 0); this.next(); }, next() { const nextIndex this.data.currentIndex 1; if (nextIndex this.data.wordList.length) { wx.showToast({ title: 今日任务完成, icon: success }); return; } this.setData({ currentIndex: nextIndex, showMeaning: false }); }, submitRecord(wordId, status) { request({ url: /record/submit, method: POST, data: { wordId, status } }); } });wx.setStorageSync(todayWords, list)是热词里「微信小程序设置缓存时间」的典型场景。小程序本地缓存默认永久有效但词库会更新所以我会在缓存里加一个时间戳超过 24 小时就重新拉。submitRecord不阻塞 UI用户点完立刻切下一个词请求在后台发失败了也不影响体验。5. 避坑与排查那些让课程设计卡三天的真实问题5.1 小程序请求报「不在以下 request 合法域名列表中」现象本地调试正常真机预览时所有接口都失败控制台提示域名不合法。原因微信小程序要求所有wx.request的域名必须在「开发设置」里配置且必须是 HTTPS。解决开发阶段在开发者工具里勾选「不校验合法域名」真机调试时要么配一个备案域名要么用内网穿透工具临时映射注意这里说的是本地开发调试不是绕过任何安全机制。上线前必须配好 HTTPS 域名。5.2 MySQL 连接报「Public Key Retrieval is not allowed」现象Java 后端启动时连 MySQL 8.0 报错提示Public Key Retrieval is not allowed。原因MySQL 8.0 默认用caching_sha2_password认证插件JDBC 驱动需要显式允许公钥检索。解决在 JDBC URL 后面加allowPublicKeyRetrievaltrueuseSSLfalse或者把用户的认证插件改成mysql_native_password。生产环境建议用 SSL 连接不要图省事关掉。5.3 音标和特殊字符存进去变成问号现象词库里phonetic字段存的是/ˈæpl/查出来变成/?æpl/。原因数据库、表、连接三处的字符集不一致。解决建库时用CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ciJDBC URL 加characterEncodingutf8小程序端wx.request的header里content-type用application/json而不是application/x-www-form-urlencoded。三处都对齐后音标就不会乱码。5.4 背词页快速点击导致重复提交现象用户连续快速点「认识」同一个词被提交多次学习记录里wrong_count异常累加。原因submitRecord是异步的没有防抖每次点击都发请求。解决在data里加一个submitting标志请求发出前设为true回调里设为falsesubmitting为true时直接return。或者用wx.showLoading遮罩请求完成再wx.hideLoading。5.5 小程序顶部导航栏高度在不同机型不一致现象自定义导航栏时iPhone 和 Android 的状态栏高度不同内容被遮挡。原因wx.getSystemInfoSync().statusBarHeight返回的是状态栏高度但导航栏总高度还要加上胶囊按钮的高度。解决用wx.getMenuButtonBoundingClientRect()拿到胶囊位置导航栏高度 胶囊top- 状态栏高度再乘以 2 加上胶囊高度。这个计算方式在热词「微信小程序顶部导航栏高度」里被反复问实测在主流机型上都准。6. 进阶技巧用错题本和艾宾浩斯曲线把留存做上去基础功能跑通后真正决定用户会不会持续用的是「复习机制」。我一般会在study_record的基础上加一个错题本页面按wrong_count降序排列让用户优先复习错得多的词。更进一步可以引入艾宾浩斯遗忘曲线的简化版每个词记录last_study_time和review_count下次复习时间 上次学习时间 间隔数组[1, 2, 4, 7, 15]天中的第review_count个。-- 查询今天需要复习的词上次学习时间 间隔 今天 SELECT w.* FROM word w JOIN study_record r ON w.id r.word_id WHERE r.user_id #{userId} AND r.status ! 2 AND DATE_ADD(r.last_study_time, INTERVAL ELT(r.review_count 1, 1, 2, 4, 7, 15) DAY) CURDATE() ORDER BY r.wrong_count DESC LIMIT 20;ELT()函数根据review_count 1的位置从间隔数组里取值review_count为 0 时取 1 天为 1 时取 2 天以此类推。这个查询走idx_user_status索引20 条以内响应很快。小程序端把「今日新词」和「今日复习」分成两个 tab用户先复习再学新词记忆效果比混在一起好。验证这套机制有没有生效我一般看两个指标一是study_record里status 2已掌握的词占比二是用户连续打卡天数。如果一周后已掌握占比低于 30%说明间隔太短或太长需要调ELT里的天数。我自己的习惯是每次上线新版本前先用测试账号跑三天看复习队列的召回率再决定要不要改参数。希望帮到你。本文还有配套的精品资源点击获取
