简介：这是一套面向教育培训机构的全栈教务管理解决方案，适用于Java后端、Vue前端及微信小程序开发者学习与二次开发，解决多校区协同、招生分销、直播教学等典型教育数字化场景中的系统集成难题。资源包共359个文件，含260个Java核心业务代码（涵盖RedisUtils、WxProperties、ExcelUtil等实用工具类）、27个PNG界面图标与1张JPG宣传图、4个XML配置及2个YAML服务参数文件，辅以.gitignore、LICENSE、README.md等工程规范文件，整体压缩包仅6.98MB，轻量易部署。目前已有68人学习下载，适合中高级开发者快速掌握SpringBoot+Vue+小程序三端联动架构设计与教务领域建模方法。读者可直接运行PC后台与小程序双端演示，深入理解课程排期、财务稽核、团体报名等模块的接口定义与状态流转逻辑，并基于模块化结构灵活裁剪功能。 最近在整理一套实际落地过的教务管理系统，刚好有朋友问起整个技术方案和源码结构，我干脆把当初从搭建到部署的完整过程沉淀成文。这套系统基于SpringBoot + Vue，同时集成了微信小程序端和PC管理后台，覆盖了学校/培训机构最常见的教务场景——学生管理、教师排课、选课、成绩录入与查询、课表查看、班级管理这些。无论你是想快速搭一套自己的教务系统，还是想找一个多端联动的完整落地案例参考，这篇文章都能派上用场。
先交代一下背景：我之前参与过的项目里，很多客户一开始的需求只有"做个课表管理"，但真正用起来之后，往往发现PC后台管理排课简单，学生和老师不可能天天守着电脑，他们更需要手机端查课表、查成绩、请假。所以这套系统在设计之初就按"PC管理后台为管理侧、微信小程序为师生侧"的思路来拆。后端统一提供RESTful API，前端两套各自消费，数据模型完全共用，整体架构不算复杂，但胜在实用，能覆盖真实业务流。
- 整体系统设计与技术选型
1.1 为什么选SpringBoot + Vue这套组合
技术选型这块，我当时没有太多纠结，核心原因就三点。第一，SpringBoot在Java生态里几乎是企业级后端的事实标准，生态成熟、资料多、团队招人容易，遇到问题能搜到的解决方案数量级比别的框架高太多。第二，Vue在国内前端圈的渗透率极高，尤其是管理后台类项目，Element UI / Element Plus这种组件库直接把后台页面开发效率拉满，不需要从零造轮子。第三，前后端分离的架构可以让PC后台和微信小程序端共用同一套API，移动端不需要单独再写一套后端逻辑，这是多端系统能高效维护的前提。
教务系统这种业务，本质上就是人和数据的关系管理。后端要做的是把学生、教师、课程、班级、选课关系、成绩记录等实体之间的关系理清楚，并提供一组稳定的CRUD和业务接口。前端要做的是把这些数据以不同的视角展示给不同角色。PC后台管理端是"上帝视角"，管全局；小程序端是"个人视角"，看自己的课表和成绩。这套视角分离的思路，直接决定了我后面数据库表结构和接口设计的方式。
1.2 系统整体架构：前后端分离下的多端复用
整体架构我按经典的三层方式拆：表现层（PC管理后台 + 微信小程序）、接口层（SpringBoot RESTful API）、数据层（MySQL）。表现层和接口层通过HTTP + JSON通信，JWT做身份认证。有人会问，为什么不用Spring Cloud那套微服务？教务管理系统在高并发上并没有那么极端的压力，单体应用配合合理的缓存和索引完全够用。而且越是多端项目，越要控制后端复杂度，微服务带来的分布式事务、服务治理成本，对这种业务体量来说是负收益。
整个请求链路是这样一个流程：小程序端或PC端发起请求，带上JWT Token，后端通过拦截器校验身份并解析角色权限，然后调用Service层业务逻辑，最终通过MyBatis-Plus操作MySQL。业务上涉及到的核心模块有：用户认证、学生/教师管理、课程管理、班级管理、选课、排课、成绩管理、课表查询、公告通知。
前端（Vue3 + Element Plus / 微信小程序原生） ↕ HTTP + JSON + JWT SpringBoot + Spring Security + MyBatis-Plus ↕ MySQL（核心业务数据） + Redis（缓存/验证码/Token黑名单）这里Redis不是必需品，但建议加上。教务系统虽然并发不高，但选课高峰期会有短时集中访问，用Redis缓存热点数据（比如课表、公告）效果非常明显。另外验证码、Token刷新这些场景用Redis也比数据库存储方便得多。
1.3 核心功能模块拆解
整个系统的功能模块，我按用户角色来划分。PC管理后台的管理员，拥有最高权限，可以管理所有基础数据和系统配置。教师端（PC后台或小程序）可以查看自己的授课课表、录入学生成绩、发布课程通知。学生端（小程序为主）可以选课、查看课表、查成绩、请假申请、接收公告。
具体的功能清单大致如下：
- 系统管理：用户管理、角色管理、菜单管理、操作日志
- 教务管理：学期管理、班级管理、课程管理、教室管理、排课管理
- 学生管理：学生信息维护、学籍状态、班级分配
- 教师管理：教师信息维护、授课安排
- 选课中心：学生选课/退课、选课时间控制、选课统计
- 成绩管理：成绩录入、成绩审核、成绩查询与导出
- 课表模块：按班级/教师/教室维度生成课表视图
- 个人中心：小程序端登录、查看通知、请假审批
这套模块拆分的核心逻辑是"基础数据先行，业务动作在后"。先把课程、班级、教室、教师、学生这些基础数据维护好，选课、排课、成绩这些业务动作才有意义。很多新手开发教务系统容易一上来就写选课逻辑，结果发现班级和课程关系没定义清楚，程序里全是补丁，这点要特别注意。
- 后端核心实现与关键细节
2.1 SpringBoot项目结构与依赖配置
后端我用的SpringBoot 2.7.x版本，为什么不用3.x？原因很实在：3.x要求JDK17起步，很多生产环境的服务器还停留在JDK8，而且部分老牌库对Jakarta命名空间的适配还有坑。2.7.x是2.x的终极版本，稳定性和生态兼容性都相对理想，适合直接部署到客户机器上。JDK用的1.8，这在企业项目里仍然是最稳妥的组合。
项目结构按模块分包，清晰比花哨重要：
com.example.edusystem ├── config // 配置类：MyBatis-Plus、Cors、Interceptor、Redis ├── controller // 接口层 ├── service // 业务逻辑层 ├── mapper // MyBatis-Plus的Mapper接口 ├── entity // 数据库实体 ├── dto // 前端请求/响应对象 ├── vo // 视图对象 ├── utils // 工具类：JWT、日期处理等 ├── exception // 统一异常处理 └── EduApplication.java核心依赖没搞太多花活，就是SpringBoot Web、Spring Security、MyBatis-Plus、MySQL驱动、Redis、JWT（jjwt）、Lombok、Hutool工具库。Hutool是个好东西，日期处理、Excel导出、加密这些工具方法直接拿来用，少写很多重复代码。
2.2 MyBatis-Plus配置与多表查询设计
数据库操作这块我选了MyBatis-Plus，说实话主要是懒。单表CRUD完全不用写SQL，内置的LambdaQueryWrapper写条件查询非常舒服，比如按照班级ID查学生列表、按照学期查课程列表，几行代码就搞定。多表关联查询还是老老实实写XML里的自定义SQL，因为教务系统里像"学生选课列表——带出课程名、教师名、学分"这种场景，关联查询用SQL表达最清晰，也最容易优化。
举个例子，查询某学生某学期的选课列表，对应SQL大致是：
SELECT c.id AS course_id, c.course_name, c.credit, t.teacher_name, sc.status, sc.score FROM t_student_course sc INNER JOIN t_course c ON sc.course_id = c.id INNER JOIN t_teacher t ON c.teacher_id = t.id WHERE sc.student_id = #{studentId} AND c.semester_id = #{semesterId} ORDER BY c.course_name这种SQL建议写在Mapper XML里，用@Select注解也行，但项目一大还是XML好维护，至少格式化、看执行计划都方便。有个实际经验：关联查询尽量只查需要的字段，不要SELECT *，尤其是课程表字段多的时候，能省不少IO。
分页用的MyBatis-Plus自带的分页插件，配置一个PaginationInnerInterceptor就行。需要注意，分页插件必须配置数据库类型，否则生成的count语句可能不兼容。
2.3 JWT认证与Spring Security权限控制
教务系统涉及三种角色——管理员、教师、学生，权限必须严格区分。学生不能去调删除课程的接口，教师不能改其他教师的课程信息。我是用Spring Security + JWT做认证和授权的。
认证流程这样走：
- 用户登录（管理员/教师走PC端，学生走小程序端），后端校验用户名密码
- 校验通过后，签发JWT Token，把用户ID、角色、过期时间放进去
- 前端拿到Token后，每次请求放在Header的Authorization字段里
- 后端写一个JwtAuthenticationFilter，解析Token并设置SecurityContext
- 在接口上用@PreAuthorize("hasRole('ADMIN')")这类注解做细粒度权限控制
JWT有个坑要提醒一下：Token一旦签发，在过期之前是无法主动失效的。用户修改密码、被封禁这些场景，Token还是有效的。解决办法是我在Redis里维护了一个Token黑名单，登出接口把Token加入黑名单并且设置和Token相同的过期时间，每次请求过滤器先查一次黑名单。多一次Redis查询，但安全性提升明显，值得。
Spring Security配置这块，我不建议用默认的登录页和表单登录，还是走无状态模式，关闭Session，所有接口除了登录、验证码等少数几个白名单，一律要认证。
http.csrf().disable() .sessionManagement().sessionCreationPolicy(SessionCreationPolicy.STATELESS) .and() .authorizeRequests() .antMatchers("/api/auth/login", "/api/captcha").permitAll() .antMatchers("/api/admin/**").hasRole("ADMIN") .antMatchers("/api/teacher/**").hasAnyRole("TEACHER", "ADMIN") .antMatchers("/api/student/**").hasAnyRole("STUDENT", "ADMIN") .anyRequest().authenticated();小程序端的登录是个特殊场景。学生没有用户名密码，直接用它微信登录后的code，后端调用微信接口换openid，再拿openid查学生表，查到就自动注册/登录。第一次登录时如果学生已经由管理员导入到系统里，就绑定openid和学号；如果没有导入，我当时的做法是拒绝登录，提示"联系管理员导入信息"，避免陌生人随便注册进来。
2.4 小程序接口的幂等与防重复提交
教务系统里有一个典型的并发问题——选课。学生选课时，前端会先查询可选课程列表，然后点击选课提交。如果网络卡顿，用户连续点了两次，就可能产生两条选课记录。解决思路是在后端做一个幂等控制：选课接口先查t_student_course表里是否已有该学生和该课程的记录，有就返回"已选过"，没有才插入。同时数据库层面给student_id和course_id建联合唯一索引，双保险，哪怕并发穿透到了数据库，也会因为唯一约束只插入一条成功记录。
这一条经验其实适用范围很广，凡是"用户手动提交"的操作，比如报名、下单、提交申请，都要考虑重复提交的问题。用唯一索引兜底是最简单可靠的方案，没有之一。
- PC管理后台与Vue前端实现
3.1 Vue3 + Element Plus搭建管理后台
PC管理后台用的是Vue3 + Vite + Element Plus + Pinia + Vue Router。Vite比Webpack快太多了，开发体验完全是两个世界；Pinia作为Vue3的官方推荐状态管理库，比Vuex的语法简洁不少，改起来也顺手。
管理后台整体布局就是左侧菜单栏 + 顶部导航栏 + 右侧内容区。菜单根据登录用户的角色动态生成，这里的数据来自后端接口（菜单表和角色菜单关联表），前端根据返回值渲染侧边栏。这样做的好处是新增菜单不用重新发版，管理员配一下菜单表就行。
路由权限控制是这类后台项目的核心点。我的做法是在Vue Router的全局前置守卫里做两件事：一是判断是否已登录，没登录跳转到登录页；二是根据后端返回的权限码（权限标识集合），用router.addRoute动态添加该用户有权限访问的路由。这样做到了菜单显示和路由跳转的双重控制，用户就算在地址栏手动输入一个无权限的URL，也会被拦下来跳到404页面。
3.2 核心页面实现要点
课表管理是教务系统里最"有技术含量"的页面。PC后台的课表展示，我用的是Element Plus的el-table，把星期作为列、节次作为行，每节课的格子合并显示课程信息，支持点击课程单元格弹出编辑窗口。这里用到了el-table的span-method方法实现单元格合并，逻辑不难，但要注意计算开始节次和持续节次后合并行数要正确，不然课表格子错位，调试起来很麻烦。
动态刷新这块，我用Vue的watch监听当前选中的班级ID，变化后重新请求课表数据。
学生选课这个高频操作，前端做了两个限制：选课时间段显示，不在开放时间内按钮置灰；学分上限控制，已选学分超过上限时提示不能再选。这两个校验前端做一遍，后端接口再做一遍。前端做是为了用户体验，后端做是为了数据安全，千万别指望前端校验能挡得住什么。
PC管理后台涉及大量表单页面，比如学生信息录入、课程信息维护。这类页面我抽了一套通用的form-dialog组件，传入配置项自动渲染表单控件，减少重复代码。实践中非常好用，新加一个模块的录入页面基本半小时能搞定。
3.3 与后端联调技巧：封装请求与拦截器
管理后台的HTTP请求统一封装在request.js里，基于Axios。请求拦截器做两件事：从Pinia里取Token并加到Header的Authorization字段；如果是FormData格式的请求，设置正确的Content-Type。响应拦截器做了统一错误处理：后端返回的约定格式是{ code: 200, data: ..., message: "..." }，code不是200时Toast提示message；HTTP状态401时说明Token过期或无效，清除本地登录态并跳转到登录页。
请求拦截： config.headers.Authorization = 'Bearer ' + token 响应拦截： if (res.data.code !== 200) { Message.error(res.data.message); return Promise.reject(); } if (status === 401) { logout(); router.push('/login'); }这套封装要尽早做好。项目开发期接口来回改，如果每个页面都单独写一遍请求和错误处理，后期重构的时候你会想哭。
- 微信小程序端开发实战
4.1 小程序端技术选型与页面结构
微信小程序端我没有用uni-app，而是直接用的原生小程序开发。原因有两个：一是项目里微信小程序的功能相对固定，不需要跨平台；二是原生小程序对微信API的支持最及时，学起来也直接。当然，如果你考虑将来还要做支付宝小程序，那用uni-app更合适，这个可以根据实际需求取舍。
小程序端页面结构分这几块：
- 登录页：微信一键登录，调后端接口换Token
- 首页：当前学期课表卡片、最新公告、待办事项（请假审批等）
- 课表页：按周展示课程时间表
- 选课页：可选的课程列表、已选课程列表、选课/退课操作
- 成绩页：学期成绩查询、成绩统计
- 我的页面：个人信息、请假申请、设置
底部TabBar我用的是三个Tab：首页、课表、我的。选课和成绩放在首页的快捷入口，避免TabBar太挤。
4.2 小程序登录与Token管理
小程序登录链路相对特殊，这里详细说一下。wx.login()拿到临时code，把code传给后端，后端用code向微信接口换openid（和session_key），然后查数据库绑定学生账号。绑定成功后签发自己的JWT Token返回给前端。前端把Token存入wx.setStorageSync，后续所有请求的Header都带上。
有个细节：小程序的wx.request不支持像Axios那样直接设置请求拦截器，必须封装一层。我写了一个request工具函数，内部统一做Token注入、响应拦截、错误提示，这样页面里调用请求跟用Axios差不多，不用每个页面重复处理Token和错误码。
4.3 分包异步化与加载性能优化
这里要单独说说分包。随着课程图片、课件资料加进来，小程序主包体积很容易超过2M限制。我的做法是：主包只放TabBar对应的页面和公共组件；选课详情、成绩详情、请假申请这些低频页面全部放到分包里，在用户进入时按需加载。实践中还用了微信的"分包异步化"能力，在分包页面里通过require.async动态引用子包中的公共模块，避免同步引用导致的分包体积冗余。
我还观察到一个新手常踩的坑：把图片资源也放在项目文件夹里，这会让包体积瞬间爆炸。正确做法是把图片全部上传到CDN或后端OSS，页面里只存URL。项目里我建了一个config.js，集中维护CDN域名和API基础地址，不同环境改这一个文件就行。
4.4 小程序端适配问题的处理经验
小程序适配最容易出问题的就是顶部导航栏。不同机型（刘海屏、挖孔屏）的安全区域不一样，我用wx.getSystemInfoSync()获取状态栏高度和胶囊按钮位置，动态计算导航栏高度。封装了一个nav-bar组件，所有页面统一使用，避免每个页面各写一套导致高度不一致。
还有一个常见需求：视频课件播放。如果课件视频是m3u8格式的，小程序原生video组件不支持这种流媒体格式。解决思路有两个：一是后端转码成MP4，但对服务端有额外压力；二是集成第三方播放器插件，比如腾讯云的播放器SDK或者ByteDance播放器，它们支持HLS协议。考虑到集成成本，我直接在后端做了转码方案，课件上传时用FFmpeg转成HLS并输出m3u8和ts分片，小程序端用第三方组件播放。这一块如果你的业务涉及视频，建议提前规划，别等上线了再补。
4.5 小程序表单与交互细节
小程序端的学生请假功能，表单里有几个常用的组件：日期选择器、文本输入框、单选框（请假类型），这些用小程序原生组件就够了。不过有一个细节要注意：原生表单组件在不同机型上的样式差异比较大，尤其是单选框。我的做法是隐藏原生radio，用自定义样式的view模拟选中态，视觉统一且不容易出现样式错乱。
另一个容易被忽略的细节是表单提交的防重复点击。小程序里按钮的loading状态要好好利用，提交时按钮显示loading并禁用点击，防止用户重复提交产生多条申请。提交成功后再跳转，不要提前跳，避免后端还在处理请求页面却关了。
- 部署、环境配置与常见问题排查
5.1 前后端分离部署方案
后端部署在生产环境我用的Linux服务器 + Docker Compose。数据库MySQL、Redis各起一个容器，SpringBoot应用单独一个容器。nginx直接部署在宿主机上，负责三件事：托管PC管理后台的静态文件；反向代理/api请求到SpringBoot容器；处理HTTPS证书。小程序端不需要部署，但它的API请求要走HTTPS，并且域名必须在小程序后台配置到request合法域名里。
docker-compose.yml的大致内容如下（简化）：
version: '3' services: mysql: image: mysql:5.7 environment: MYSQL_ROOT_PASSWORD: xxx volumes: - ./mysql-data:/var/lib/mysql redis: image: redis:6-alpine app: build: . depends_on: - mysql - redis ports: - "8080:8080"SpringBoot的配置文件里要注意，生产环境的数据库地址、Redis地址不要用localhost，要用服务名（mysql、redis），这样容器间才能互相访问。用Docker部署还有个好处：服务器换环境时，一条docker-compose up -d就把全套服务拉起来了，不用手动装JDK、MySQL、Redis，省了很多运维精力。
5.2 跨域问题排查
前后端分离开发时最常遇到的就是跨域。在开发环境，Vite配置proxy代理，把/api开头的请求代理到后端8080端口，浏览器不会产生跨域问题。但生产环境如果用小程序的请求，它没有跨域的概念，只有PC后台的浏览器访问才会触发。
如果你在生产环境发现浏览器访问接口报CORS错误，先确认浏览器实际请求的URL是不是nginx转发后的地址，再看后端是否配置了CorsFilter。我后端的跨域处理是在config里写一个CorsFilter，放行所有来源，并设置允许的Header包含Authorization。注意如果用了Spring Security，CORS配置必须在Security过滤链之前生效，否则请求在安全过滤器就被拦了，CORS配置等于白写。
排查步骤： 1. 浏览器F12查看请求URL，确认是否走了代理 2. 看请求头Origin是否正常 3. 确认后端CorsFilter是否配置了Access-Control-Allow-Origin 4. 确认Spring Security是否放行了OPTIONS请求5.3 小程序抓包与联调技巧
小程序联调时，我强烈建议学会抓包。微信开发者工具自带的Network面板能看到请求和响应，但对于排查一些真机上的问题，开发者工具模拟不出来。要抓真机小程序的包，可以用Charles或Reqable这类工具，在电脑上开启HTTPS代理，手机WiFi代理指向电脑，再给手机安装Charles的CA证书，就能看到小程序发的每一个请求。
实际操作中，第一次抓包最后一步有个常见坑：Android 7.0以上的系统，默认不信任用户安装的CA证书，需要把证书安装到系统证书目录里（要求已经root），或者小程序开发版勾选"不校验合法域名"。所以最简单的方式是：在微信开发者工具中，勾选"详情 -> 本地设置 -> 不校验合法域名"，开发阶段这样大大降低联调成本。
5.4 常见问题速查表
实际开发和后期维护中，我把碰到的高频问题整理成了一张速查表，方便团队新成员快速定位：
| 现象 | 可能原因 | 解决方案 |
|---|---|---|
| 登录后请求401 | Token过期或Header未正确携带 | 检查请求拦截器，确认Authorization字段格式为Bearer + 空格 + Token |
| 小程序加载白屏 | 分包引用路径错误或基础库版本过低 | 检查分包异步化引用，确认页面路径在小程序app.json中正确注册 |
| 课表格子错乱 | el-table span-method计算的行列数不对 | 打印合并的行列索引，逐个核对节次边界 |
| 前端请求跨域 | nginx未配置代理或CorsFilter缺失 | 检查nginx location /api的proxy_pass，确认CorsFilter放行 |
| 数据库连接超时 | 容器IP变化或连接池配置偏小 | 使用服务名代替IP，调大HikariCP的maximum-pool-size |
| 导出Excel乱码 | Hutool导出时未处理响应头编码 | 设置Content-Type为application/vnd.ms-excel，编码UTF-8 |
| 选课并发重复 | 前端重复提交且后端无唯一约束 | 后端加幂等校验和联合唯一索引 |
- 开发过程中踩过的坑与经验总结
有不少问题在写代码的时候根本想不到，只有等数据量上来、并发上来才会暴露。这里分享几个亲身经历，希望能帮你少走弯路。
关于数据库设计，我一开始把学生、用户、教师三个表拆得太细，后来发现联表查询很麻烦。学生和用户其实可以合并成一张user表，用role字段区分，学生扩展信息单独一张student_profile表。教务系统的核心查询场景是"按人查数据"，用户表拆得太碎，每个查询都要多join一次，性能和开发效率都不理想。
JWT过期时间这个坑也值得说说。当初图省事把Token过期时间设置成了7天，学生不用频繁登录，体验是好了，但安全隐患也大了——Token泄露后7天内都能被冒用。后来我把Token改成2小时过期，配合RefreshToken机制，刷新Token保存在Redis里，有效期7天，过期前自动换取新Token。安全性好了，用户体验也没降太多。
小程序端的资源加载，还有一个容易忽略的点：图片懒加载。课表、公告里的图片比较多，如果一次性全加载，小程序页面的onShow会明显卡顿。使用image组件的lazy-load属性，配合CDN上的合理尺寸压缩，首屏加载速度快很多。真机上测试最明显，同一个页面，优化前加载要三秒多，优化后基本秒开。
关于日志，我强烈建议后端把关键业务操作都记录下来。我在系统里写了一个简单的AOP切面，用@Log注解标注需要记录的方法，自动记录操作人、操作类型、请求参数、耗时。这个日志功能看起来不起眼，但在线上排查问题时简直是救命稻草。比如学生反馈"我明明选了课，为什么选课记录没了"，查一下操作日志，发现是管理员在后台误删了记录，责任清晰，不用互相扯皮。
最后说一句运维方面的经验。教务系统一般都涉及学期切换，每次新学期的开始，课表要重新排、选课要重新开放、成绩期次要更新。我在系统里设计了"学期复制"功能，管理员可以一键把上学期的班级、课程结构复制到新学期，再手动微调排课。这个功能开发成本不高，但能让系统上线后第一次换学期省掉大量重复录入工作，实用性非常高。
如果你准备基于这套架构做二次开发，我建议优先扩展以下几个方向：消息推送（新公告、成绩发布时通过微信订阅消息通知学生）、数据报表（成绩分布、选课热度分析）、在线考试模块。这些都是教务系统后续最常见的需求点，而且完全可以在现有架构上平滑增加，不需要推到重来。
回到最初的问题——为什么一定要做多端？因为教务系统的使用场景天然是分裂的：管理者在办公室用PC、教师在教室用手机、学生在宿舍用小程序。一个系统要真正被用起来，必须让每个角色都在最顺手的地方完成操作。PC管理后台负责复杂管理操作，小程序负责高频轻量查询，两边共用同一套后端逻辑，这也是现在大多数业务系统的理想形态。希望这篇实战总结能给你一些参考。
本文还有配套的精品资源，点击获取
