Spring Boot+微信小程序：午托晚托课后服务平台毕设实战解析

每年到毕设选题的季节，我总能在各种技术交流群里看到同一类问题："Java毕设做什么题好？""Spring Boot项目有什么推荐的？"。大多数人的第一反应是商城、博客、课程系统，但等我带过几届学生做完这些题目之后，越来越体会到一件事——真正好做的毕设，不是功能最多、名字最响亮的，而是业务边界清晰、你身边就能找到真实用户去验证的场景。今天聊的这款基于Spring Boot + 微信小程序的午托晚托培训机构课后服务平台，就是这类题目的典型代表。它要做的事很简单：让托管机构里排队的家长、盯作业的老师、管账的老板，都有一块自己能看懂的屏幕。

如果你正在准备Java方向的毕业设计，或者想找一个短平快的Spring Boot练手项目，这篇文章值得读完。我会从选题逻辑、业务拆解、后端表设计、小程序端实现，一直聊到调试部署和答辩准备，把整个项目从0到1的完整思路和自己的实操经验都倒出来。

1. 毕设选题时，我为什么反复推荐"课后服务类"业务系统

1.1 真正的市场切口在"课后托管"而非"电商商城"

先说个现象。每年都会看到大量同学选"网上商城""图书管理系统"这类题目，不是不能做，而是做完之后很难出彩。商城类项目要面对商品规格、购物车、订单状态机、支付回调这些复杂逻辑，学生往往做到一半就开始临阵砍功能，最后交上去的是一个"半个商城"；图书管理系统则功能太薄，基本就是增删改查的简单堆叠，答辩时评委一句"这不就是有界面的数据库操作吗"就能把你问住。

午托晚托课后服务平台不一样。它属于"课后服务"细分场景，在"双减"政策落地之后，课后托管、午托晚托、作业辅导已经成为很多家庭的刚需，市场规模和真实需求都非常清晰。你去任意一家托管机构门口蹲半小时，就能看到完整的业务链条：家长送孩子过来、老师点名签到、孩子写作业、老师拍照反馈、家长月底结算托管费。这个场景不需要去网上扒需求文档，你身边的亲戚、邻居、同学就是用户。

更重要的是，这类业务的用户角色非常立体：机构管理员要管全局，老师要管班级和作业，家长要随时看孩子的状态。三方角色天然形成权限差异和业务闭环，这恰恰是评委想看到的"系统设计能力"。

1.2 一个午托晚托平台覆盖了Java后端必修的全部考点

我之所以反复推荐这类题目，还在于它的技术覆盖面非常契合Java方向毕设的评分标准。Spring Boot是主框架，MyBatis-Plus操作MySQL，Redis做缓存和token存储，JWT处理登录鉴权，小程序端用HTTP接口与后端通信——这套组合等于把Java后端毕业设计的核心考点全部覆盖了。

最关键的一点在于，这个项目的"业务复杂度"是可调节的。如果你只想求稳，那就做基础版：学生管理、签到管理、作业管理、缴费管理四个模块，完成一个标准的CRUD + 权限控制闭环，足够通过答辩。如果你想把系统做深，可以在同一个骨架上继续加排课、餐食记录、考勤统计报表、消息订阅推送。也就是说，同一套设计能匹配不同水平的同学，不会出现"题目太大做不完"或者"题目太小没内容"的尴尬。

另外，从面试或者求职的角度来说，"课后服务平台"这种表达真实业务场景的项目，比"某某管理系统"听起来更有说服力。它能体现你理解真实业务流程，知道怎么把一个线下场景抽象成数据表和接口，这种能力恰恰是很多初级开发岗位看重的。

2. 先把业务流程捋顺，再谈建表：机构、老师、家长三方看板

2.1 三方角色的权限与页面边界

做任何系统，我都习惯先把角色和用户故事理清楚，再动手写代码。这套平台的核心角色有三个：

• 机构管理员，一般就是托管机构的负责人或教务。他们关注的是全景数据：今天到了多少孩子、哪些班级还没点名、本月的收费完成率、哪位家长还没交托管费。管理员的操作集中在管理端（小程序端或后台管理页面），负责维护班级、老师账号、课程套餐、收费标准以及发布机构公告。
• 带班老师，是使用频率最高的角色。每天到岗第一件事是打开小程序发起签到或点名，孩子完成作业后要登记作业情况，如果机构提供餐食，老师还需要记录孩子用餐状态。老师在移动端上的操作要尽量快，按钮要少，一个动作要能一步完成，因为真实场景里老师可能一只手拉着两个孩子，另一只手拿手机。
• 家长，是信息接收方。他们最关心的三件事：孩子到没到？孩子饭吃了没？今天留了什么作业？家长端不需要太多操作，主要是查看，所以页面设计上以动态流和状态卡片为主。

在设计权限时，我的做法是后端统一采用"角色字段 + JWT + 注解拦截"的方式，前端小程序根据角色字段渲染不同的TabBar和菜单。管理端和小程序端共用同一套权限校验逻辑，避免出现"接口裸露"的问题——比如家长直接调接口把孩子的签到记录改成已到，这类风险必须在后端拦截，不能指望前端藏按钮。

2.2 核心业务流程串讲：入托、签到、作业、缴费

把角色理清之后，业务主流程就很容易串起来了。我按真实的使用节奏走一遍：

第一个环节是入托报名。家长在小程序端浏览机构信息，选择托管套餐（午托、晚托、午晚托），填写孩子信息并提交报名，管理员在后台审核通过后，孩子正式进入班级。

第二个环节是每日签到。老师早上在班级里发起签到，可以按名单逐个点名，也可以让孩子或家长扫码签到。这里我建议毕设版做"老师手动点名"就够了，扫码签到会引入二维码生成和有效期校验，短期内没必要。签到状态会实时推送给家长，家长在小程序里马上能看到"您的孩子已于11:50到校"。

第三个环节是作业跟踪。晚托的核心任务就是辅导作业，所以作业模块不能只是一个公告板。老师发布作业时按科目和截止时间结构化记录，家长查看时能看到作业要求和完成状态；如果机构允许学生在平台提交作业照片，也可以做一个小型上传闭环。

第四个环节是缴费管理。按月生成托管账单，家长在线查看账单详情，线下转账或线上支付后，管理员在后台确认到账并更新状态。线上支付涉及微信支付商户号申请，个人毕设一般走线下确认流程，这类业务细节我会在后面单独说。

最后是通知触达。机构发布放假通知、调课通知时，系统生成公告并同步显示在家长端首页。基础版用普通公告列表就能跑通，进阶做法是接入微信订阅消息做主动推送，答辩时可以当亮点讲。

3. Spring Boot后端的关键设计和表结构思路

3.1 技术选型要"稳"，版本不要太激进

后端技术栈我推荐一套非常成熟的组合，这也是我实测下来最省心的：

很多同学一上来就追新，直接用Spring Boot 3.x + JDK 21，结果会发现一些老教程里的配置写法已经失效，碰到问题搜到的解决方案又大多针对2.x，白白浪费一周时间。毕设的原则是"稳定压倒一切"，用2.7.x版本，网上任何一个老教程都能照抄，遇到问题也能快速搜到答案。

3.2 核心表结构设计与关系梳理

我建议按下面这张表清单来建库，一共八张核心表就足够支撑整个平台：

• user表：存放三种角色的登录账号，通过type字段区分1=管理员、2=老师、3=家长，统一用手机号+密码或者手机号+短信验证码登录。把三种角色放一张表里，比拆三张用户表简单得多，而且JWT鉴权只需要一个用户ID。
• student表：学生档案。学位字段包括姓名、性别、年龄、学校名称、年级、紧急联系方式、家长ID。这里注意，一个家长可能托管两个孩子，所以家长和学生是一对多关系。
• classes表：班级。托管机构会按年级或跟班老师分班，班级表记录班级名称、带班老师ID、容量。
• student_class表：学生和班级的多对多关联简化版。实际业务里学生可能从A班转到B班，但这个场景在毕设里不需要做历史追溯，只要记录当前班级即可，所以直接在student表里加一个class_id字段也可以。我个人建议单独建关联表，为以后扩展"转班记录"留余地。
• attendance表：每日签到记录，字段包括student_id、class_id、签到日期、签到时间、签到状态（0未到、1已到、2请假）、备注。
• homework表：老师发布的作业，包含title、content、subject、class_id、发布老师ID、截止时间。
• payment_record表：缴费记录，包含student_id、账单月份、应缴金额、实缴金额、缴费状态（0待缴费、1已缴费、2已逾期）、确认人ID。
• notice表：机构公告，包含标题、内容、发布人ID、发布状态、发布时间。

表之间的关系不复杂，核心点在于student是业务锚点，签到、作业、缴费都要落到学生个体身上；而家长查看时又需要通过"家长ID→学生列表→各业务表"这条链路去组织数据。设计接口时要提前想好这种"以孩子为中心"的查询视角。

3.3 JWT身份认证如何区分三种角色

登录和鉴权是整个后端的基石，也是最容易被答辩追问的点。我用的方案是JWT + 拦截器，核心思路如下：

用户登录时，后端校验手机号和密码（密码用BCrypt加密存储），校验通过后用Hutool的JWTUtil生成token，把userId和roleType两个关键信息写进token的payload里，返回给前端。前端每个请求都在Header里带上Authorization: Bearer <token>，后端写一个拦截器统一解析token、放行登录接口和静态资源，其他接口全部走校验。

角色区分不需要引入Spring Security那么重的框架，直接在Controller方法上做一个自定义注解@RequireRole(role = "TEACHER")，拦截器里判断当前用户的角色是否匹配就行。这样做有三个好处：代码量少、逻辑直白、答辩时能说得清楚。如果你用了Spring Security但说不清过滤链原理，反而容易暴露薄弱点。

下面这个统一返回结构是必须提前定义好的，不然接口风格会乱：

java复制@Data
public class Result<T> {
    private Integer code;
    private String message;
    private T data;

    public static <T> Result<T> success(T data) {
        Result<T> r = new Result<>();
        r.code = 200;
        r.message = "ok";
        r.data = data;
        return r;
    }

    public static <T> Result<T> error(Integer code, String message) {
        Result<T> r = new Result<>();
        r.code = code;
        r.message = message;
        return r;
    }
}

登录接口的核心逻辑大致是这样的：

java复制@PostMapping("/login")
public Result<Map<String, Object>> login(@RequestBody LoginDTO dto) {
    // 1. 查用户
    User user = userService.findByPhone(dto.getPhone());
    if (user == null || !BCrypt.checkpw(dto.getPassword(), user.getPassword())) {
        return Result.error(500, "手机号或密码错误");
    }
    // 2. 生成token
    Map<String, Object> payload = new HashMap<>();
    payload.put("userId", user.getId());
    payload.put("role", user.getRole());
    String token = JWTUtil.createToken(payload, secret.getBytes());
    // 3. 组装返回
    Map<String, Object> result = new HashMap<>();
    result.put("token", token);
    result.put("role", user.getRole());
    result.put("userInfo", user);
    return Result.success(result);
}

这一套逻辑可讲的东西足够多了：BCrypt不可逆加密、JWT的无状态特性、拦截器如何排除白名单路径、token过期如何处理。每一条都是答辩时评委爱问的点，提前把代码和原理对齐，心里不慌。

4. 小程序端实现的大框架与常见取舍

4.1 原生小程序 vs uni-app，毕设该选谁

小程序端有两种主流做法：微信原生小程序和uni-app。我个人的建议是：如果你的目标是快速完成毕设，选微信原生小程序；如果你正好在学Vue、想让项目以后有复用价值，可以选uni-app。

原生小程序的好处是文档最全、出错少、微信开发者工具直接运行，不需要多一层编译转换。而且课程设计里老师大概率只关心页面能不能跑通、接口能不能调通，不太在意你用的是不是跨端框架。uni-app的优势是写一套代码可以编译到H5和App，但这个优势对毕设来说不太用得上，反而引入了路由规范、组件差异等额外学习成本。

做完一个原生小程序之后，你会发现微信小程序的开发模式其实很固定：app.json配页面和TabBar，每个页面由wxml、wxss、js、json四件套组成，逻辑通过Page注册，数据绑定用的WXML模板语法。这些知识点网上教程铺天盖地，遇到问题特别好搜。

4.2 登录、请求封装与页面跳转

小程序的登录不能直接拿手机号密码登录，走的应该是微信登录流程：wx.login()拿code，把code传给后端，后端调用微信接口换openid，然后后端拿openid和用户表比对，如果openid已经绑定过就正常登录，否则返回"未绑定"提示，引导用户走手机号绑定流程。

这里有个毕设里的细节：个人主体小程序很多接口权限受限，而且正式AppID需要注册小程序账号才能拿到。最省事的方案是在微信开发者工具里使用"测试号"（AppID为测试号即可），测试号支持wx.login和大部分基础接口，足够毕设演示用。等你真正要上线或现场演示，再换成正式AppID。

整个小程序端的请求层我习惯封装成一个Promise方法，避免每页重复写wx.request：

javascript复制const BASE_URL = "http://localhost:8080/api";

function request(url, method, data) {
  return new Promise((resolve, reject) => {
    wx.request({
      url: BASE_URL + url,
      method,
      data,
      header: {
        "Authorization": "Bearer " + wx.getStorageSync("token")
      },
      success(res) {
        if (res.statusCode === 200 && res.data.code === 200) {
          resolve(res.data.data);
        } else if (res.statusCode === 401) {
          wx.redirectTo({ url: "/pages/login/login" });
        } else {
          reject(res.data);
        }
      },
      fail(err) {
        reject(err);
      }
    });
  });
}

这个封装把token注入、状态码判断、401跳登录三个常见问题一次性解决，后续写页面调接口只需要一行request("/attendance/list", "GET", {})，非常省事。页面跳转上要注意，家长端和老师端建议用两个不同的tabBar，从一进入小程序就根据角色渲染不同入口，这比让所有用户进同一个首页再切换要清爽得多。

4.3 家长端和老师端的功能落点

家长端我做了四个核心页面：首页、消息、账单、我的。

首页是一个孩子列表，每个孩子一张卡片，直接展示当天的签到状态、当前的用餐状态和未读公告数。孩子多于一个时，卡片可以横向滑动，这个交互小程序原生swiper组件就能实现。账单页展示待缴费列表，每笔账单都能看到月份、金额和状态。消息页放机构公告和作业动态。

老师端则是一套高频操作工具：我的班级、今日点名、发布作业、学生花名册。今日点名页默认加载当前班级的学生列表，每个学生后面有"到校""请假"两个主按钮和一个备注入口，点完自动保存并刷新状态。这个页面要做成"高频使用场景"，所以不需要花里胡哨，只要能三步之内完成全班点名就行。

这里有一个容易被忽略的细节：页面数据刷新时机。家长打开小程序时，首页要拉取当天最新签到状态，但是小程序页面的onShow和onLoad各触发时机不同，放在onLoad拉取数据的话，从账单页切回首页时不会刷新。实测中我发现把拉取动作放在onShow里更符合使用直觉，代价是每次显示都会发一次请求，但毕设阶段完全够用。

5. 调试、部署和演示：最容易翻车的三个环节

5.1 本地调试的经典三关：跨域、域名白名单、HTTPS

几乎所有同学都会在这一步卡住，我刚做的时候也一样。先看跨域：后端接口如果部署在localhost:8080，小程序请求域名是localhost不会强制走CORS，但你如果用局域网IP（比如让真机连电脑的热点去访问），后端必须加跨域配置，否则浏览器和真机都会拦截。在Spring Boot里加一个CorsFilter最直接：

java复制@Configuration
public class CorsConfig {
    @Bean
    public CorsFilter corsFilter() {
        CorsConfiguration config = new CorsConfiguration();
        config.addAllowedOriginPattern("*");
        config.addAllowedMethod("*");
        config.addAllowedHeader("*");
        config.setAllowCredentials(true);
        UrlBasedCorsConfigurationSource source = new UrlBasedCorsConfigurationSource();
        source.registerCorsConfiguration("/**", config);
        return new CorsFilter(source);
    }
}

接下来说小程序端的"合法域名"问题。微信开发者工具默认会校验请求域名是否备案且支持HTTPS，本地开发时后端是http://localhost:8080，肯定不满足。微信官方在开发者工具的"详情-本地设置"里提供了一个"不校验合法域名"的调试开关，本地开发可以勾选。这个开关只影响本地调试，项目真正上线时必须在微信公众平台后台配置合法域名并启用HTTPS，这个流程大家心里要有数。

真机调试时不要把请求地址写成localhost，因为手机上的localhost指手机自身。要先把后端和手机连在同一局域网，然后填写你电脑的局域网IP，比如http://192.168.1.101:8080。这一步很多人栽过，我写出来你就不会再踩。

5.2 数据准备工作：演示数据比代码更能撑起答辩

我相信很多同学答辩时经历过这种尴尬：现场演示，数据库里只有一条测试数据，点开班级列表空荡荡，签到一个都没有。项目代码写得再好，空数据页面一展示，视觉效果直接归零。

我强烈建议在项目里加一个DataInitializer这样的数据初始化组件，项目启动时自动检查数据量，如果没有演示数据就自动插入一批。数据不用多，班级3个，学生10个，老师2个，最近7天的签到记录每天都有，作业5条，缴费记录覆盖待缴费、已缴费、逾期三种状态。家长账号可以绑定两个孩子，方便演示"多孩子切换"的亮点。

初始化数据要在开发阶段反复测试，确保管理员登录后看到的统计面板有数字变化，家长端打开后孩子状态是"已到校"。答辩时能流畅点出这些数据背后的业务含义，比空谈"本系统实现了什么功能"有说服力得多。

5.3 部署方案与常见问题

毕设的部署分两种：本地演示和线上访问。大多数学校的答辩主机上跑本地演示就够了，但如果你想让评委随时远程看系统，或者把项目链接写进简历，就需要部署到云服务器。

本地演示要注意MySQL和Redis服务是否开机自启，如果答辩时连不上数据库，整个演示就崩了。线上部署我建议用一台2核4G的入门云服务器，装好JDK、MySQL、Nginx，后端打jar包用nohup java -jar后台运行，前端小程序通过HTTPS域名访问后端接口。如果你没有备案域名和HTTPS证书，也可以退而求其次使用IP加端口的方式，让评委在小程序里打开"开发版"进行体验，这一步最好提前确认学校答辩环境的网络策略。

部署过程中有三个高频问题，我单独列一下：

• MySQL时区问题：JDBC连接串里一定要加serverTimezone=Asia/Shanghai，否则签到时间会比本地时间少8小时。
• 文件上传路径问题：作业照片和多图片上传时，绝对路径在Windows和Linux下分隔符不同，建议用配置项统一管理上传根目录，不要写死。
• 静态资源404：如果你把上传的图片放在本地目录而没有配置Spring Boot静态资源映射，访问图片会404。需要写一个WebMvcConfigurer把本地目录映射成虚拟路径，比如/upload/** -> file:D:/upload/。

这些坑都不难解决，但每一条都是我亲眼见过同学在答辩现场翻车的点，提前处理掉，省去答辩时的慌乱。

6. 毕设文档和答辩准备的四个关键点

6.1 需求分析怎么写才不像抄的

很多学校的毕设文档要求从任务书、开题报告开始写，需求分析部分极其容易写得像百度百科。我的经验是：用场景描述代替功能罗列。

比如写家长需求时，与其写"家长可以查看孩子签到信息"，不如写成："托管机构的家长多为双职工家庭，工作日无法及时到机构接送孩子。家长打开小程序后，需要第一时间确认孩子是否已安全到达机构；下午时段需要知道孩子作业完成进度，以便下班接孩子时不用反复询问老师。"这种写法有真实的使用者画像、使用场景和痛点，评委一看就知道你做过调研而不是复制粘贴。

业务流程图、用例图建议自己用工具画一遍，不用特别复杂，把三方角色和核心用例画清楚就行。画图的过程本身就是梳理系统思路的过程，写代码之前画一遍，后面能少走很多弯路。

6.2 架构图和截图怎么组织

论文里的系统架构图不要画得高深莫测，重点是"前端小程序 + 后端Spring Boot + MySQL/Redis"这条主线要清晰。每一层用什么技术、为什么这么选，写一段简明文字说明即可。报表和统计功能如果有，可以用ECharts画柱状图折线图，截图放在论文里非常提气——比如"本月出勤率趋势""各班学生人数分布"。

功能截图要注意顺序：先截登录页，再截管理员后台，接着截老师端班级点名和作业发布，最后截家长端首页和账单页。这个顺序和答辩演示脚本是同一套逻辑，保证论文和PPT、演示画面三者一致，评委的观看体验才好。

6.3 答辩高频问题与应对思路

根据我的经验，这个项目的答辩问题集中在下面几类，提前准备好答案：

为什么选Spring Boot而不是SSH/SSM？ 回答思路：Spring Boot简化了配置、内嵌Tomcat、生态成熟，适合快速构建独立服务；SSH（Struts+Hibernate+Spring）已经过时，Spring MVC+MyBatis虽然有学习价值，但Spring Boot是当前主流的工程化选择。

JWT和Session有什么区别？ 回答思路：Session存在服务端，需要维持会话状态，分布式环境下要处理session共享；JWT是无状态的，token里带了用户信息，服务端不用存，适合小程序这种多端场景。同时要承认JWT的缺点，比如服务端没法主动让token失效、token太长会增加请求体，这些补充反而显得你理解深入。

签到数据量大了之后怎么优化？ 回答思路：给attendance表的student_id和attendance_date建联合索引；按月份分表；引入Redis缓存当天签到状态。能说出这三层优化，评委基本不会再追问。

账户系统和权限是怎么设计的？ 把user表的type字段方案、JWT角色注入、@RequireRole注解拦截器这套逻辑讲清楚，已经超越大部分毕设作品了。如果能进一步说"未来改成Spring Security + RBAC五张表也只是更多角色场景下的自然演进"，这个回答就圆满了。

6.4 三分钟演示脚本怎么编排

最后做一份演示脚本，打印出来放在手边，答辩现场照着走不容易断篇。我建议的顺序是：管理员登录查看经营看板，进入班级管理查看班级列表；切换到老师账号完成一次"发起点名-记录到校-发布作业"的完整操作；切换到家长账号，打开首页确认孩子签到状态，查看作业详情和待缴费账单；最后回到管理员端，展示数据统计报表的出勤率变化。整个过程控制在三分钟左右，覆盖三方角色和一整条业务主链，每一个页面都要让评委看清。

最后按我个人的习惯，给这个项目留两个可扩展的钩子：一是接入订阅消息，让签到和作业状态主动推到家长；二是加一个简单的月度账单统计报表，用ECharts展示这两点不光能当论里"系统展望"的素材，也是你拿高分时最容易被评委追问、但又有现成实现思路的地方。做毕设最怕的不是技术难，而是项目做完你还说不清自己写了什么。按上面的路线走一遍，代码、文档、演示都对齐，答辩基本就稳了。