先说结论：这套“基于微信小程序的考研学习系统”，选题方向是对的，技术栈也不冷门。后端SpringBoot、前端微信原生小程序，功能覆盖学习计划、每日打卡、题库刷题、错题本、学习统计和后台管理。作为计算机毕业设计，它兼具工程量适中、演示效果直观、答辩有话可说三个优点。尤其考研复习辅助平台这个场景，学生能理解需求，评委能看懂功能，落地时也不会像电商、外卖那种“烂大街”选题一样被质疑工作量。这个课题适合Java方向、小程序方向，或者想走全栈路线、但又不希望前端玩得太重的同学。我这边带着A同学完整跑过一轮，从需求设计、数据库建模、后端接口、小程序页面，到论文文档和答辩预演都过了一遍，下面把整个开发逻辑、核心细节和踩过的坑一次性讲清楚。1. 需求拆解与技术选型：为什么是SpringBoot + 微信小程序1.1 考研学习系统的核心功能范围动手写代码前，先把需求边界划清楚。考研学习系统不是要把“考虫”“墨墨背单词”那套完整重做，那是商业产品的量级，不是个人毕设的量级。作为毕设系统，功能要做到“看起来完整、演示起来顺畅、代码量又能控制住”。我当时给A同学划定的核心功能是六个模块：用户登录与个人中心：基于微信授权登录，保存昵称、头像、学习天数、连续打卡天数。学习计划管理：按科目（政治、英语、数学、专业课）创建学习计划，包含计划标题、日期、时长、完成状态。每日打卡：针对某条计划进行打卡，记录实际学习分钟数，支持补卡逻辑。题库练习：按科目分类的单选题/多选题/判断题，支持顺序刷题、答案解析。错题本：刷题时自动收集错题，支持标记“已掌握”，从错题本移除。学习统计：展示今日学习时长、打卡日历、累计学习天数、题目正确率。这个功能列表是经过取舍的。比如“在线视频学习”“资料下载”“社区帖子”这些功能我特意让A同学放弃掉了。原因很简单：文件存储、视频转码、内容审核这些模块，会大幅增加后端复杂度和服务器成本，而且对毕设答辩的核心加分点几乎没有贡献。评委想看到的是你“会设计、会实现、会排查问题”，而不是你“堆了多少个页面”。1.2 技术选型的现实逻辑后端选择SpringBoot，理由非常直白：国内Java生态最成熟，SpringBoot的自动配置能让你在几分钟内拉起一个可运行的项目，而且社区资料多，任何一个细节报错都能搜到解决方案。对于毕设阶段而言，这不是炫技的地方，稳妥、快速、可复用才是第一诉求。前端选择微信原生小程序而不是Uniapp或者Vue，我同样给出了自己的理由：原生小程序结构清晰，WXML、WXSS、JS、JSON四个文件各司其职，代码量适中，好写论文。不需要额外编译链路，开发者工具打开就能跑，降低环境配置带来的不可控风险。考研刷题场景天然适合在小程序里做——手机端触屏交互、微信授权登录一步到位、分享传播方便。如果换成本文后面会提到的“管理后台”，我建议用Vue + Element UI，为什么？管理端是电脑浏览器访问，数据表格、表单校验这类场景Vue生态里的组件库效率远高于原生小程序。小程序端做学生操作，管理端做数据维护，这也是前后端分离项目里比较标准的组合。1.3 前后端分离的部署方式项目结构上，后端是一个独立的SpringBoot工程，包含controller、service、mapper、entity、config几个标准分层；前端是微信小程序工程，通过wx.request发起HTTP请求访问后端接口。两者通过RESTful API通信，数据格式统一使用JSON。部署时后端打包成jar，放到服务器用java -jar启动，小程序则通过微信开发者工具上传代码到微信平台审核发布。毕设演示时，如果不想花钱买服务器，后端跑在本机，小程序开发者工具勾选“不校验合法域名”，一样可以完整演示前后端联调效果。这一点后面单独展开。2. 数据库设计：核心表结构直接照这个抄2.1 核心数据表清单数据库是这套系统的地基，表设计不好，后面接口写起来全是泪。我用MySQL设计了一套六张核心表的结构，A同学照着建完之后，接口开发阶段基本没有因为表结构返工。表名用途核心字段user用户信息表id、openid、nickname、avatar、total_days、continuous_daysstudy_plan学习计划表id、user_id、subject、plan_title、plan_date、planned_minutes、status、remarkplan_checkin每日打卡表id、plan_id、user_id、checkin_date、actual_minutes、is_validquestion题目表id、category_id、question_type、content、options、answer、analysis、difficultywrong_question错题本表id、user_id、question_id、user_answer、created_time、is_masteredcategory科目分类表id、name、sort_order这六张表基本覆盖了系统所有业务。你可能注意到一个问题：没建“学习统计表”。原因是我把学习统计数据设计成动态计算，通过聚合study_plan和plan_checkin表获取，而不是冗余存储。这种设计的好处是省去了一致性维护，坏处是统计接口需要写稍微复杂一点的SQL，但只要数据量在个人毕设规模以内，性能完全不是问题。2.2 关键字段的设计逻辑这里面有几个字段值得单独解释。user表的openid。这是微信生态里用户的唯一标识，一个用户对一个小程序只有一个openid。很多人写微信登录时会在这里踩坑：后端通过wx.login拿到的code去微信接口换openid和session_key，这个openid必须存起来，后续所有业务数据都通过它关联用户。注意unionid是同一主体下多个小程序/公众号共用的标识，毕设项目不涉及多应用互通，用openid就够了，千万别混。study_plan表的status字段。我用整数0、1、2分别表示未开始、进行中、已完成。这里有个设计细节：没有直接用布尔值，因为未来可能需要支持“已过期未打卡”的中间状态。很多新手在这里图省事用tinyint(1)，等到要做计划列表的筛选统计时才发现不够用。question表的options字段。我设计成JSON字符串，比如四选一的选择题，options存["A. xxx", "B. xxx", "C. xxx", "D. xxx"]。后端解析时用@JsonFormat转为数组，前端拿到后直接渲染。相比单独建一张选项表，这种设计对固定题型非常友好，写代码节省大量时间，而且在毕设论文里可以用“题目选项较多，采用JSON格式存储以降低表关联复杂度”作为设计理由。2.3 表关联关系梳理表间关系用大白话讲：一个用户可以有多个学习计划，所以user和study_plan是一对多。一个计划可以在不同日期被多次打卡，所以study_plan和plan_checkin是一对多。一个用户会产生多条错题记录，所以user和wrong_question是一对多。一个分类下有多道题目，所以category和question是一对多。这套关系对应到后端MyBatis的Mapper里，就是几个LEFT JOIN或者嵌套查询的事。我建议你在设计阶段就把ER图画出来，画清楚再建表。别急着写代码，ER图不仅是论文里的必备图表，也是自己梳理业务逻辑最有效的方式。3. 后端SpringBoot实现：从工程初始化到核心接口3.1 工程分层与初始化要点SpringBoot工程我建议用Spring Initializr生成，Java版本用8或11都行，别盲目上17——有些学校机房或者服务器JDK版本偏旧，17可能跑不起来（这里补充说明：如果服务器环境是JDK8，代码里有Java 11语法会直接启动报错）。依赖引入spring-boot-starter-web、mybatis-plus-boot-starter、mysql-connector-java、lombok，再加一个jjwt做登录令牌。分包结构按这个来，简单直观：com.example.kaoyan ├── controller // 接口层，接收参数、返回结果 ├── service // 业务逻辑层 ├── mapper // 数据访问层 ├── entity // 数据库实体类 ├── config // 配置类：跨域、拦截器、MybatisPlus配置 └── common // 通用返回类、异常处理、工具类有一点要提醒：entity实体类里的字段命名要和数据库表字段一一对应，建议开下MyBatis-Plus的map-underscore-to-camel-case: true配置，这样数据库的plan_title能自动映射到Java的planTitle，避免一个个写@TableField。3.2 微信登录与JWT鉴权登录是整个系统的基础。流程是：小程序端调用wx.login()拿到临时code，传给后端；后端用code去微信接口jscode2session换取openid；再拿openid查user表，存在就直接登录，不存在就自动注册。换取openid的HTTP请求我直接用RestTemplate实现，配置一个Bean就可以，不需要引入额外依赖。换取成功后会拿到session_key和openid，其中session_key涉及解密手机号等信息时才用，毕设阶段不会涉及，可以忽略。后端校验用户存在后，用JWT生成一个带openid和过期时间的token返回给前端。注意JWT密钥不要硬编码在代码里，放到application.yml配置文件中，用@Value读取。鉴权逻辑我单独写了一个拦截器：除了/api/user/login这个接口放行外，其余接口统一校验请求头里的token。解析token拿到openid后，把openid塞进ThreadLocal或者请求参数里，后续业务接口直接用。这样设计的优势是，你只需要写一次校验逻辑，所有接口自动获得登录保护。如果你对拦截器不熟，也有个偷懒的方案：用自定义注解配合AOP切面实现。但个人建议用拦截器，代码量更少，论文里也好描述——“基于拦截器的统一登录校验机制”。3.3 学习计划与打卡接口实现计划模块是典型CRUD，但有几个点值得展开。新增计划时，前端会提交userId、subject、planTitle、planDate、plannedMinutes等字段。后端除了入库，还要做一次基础校验——planDate不能是过去日期，否则直接抛业务异常。这里建议用@Validated注解做参数校验，比如@NotBlank、@NotNull，配合全局异常处理器统一返回错误信息，省去每个接口手写if判断。打卡接口就比较有讲究了。它的核心逻辑是：根据planId查到计划，判断计划是否属于当前登录用户——这里容易漏，必须加上用户归属校验，否则A用户可以打卡B用户的计划，属于越权漏洞。判断当天是否已经打卡，如果已打卡，提示“今日已打卡”。写入plan_checkin记录，并更新study_plan的status为已完成。返回今日打卡时长和累计连续天数。连续天数计算是我单独写了一个工具方法：查用户最近所有打卡日期，从今天往前数，如果昨天没打卡，连续天数就归1；如果昨天打卡了，就从日期序列连续递增。这里涉及一个细节：用LocalDate比较日期，不要用Date，否则时区差会让你在边界情况下出错。3.4 题库与错题本接口实现题库接口相对简单，分页查询题目列表，按categoryId筛选。我用MyBatis-Plus的Page对象做分页，接口返回total、records两个字段，前端配合wx:for渲染，配合onReachBottom做上拉加载更多。刷题提交接口需要考虑的一点是：用户提交答案后，后端比对question表里的answer字段，返回correct布尔值。如果错误，自动写入wrong_question表，记录用户提交的答案和题目ID。这里有个小坑——用户重复刷同一道题时会生成多条错题记录，去重逻辑建议在错题本查询处做，查询时按question_id分组取最新一条。错题本接口我提供了三个：list查询错题列表、mastered标记已掌握、delete移除错题。论文里的“错题闭环管理”就是这么来的：刷题产生错题 → 错题本查看 → 巩固后标记掌握 → 错题移除。3.5 学习统计接口实现统计接口用SQL聚合实现，返回五块数据：今日学习分钟数、累计学习天数、连续打卡天数、今日完成计划数、总刷题数与正确率。核心SQL类似：SELECT IFNULL(SUM(actual_minutes), 0) AS today_minutes FROM plan_checkin WHERE user_id = #{userId} AND checkin_date = CURDATE()这里强烈建议前端不要循环查接口拿统计，比如“连续打卡天数”用一次循环查几十个接口，前端性能差，后端也扛不住。全部聚合到一个接口返回，前端一次请求全部拿到。这也是答辩时一个加分细节：你写的是“减少HTTP请求次数，优化接口性能”，一句话就能体现你的工程意识。4. 小程序前端：页面结构、请求封装与核心交互4.1 页面目录规划微信小程序的页面我分成五个Tab和若干子页面：pages/ ├── index/ // 首页：学习数据总览、今日计划 ├── plan/ // 计划页：计划列表、新增计划 ├── quiz/ // 刷题页：分类刷题、答题 ├── wrong/ // 错题本页 └── mine/ // 个人中心：用户信息、累计数据子页面包括新增计划页、答题详情页、计划详情页、打卡日历页。页面多不要紧，关键是每个页面功能单一，避免一个大页面几百行代码。首页布局我建议采用“顶部统计卡片 + 中间打卡日历 + 下方今日计划列表”的结构。统计卡片展示今日学习时长、连续打卡天数、累计天数，数据全部来自后端/api/stats/summary接口。4.2 请求封装与登录态管理小程序端不能像Web一样直接调接口，wx.request需要封装。我在utils/request.js里统一封装了请求方法，核心逻辑包括：拼接接口前缀、自动携带token、统一错误拦截、401时跳转重新登录。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.code === 200) { resolve(res.data.data); } else if (res.data.code === 401) { wx.navigateTo({ url: '/pages/login/login' }); } else { wx.showToast({ title: res.data.msg, icon: 'none' }); } }, fail: (err) => reject(err) }); }); };baseUrl我放在app.js的globalData里，开发时用http://localhost:8080，部署时改成服务器域名。这里有个很多人忽略的问题：baseUrl不能写死在每个页面里，改起来会崩溃，必须全局统一管理。4.3 每日打卡与刷题交互打卡的核心交互是“点击打卡 → 请求后端 → 更新UI”，有一个交互细节值得说。打卡成功后，不要只是弹一个toast，计划项的status要立即变为“已完成”，今日统计卡片的数值也要同步刷新。我用的是一个自定义事件：打卡成功后通过getApp().globalData.eventBus触发首页刷新。小程序里没有Vue那种全局事件，我会在app.js里放一个简单的订阅器，或者用wx.eventCenter，实现不足二十行，但交互体验会比“打卡后还要手动刷新页面”好一个档次。刷题页的交互核心是答题反馈。用户点击选项后，先本地判断选中的答案与正确选项是否一致，立即高亮正确/错误选项，再异步调用后端提交接口。这样用户体验上没有等待感，后端就算稍慢也不影响答题反馈。这里要特别注意：提交答案时要把questionId和userAnswer一起传，后端才能比对并记录错题。4.4 图表与数据展示统计页面我引入了echarts-for-weixin组件库来画打卡日历热力图和刷题正确率趋势图。这个组件本质是ECharts的微信小程序适配版，使用前需要把组件目录完整复制到components下，然后在页面json文件中注册组件。使用上有几个坑：图表容器的width/height必须在WXSS里写死，不能依赖内容撑开，否则画布会显示空白；数据加载要在onReady里再初始化，不能放在onLoad里，否则容器尺寸还没渲染完成；图表配置项和ECharts官网一致，照抄官方示例即可。如果你觉得引入图表组件太麻烦，退而求其次的做法是使用Canvas手绘柱状图。虽然工作量稍大，但论文里可以写“基于Canvas自定义绘制图表”，也是个亮点。A同学最终用了ECharts方案，因为在演示时图表更美观。5. 前后端联调与避坑：这些坑我全都踩过5.1 本地联调时的网络配置很多同学第一次做前后端分离，最容易卡死在第一步：小程序请求http://localhost:8080，结果真机预览直接报“request:fail”。原因有两个层面：一是小程序真机上localhost指向手机自己，不是你的电脑；二是微信平台要求请求域名必须是HTTPS且完成备案，开发阶段可以在“详情-本地设置”里勾选“不校验合法域名”。网络层面的正确操作是：后端启动时，SpringBoot默认监听8080端口，绑定0.0.0.0，保证局域网内可访问。小程序端baseUrl改为你电脑的局域网IP，比如http://192.168.1.5:8080。手机和电脑连同一个WiFi。这三步做完，真机调试基本就能通了。5.2 token失效和登录态丢失小程序端最常见的报错是接口返回401。出现这个现象，先不要急着改后端，检查三处：登录成功时是否wx.setStorageSync('token', token)存了token；请求封装里header字段是否写成了headers——这个一眼看不出来，报错会让你怀疑人生；token过期策略。JWT过期时间我设的是7天，小程序冷启动后会从storage里读取token，如果后端校验失败，需要跳转到登录页重新登录。还有一个容易忽略的逻辑：用户访问受保护接口时，后端拦截器抛出401，前端跳转登录页，但登录页的登录流程是静默的——小程序端wx.login()获得code、调后端、拿到token，整个过程中用户不需要输入任何东西，这就是“静默登录”。这样设计用户体验最好，不会在演示时出现尴尬的登录页面。5.3 跨域、日期、字段映射问题跨域问题在后端解决。SpringBoot里注册一个CorsFilter全局配置，允许localhost和127.0.0.1访问，否则浏览器类调试工具（比如你后端接口放到某个云开发控制台测试时）会报跨域错误。小程序端本身没有浏览器同源策略限制，所以如果只在微信开发者工具里跑，跨域问题不会出现，但为了后用，还是建议后端加一个CORS配置。日期问题主要出现在打卡日期和“今天是几号”的判断上。我统一在后端返回给前端的日期格式为yyyy-MM-dd，前端拿到后直接显示。前端提交日期时，用new Date()拼接成年月日字符串，而不是传时间戳。只要约定好“接口传输的一律是字符串日期”，时区问题基本不会出现。字段映射问题就是前后端字段名一致性。后端返回的userId，前端数据里写的却是user_id，这种低级错误会浪费大量排查时间。我的习惯是：后端统一驼峰命名返回，前端定义数据模型时完全按后端字段名对齐。如果嫌敲字麻烦，直接复制后端返回的JSON结构到前端变量定义处，最稳妥。5.4 常见问题速查表问题现象可能原因解决方案小程序请求一直pending，最后超时后端没启动，或端口不对，或开错服务先确认后端控制台有启动日志、端口是8080登录返回code无效wx.login拿到的code过期，或者把code和openid搞混每次登录重新调用wx.login，不要缓存code接口返回404后端路径与前端请求路径不一致打开开发者工具Network面板，比对实际请求URL数据库存中文变??数据库连接串未配置characterEncoding=utf-8在JDBC URL加?characterEncoding=utf-8计划列表查不到数据用户ID传的是登录之前的临时值统一从token解析用户身份，不要信前端的userId真机打卡日期差一天手机时区与服务器时区不一致日期统一用字符串传输，后端用LocalDate.now()MyBatis查询列名不对数据库下划线字段和实体驼峰字段映射失败打开MyBatis-Plus驼峰映射配置这里特别提醒一下“用户ID传的是登录之前的临时值”的问题。A同学曾经在首页没登录的情况下先请求了计划列表，后端自然查不到数据。后来我在每个业务接口里都从token解析用户身份，前端不再传userId参数。这样做既保证了安全性，也省去前端各种传参的麻烦。6. 文档撰写与答辩准备：让毕设不只是“能跑”6.1 论文（LW）结构怎么安排说明文档/论文是毕设的硬指标，很多同学代码跑通了、论文憋不出来。实际上论文结构是有套路可循的，按下面这个大纲写，内容会很自然：绪论：研究背景、意义、国内外现状、主要工作。相关技术介绍：SpringBoot、微信小程序、MyBatis-Plus、MySQL。系统需求分析：可行性分析、功能需求、非功能需求。系统设计：总体架构、功能模块设计、数据库设计。系统实现：按模块写核心代码逻辑和界面截图。系统测试：功能测试用例、部分性能说明。写论文时有个关键技巧：把每个功能模块的实现章节和代码结合起来，不要只贴大段代码，而是在关键代码处加一段设计说明。比如打卡模块，先写“本模块的核心逻辑是判断用户当天的打卡状态，避免重复打卡”，再贴localDateTime判断的核心代码片段。这样的论文读起来才像“设计”，而不是代码堆砌。6.2 图表怎么画论文里的图建议这几张：系统架构图：小程序端、后端、数据库三层结构，用简单的框线图表示。功能模块图：树状图展示系统功能分解。用例图：说明学生、管理员各自的操作权限。数据库ER图：把前文六张表及其关系画出来。核心业务流程图：比如刷题流程、打卡流程。这些图画的时候用Visio、ProcessOn或者Draw.io都行，重要的是图要清晰、标注完整。不要直接从网上截图，会被查重和学术规范检查盯上。图表完成后，论文里每张图都要有“图编号+图名+一句话说明”。6.3 答辩高频问题准备清单答辩老师大概率会围绕这几个方向提问，提前准备就不会现场卡壳：为什么选这个课题？你的系统相比市面上考研App有什么不同？SpringBoot相比SSM框架的优势是什么？数据库为什么这样设计？表间关系是什么？你是如何保证系统安全性的？（回答思路：JWT鉴权、拦截器统一校验、后端对用户归属校验、参数校验）如果用户量变大，系统哪里会出现瓶颈？你打算怎么优化？（回答思路：分页查询、数据库索引、缓存热点数据）项目的难点和亮点分别是什么？（建议回答：连续打卡算法和多条件统计的聚合查询）这些问题都不算刁钻，关键是你要真的理解自己的代码。我见过太多学生论文写得很好，但被问到“你这个查询为什么要加索引”时直接愣住。写论文的过程，本质上也是逼自己把每个设计决定想清楚的过程。最后再分享一点A同学这个项目从零到一，大概用了三周时间，第一周建库写后端，第二周写小程序端，第三周联调、写论文、准备答辩。节奏比较稳，主要是因为他提前把表结构和接口文档定好了，前后端开发时不需要互相等。如果你也想跑一遍这个流程，我建议你拿到需求后别急着敲代码，先花一天时间把ER图和接口清单列出来。接口清单就写接口名、请求方式、路径、参数、返回内容。这一步看着简单，却能省掉后面至少一半的返工时间。调试过程中最值得记住的一句话是：报错不可怕，可怕的是不看报错信息直接乱猜。SpringBoot的报错日志、小程序开发者工具的Console面板，都把问题指得很明白了，养成先看日志、再定位代码的习惯，这个项目你会做得很顺畅。
先说结论：这套“基于微信小程序的考研学习系统”，选题方向是对的，技术栈也不冷门。后端SpringBoot、前端微信原生小程序，功能覆盖学习计划、每日打卡、题库刷题、错题本、学习统计和后台管理。作为计算机毕业设计，它兼具工程量适中、演示效果直观、答辩有话可说三个优点。尤其考研复习辅助平台这个场景，学生能理解需求，评委能看懂功能，落地时也不会像电商、外卖那种“烂大街”选题一样被质疑工作量。这个课题适合Java方向、小程序方向，或者想走全栈路线、但又不希望前端玩得太重的同学。我这边带着A同学完整跑过一轮，从需求设计、数据库建模、后端接口、小程序页面，到论文文档和答辩预演都过了一遍，下面把整个开发逻辑、核心细节和踩过的坑一次性讲清楚。1. 需求拆解与技术选型：为什么是SpringBoot + 微信小程序1.1 考研学习系统的核心功能范围动手写代码前，先把需求边界划清楚。考研学习系统不是要把“考虫”“墨墨背单词”那套完整重做，那是商业产品的量级，不是个人毕设的量级。作为毕设系统，功能要做到“看起来完整、演示起来顺畅、代码量又能控制住”。我当时给A同学划定的核心功能是六个模块：用户登录与个人中心：基于微信授权登录，保存昵称、头像、学习天数、连续打卡天数。学习计划管理：按科目（政治、英语、数学、专业课）创建学习计划，包含计划标题、日期、时长、完成状态。每日打卡：针对某条计划进行打卡，记录实际学习分钟数，支持补卡逻辑。题库练习：按科目分类的单选题/多选题/判断题，支持顺序刷题、答案解析。错题本：刷题时自动收集错题，支持标记“已掌握”，从错题本移除。学习统计：展示今日学习时长、打卡日历、累计学习天数、题目正确率。这个功能列表是经过取舍的。比如“在线视频学习”“资料下载”“社区帖子”这些功能我特意让A同学放弃掉了。原因很简单：文件存储、视频转码、内容审核这些模块，会大幅增加后端复杂度和服务器成本，而且对毕设答辩的核心加分点几乎没有贡献。评委想看到的是你“会设计、会实现、会排查问题”，而不是你“堆了多少个页面”。1.2 技术选型的现实逻辑后端选择SpringBoot，理由非常直白：国内Java生态最成熟，SpringBoot的自动配置能让你在几分钟内拉起一个可运行的项目，而且社区资料多，任何一个细节报错都能搜到解决方案。对于毕设阶段而言，这不是炫技的地方，稳妥、快速、可复用才是第一诉求。前端选择微信原生小程序而不是Uniapp或者Vue，我同样给出了自己的理由：原生小程序结构清晰，WXML、WXSS、JS、JSON四个文件各司其职，代码量适中，好写论文。不需要额外编译链路，开发者工具打开就能跑，降低环境配置带来的不可控风险。考研刷题场景天然适合在小程序里做——手机端触屏交互、微信授权登录一步到位、分享传播方便。如果换成本文后面会提到的“管理后台”，我建议用Vue + Element UI，为什么？管理端是电脑浏览器访问，数据表格、表单校验这类场景Vue生态里的组件库效率远高于原生小程序。小程序端做学生操作，管理端做数据维护，这也是前后端分离项目里比较标准的组合。1.3 前后端分离的部署方式项目结构上，后端是一个独立的SpringBoot工程，包含controller、service、mapper、entity、config几个标准分层；前端是微信小程序工程，通过wx.request发起HTTP请求访问后端接口。两者通过RESTful API通信，数据格式统一使用JSON。部署时后端打包成jar，放到服务器用java -jar启动，小程序则通过微信开发者工具上传代码到微信平台审核发布。毕设演示时，如果不想花钱买服务器，后端跑在本机，小程序开发者工具勾选“不校验合法域名”，一样可以完整演示前后端联调效果。这一点后面单独展开。2. 数据库设计：核心表结构直接照这个抄2.1 核心数据表清单数据库是这套系统的地基，表设计不好，后面接口写起来全是泪。我用MySQL设计了一套六张核心表的结构，A同学照着建完之后，接口开发阶段基本没有因为表结构返工。表名用途核心字段user用户信息表id、openid、nickname、avatar、total_days、continuous_daysstudy_plan学习计划表id、user_id、subject、plan_title、plan_date、planned_minutes、status、remarkplan_checkin每日打卡表id、plan_id、user_id、checkin_date、actual_minutes、is_validquestion题目表id、category_id、question_type、content、options、answer、analysis、difficultywrong_question错题本表id、user_id、question_id、user_answer、created_time、is_masteredcategory科目分类表id、name、sort_order这六张表基本覆盖了系统所有业务。你可能注意到一个问题：没建“学习统计表”。原因是我把学习统计数据设计成动态计算，通过聚合study_plan和plan_checkin表获取，而不是冗余存储。这种设计的好处是省去了一致性维护，坏处是统计接口需要写稍微复杂一点的SQL，但只要数据量在个人毕设规模以内，性能完全不是问题。2.2 关键字段的设计逻辑这里面有几个字段值得单独解释。user表的openid。这是微信生态里用户的唯一标识，一个用户对一个小程序只有一个openid。很多人写微信登录时会在这里踩坑：后端通过wx.login拿到的code去微信接口换openid和session_key，这个openid必须存起来，后续所有业务数据都通过它关联用户。注意unionid是同一主体下多个小程序/公众号共用的标识，毕设项目不涉及多应用互通，用openid就够了，千万别混。study_plan表的status字段。我用整数0、1、2分别表示未开始、进行中、已完成。这里有个设计细节：没有直接用布尔值，因为未来可能需要支持“已过期未打卡”的中间状态。很多新手在这里图省事用tinyint(1)，等到要做计划列表的筛选统计时才发现不够用。question表的options字段。我设计成JSON字符串，比如四选一的选择题，options存["A. xxx", "B. xxx", "C. xxx", "D. xxx"]。后端解析时用@JsonFormat转为数组，前端拿到后直接渲染。相比单独建一张选项表，这种设计对固定题型非常友好，写代码节省大量时间，而且在毕设论文里可以用“题目选项较多，采用JSON格式存储以降低表关联复杂度”作为设计理由。2.3 表关联关系梳理表间关系用大白话讲：一个用户可以有多个学习计划，所以user和study_plan是一对多。一个计划可以在不同日期被多次打卡，所以study_plan和plan_checkin是一对多。一个用户会产生多条错题记录，所以user和wrong_question是一对多。一个分类下有多道题目，所以category和question是一对多。这套关系对应到后端MyBatis的Mapper里，就是几个LEFT JOIN或者嵌套查询的事。我建议你在设计阶段就把ER图画出来，画清楚再建表。别急着写代码，ER图不仅是论文里的必备图表，也是自己梳理业务逻辑最有效的方式。3. 后端SpringBoot实现：从工程初始化到核心接口3.1 工程分层与初始化要点SpringBoot工程我建议用Spring Initializr生成，Java版本用8或11都行，别盲目上17——有些学校机房或者服务器JDK版本偏旧，17可能跑不起来（这里补充说明：如果服务器环境是JDK8，代码里有Java 11语法会直接启动报错）。依赖引入spring-boot-starter-web、mybatis-plus-boot-starter、mysql-connector-java、lombok，再加一个jjwt做登录令牌。分包结构按这个来，简单直观：com.example.kaoyan ├── controller // 接口层，接收参数、返回结果 ├── service // 业务逻辑层 ├── mapper // 数据访问层 ├── entity // 数据库实体类 ├── config // 配置类：跨域、拦截器、MybatisPlus配置 └── common // 通用返回类、异常处理、工具类有一点要提醒：entity实体类里的字段命名要和数据库表字段一一对应，建议开下MyBatis-Plus的map-underscore-to-camel-case: true配置，这样数据库的plan_title能自动映射到Java的planTitle，避免一个个写@TableField。3.2 微信登录与JWT鉴权登录是整个系统的基础。流程是：小程序端调用wx.login()拿到临时code，传给后端；后端用code去微信接口jscode2session换取openid；再拿openid查user表，存在就直接登录，不存在就自动注册。换取openid的HTTP请求我直接用RestTemplate实现，配置一个Bean就可以，不需要引入额外依赖。换取成功后会拿到session_key和openid，其中session_key涉及解密手机号等信息时才用，毕设阶段不会涉及，可以忽略。后端校验用户存在后，用JWT生成一个带openid和过期时间的token返回给前端。注意JWT密钥不要硬编码在代码里，放到application.yml配置文件中，用@Value读取。鉴权逻辑我单独写了一个拦截器：除了/api/user/login这个接口放行外，其余接口统一校验请求头里的token。解析token拿到openid后，把openid塞进ThreadLocal或者请求参数里，后续业务接口直接用。这样设计的优势是，你只需要写一次校验逻辑，所有接口自动获得登录保护。如果你对拦截器不熟，也有个偷懒的方案：用自定义注解配合AOP切面实现。但个人建议用拦截器，代码量更少，论文里也好描述——“基于拦截器的统一登录校验机制”。3.3 学习计划与打卡接口实现计划模块是典型CRUD，但有几个点值得展开。新增计划时，前端会提交userId、subject、planTitle、planDate、plannedMinutes等字段。后端除了入库，还要做一次基础校验——planDate不能是过去日期，否则直接抛业务异常。这里建议用@Validated注解做参数校验，比如@NotBlank、@NotNull，配合全局异常处理器统一返回错误信息，省去每个接口手写if判断。打卡接口就比较有讲究了。它的核心逻辑是：根据planId查到计划，判断计划是否属于当前登录用户——这里容易漏，必须加上用户归属校验，否则A用户可以打卡B用户的计划，属于越权漏洞。判断当天是否已经打卡，如果已打卡，提示“今日已打卡”。写入plan_checkin记录，并更新study_plan的status为已完成。返回今日打卡时长和累计连续天数。连续天数计算是我单独写了一个工具方法：查用户最近所有打卡日期，从今天往前数，如果昨天没打卡，连续天数就归1；如果昨天打卡了，就从日期序列连续递增。这里涉及一个细节：用LocalDate比较日期，不要用Date，否则时区差会让你在边界情况下出错。3.4 题库与错题本接口实现题库接口相对简单，分页查询题目列表，按categoryId筛选。我用MyBatis-Plus的Page对象做分页，接口返回total、records两个字段，前端配合wx:for渲染，配合onReachBottom做上拉加载更多。刷题提交接口需要考虑的一点是：用户提交答案后，后端比对question表里的answer字段，返回correct布尔值。如果错误，自动写入wrong_question表，记录用户提交的答案和题目ID。这里有个小坑——用户重复刷同一道题时会生成多条错题记录，去重逻辑建议在错题本查询处做，查询时按question_id分组取最新一条。错题本接口我提供了三个：list查询错题列表、mastered标记已掌握、delete移除错题。论文里的“错题闭环管理”就是这么来的：刷题产生错题 → 错题本查看 → 巩固后标记掌握 → 错题移除。3.5 学习统计接口实现统计接口用SQL聚合实现，返回五块数据：今日学习分钟数、累计学习天数、连续打卡天数、今日完成计划数、总刷题数与正确率。核心SQL类似：SELECT IFNULL(SUM(actual_minutes), 0) AS today_minutes FROM plan_checkin WHERE user_id = #{userId} AND checkin_date = CURDATE()这里强烈建议前端不要循环查接口拿统计，比如“连续打卡天数”用一次循环查几十个接口，前端性能差，后端也扛不住。全部聚合到一个接口返回，前端一次请求全部拿到。这也是答辩时一个加分细节：你写的是“减少HTTP请求次数，优化接口性能”，一句话就能体现你的工程意识。4. 小程序前端：页面结构、请求封装与核心交互4.1 页面目录规划微信小程序的页面我分成五个Tab和若干子页面：pages/ ├── index/ // 首页：学习数据总览、今日计划 ├── plan/ // 计划页：计划列表、新增计划 ├── quiz/ // 刷题页：分类刷题、答题 ├── wrong/ // 错题本页 └── mine/ // 个人中心：用户信息、累计数据子页面包括新增计划页、答题详情页、计划详情页、打卡日历页。页面多不要紧，关键是每个页面功能单一，避免一个大页面几百行代码。首页布局我建议采用“顶部统计卡片 + 中间打卡日历 + 下方今日计划列表”的结构。统计卡片展示今日学习时长、连续打卡天数、累计天数，数据全部来自后端/api/stats/summary接口。4.2 请求封装与登录态管理小程序端不能像Web一样直接调接口，wx.request需要封装。我在utils/request.js里统一封装了请求方法，核心逻辑包括：拼接接口前缀、自动携带token、统一错误拦截、401时跳转重新登录。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.code === 200) { resolve(res.data.data); } else if (res.data.code === 401) { wx.navigateTo({ url: '/pages/login/login' }); } else { wx.showToast({ title: res.data.msg, icon: 'none' }); } }, fail: (err) => reject(err) }); }); };baseUrl我放在app.js的globalData里，开发时用http://localhost:8080，部署时改成服务器域名。这里有个很多人忽略的问题：baseUrl不能写死在每个页面里，改起来会崩溃，必须全局统一管理。4.3 每日打卡与刷题交互打卡的核心交互是“点击打卡 → 请求后端 → 更新UI”，有一个交互细节值得说。打卡成功后，不要只是弹一个toast，计划项的status要立即变为“已完成”，今日统计卡片的数值也要同步刷新。我用的是一个自定义事件：打卡成功后通过getApp().globalData.eventBus触发首页刷新。小程序里没有Vue那种全局事件，我会在app.js里放一个简单的订阅器，或者用wx.eventCenter，实现不足二十行，但交互体验会比“打卡后还要手动刷新页面”好一个档次。刷题页的交互核心是答题反馈。用户点击选项后，先本地判断选中的答案与正确选项是否一致，立即高亮正确/错误选项，再异步调用后端提交接口。这样用户体验上没有等待感，后端就算稍慢也不影响答题反馈。这里要特别注意：提交答案时要把questionId和userAnswer一起传，后端才能比对并记录错题。4.4 图表与数据展示统计页面我引入了echarts-for-weixin组件库来画打卡日历热力图和刷题正确率趋势图。这个组件本质是ECharts的微信小程序适配版，使用前需要把组件目录完整复制到components下，然后在页面json文件中注册组件。使用上有几个坑：图表容器的width/height必须在WXSS里写死，不能依赖内容撑开，否则画布会显示空白；数据加载要在onReady里再初始化，不能放在onLoad里，否则容器尺寸还没渲染完成；图表配置项和ECharts官网一致，照抄官方示例即可。如果你觉得引入图表组件太麻烦，退而求其次的做法是使用Canvas手绘柱状图。虽然工作量稍大，但论文里可以写“基于Canvas自定义绘制图表”，也是个亮点。A同学最终用了ECharts方案，因为在演示时图表更美观。5. 前后端联调与避坑：这些坑我全都踩过5.1 本地联调时的网络配置很多同学第一次做前后端分离，最容易卡死在第一步：小程序请求http://localhost:8080，结果真机预览直接报“request:fail”。原因有两个层面：一是小程序真机上localhost指向手机自己，不是你的电脑；二是微信平台要求请求域名必须是HTTPS且完成备案，开发阶段可以在“详情-本地设置”里勾选“不校验合法域名”。网络层面的正确操作是：后端启动时，SpringBoot默认监听8080端口，绑定0.0.0.0，保证局域网内可访问。小程序端baseUrl改为你电脑的局域网IP，比如http://192.168.1.5:8080。手机和电脑连同一个WiFi。这三步做完，真机调试基本就能通了。5.2 token失效和登录态丢失小程序端最常见的报错是接口返回401。出现这个现象，先不要急着改后端，检查三处：登录成功时是否wx.setStorageSync('token', token)存了token；请求封装里header字段是否写成了headers——这个一眼看不出来，报错会让你怀疑人生；token过期策略。JWT过期时间我设的是7天，小程序冷启动后会从storage里读取token，如果后端校验失败，需要跳转到登录页重新登录。还有一个容易忽略的逻辑：用户访问受保护接口时，后端拦截器抛出401，前端跳转登录页，但登录页的登录流程是静默的——小程序端wx.login()获得code、调后端、拿到token，整个过程中用户不需要输入任何东西，这就是“静默登录”。这样设计用户体验最好，不会在演示时出现尴尬的登录页面。5.3 跨域、日期、字段映射问题跨域问题在后端解决。SpringBoot里注册一个CorsFilter全局配置，允许localhost和127.0.0.1访问，否则浏览器类调试工具（比如你后端接口放到某个云开发控制台测试时）会报跨域错误。小程序端本身没有浏览器同源策略限制，所以如果只在微信开发者工具里跑，跨域问题不会出现，但为了后用，还是建议后端加一个CORS配置。日期问题主要出现在打卡日期和“今天是几号”的判断上。我统一在后端返回给前端的日期格式为yyyy-MM-dd，前端拿到后直接显示。前端提交日期时，用new Date()拼接成年月日字符串，而不是传时间戳。只要约定好“接口传输的一律是字符串日期”，时区问题基本不会出现。字段映射问题就是前后端字段名一致性。后端返回的userId，前端数据里写的却是user_id，这种低级错误会浪费大量排查时间。我的习惯是：后端统一驼峰命名返回，前端定义数据模型时完全按后端字段名对齐。如果嫌敲字麻烦，直接复制后端返回的JSON结构到前端变量定义处，最稳妥。5.4 常见问题速查表问题现象可能原因解决方案小程序请求一直pending，最后超时后端没启动，或端口不对，或开错服务先确认后端控制台有启动日志、端口是8080登录返回code无效wx.login拿到的code过期，或者把code和openid搞混每次登录重新调用wx.login，不要缓存code接口返回404后端路径与前端请求路径不一致打开开发者工具Network面板，比对实际请求URL数据库存中文变??数据库连接串未配置characterEncoding=utf-8在JDBC URL加?characterEncoding=utf-8计划列表查不到数据用户ID传的是登录之前的临时值统一从token解析用户身份，不要信前端的userId真机打卡日期差一天手机时区与服务器时区不一致日期统一用字符串传输，后端用LocalDate.now()MyBatis查询列名不对数据库下划线字段和实体驼峰字段映射失败打开MyBatis-Plus驼峰映射配置这里特别提醒一下“用户ID传的是登录之前的临时值”的问题。A同学曾经在首页没登录的情况下先请求了计划列表，后端自然查不到数据。后来我在每个业务接口里都从token解析用户身份，前端不再传userId参数。这样做既保证了安全性，也省去前端各种传参的麻烦。6. 文档撰写与答辩准备：让毕设不只是“能跑”6.1 论文（LW）结构怎么安排说明文档/论文是毕设的硬指标，很多同学代码跑通了、论文憋不出来。实际上论文结构是有套路可循的，按下面这个大纲写，内容会很自然：绪论：研究背景、意义、国内外现状、主要工作。相关技术介绍：SpringBoot、微信小程序、MyBatis-Plus、MySQL。系统需求分析：可行性分析、功能需求、非功能需求。系统设计：总体架构、功能模块设计、数据库设计。系统实现：按模块写核心代码逻辑和界面截图。系统测试：功能测试用例、部分性能说明。写论文时有个关键技巧：把每个功能模块的实现章节和代码结合起来，不要只贴大段代码，而是在关键代码处加一段设计说明。比如打卡模块，先写“本模块的核心逻辑是判断用户当天的打卡状态，避免重复打卡”，再贴localDateTime判断的核心代码片段。这样的论文读起来才像“设计”，而不是代码堆砌。6.2 图表怎么画论文里的图建议这几张：系统架构图：小程序端、后端、数据库三层结构，用简单的框线图表示。功能模块图：树状图展示系统功能分解。用例图：说明学生、管理员各自的操作权限。数据库ER图：把前文六张表及其关系画出来。核心业务流程图：比如刷题流程、打卡流程。这些图画的时候用Visio、ProcessOn或者Draw.io都行，重要的是图要清晰、标注完整。不要直接从网上截图，会被查重和学术规范检查盯上。图表完成后，论文里每张图都要有“图编号+图名+一句话说明”。6.3 答辩高频问题准备清单答辩老师大概率会围绕这几个方向提问，提前准备就不会现场卡壳：为什么选这个课题？你的系统相比市面上考研App有什么不同？SpringBoot相比SSM框架的优势是什么？数据库为什么这样设计？表间关系是什么？你是如何保证系统安全性的？（回答思路：JWT鉴权、拦截器统一校验、后端对用户归属校验、参数校验）如果用户量变大，系统哪里会出现瓶颈？你打算怎么优化？（回答思路：分页查询、数据库索引、缓存热点数据）项目的难点和亮点分别是什么？（建议回答：连续打卡算法和多条件统计的聚合查询）这些问题都不算刁钻，关键是你要真的理解自己的代码。我见过太多学生论文写得很好，但被问到“你这个查询为什么要加索引”时直接愣住。写论文的过程，本质上也是逼自己把每个设计决定想清楚的过程。最后再分享一点A同学这个项目从零到一，大概用了三周时间，第一周建库写后端，第二周写小程序端，第三周联调、写论文、准备答辩。节奏比较稳，主要是因为他提前把表结构和接口文档定好了，前后端开发时不需要互相等。如果你也想跑一遍这个流程，我建议你拿到需求后别急着敲代码，先花一天时间把ER图和接口清单列出来。接口清单就写接口名、请求方式、路径、参数、返回内容。这一步看着简单，却能省掉后面至少一半的返工时间。调试过程中最值得记住的一句话是：报错不可怕，可怕的是不看报错信息直接乱猜。SpringBoot的报错日志、小程序开发者工具的Console面板，都把问题指得很明白了，养成先看日志、再定位代码的习惯，这个项目你会做得很顺畅。