简介：这份资源是面向高校学生与Java初学者的一份完整毕业设计文档，主题为基于微信小程序的四六级词汇学习系统，帮助备考四六级的用户随时随地进行词汇管理与学习。文档围绕系统分析、功能设计与技术实现展开，涵盖微信开发者工具、小程序框架与目录结构、Java语言、MySQL数据库及SSM框架等关键技术，并包含需求分析、可行性分析、系统设计与实现等完整章节，可作为课程设计或毕业设计的参考模板。资源包共1个docx文件，大小约3.79MB，内容结构完整、目录清晰，便于按章节查阅与二次修改。目前已有30人学习下载，适合需要小程序开发实战案例、想了解SSM与小程序结合方式，或正在准备相关论文与答辩的读者参考借鉴。
1. 从一份 docx 到能跑的小程序：四六级词汇系统到底要解决什么
每年四六级报名前后，总有一批同学在群里问「有没有那种能按高频词、真题词分类背单词的小程序」。市面上背单词 App 不少，但要么广告多，要么词库和四六级考纲对不上，要么强制付费。于是「基于微信小程序的四六级词汇系统」这类课程设计题目就冒出来了——它看起来是个学生作业，实际上是一个完整的全栈落地场景：微信小程序做前端，Java 做后端，MySQL 存词库和用户数据，SSM 框架把三层串起来。
这个系统的核心诉求很明确：用户打开小程序就能查词、背词、做测试，后台能管理词库和用户记录。它适合三类人：一是正在做课程设计或毕业设计的同学，需要一个能讲清楚架构、能演示、能写进论文的完整项目；二是想从零学微信小程序 + Java 后端的开发者，需要一个有真实业务逻辑的练手项目；三是英语老师或培训机构，想低成本搭一个内部用的词汇工具。接下来我会按「架构怎么定 → 数据库怎么建 → 后端怎么写 → 小程序怎么调 → 坑在哪」的顺序，把这条链路拆开讲清楚。
2. 架构选型：为什么是微信小程序 + SSM，而不是 uniapp 或 Spring Boot
2.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 Boot
SSM（Spring + 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只负责参数校验和返回 JSON，service写业务规则（比如「每天最多背 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`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; -- 用户表：微信 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`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; -- 学习记录表：记录每个用户对每个词的状态 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`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;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) { List<Word> wordList = EasyExcel.read(filePath) .head(Word.class) // 表头映射到 Word 字段 .sheet() .doReadSync(); // 分批插入，每批 500 条，避免单条 SQL 过长 for (int i = 0; i < wordList.size(); i += 500) { List<Word> 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 UPDATE：
INSERT 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，传给后端，后端用code+appid+secret调微信接口换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_type=authorization_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 后面加allowPublicKeyRetrieval=true&useSSL=false，或者把用户的认证插件改成mysql_native_password。生产环境建议用 SSL 连接，不要图省事关掉。
5.3 音标和特殊字符存进去变成问号
现象：词库里phonetic字段存的是/ˈæpl/，查出来变成/?æpl/。原因：数据库、表、连接三处的字符集不一致。解决：建库时用CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci，JDBC URL 加characterEncoding=utf8，小程序端wx.request的header里content-type用application/json而不是application/x-www-form-urlencoded。三处都对齐后音标就不会乱码。
5.4 背词页快速点击导致重复提交
现象：用户连续快速点「认识」，同一个词被提交多次，学习记录里wrong_count异常累加。原因：submitRecord是异步的，没有防抖，每次点击都发请求。解决：在data里加一个submitting标志，请求发出前设为true，回调里设为false，submitting为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里的天数。我自己的习惯是每次上线新版本前，先用测试账号跑三天，看复习队列的召回率，再决定要不要改参数。希望帮到你。
本文还有配套的精品资源，点击获取
