1. 项目概述与选题价值1.1 核心需求解析先说结论这是一个典型的Java Web 课程设计/毕业设计级别的完整项目技术组合是当下最主流的SpringBoot 微信小程序 MyBatis面向的场景是高校教务管理。市面上这类项目很多但这个项目最大的价值在于它把微信小程序前端和 SpringBoot 后端串成了一条完整的链路——从小程序端的wx.login获取临时凭证到后端调用微信接口换取 openid再到自定义登录态返回前端这一整套流程跑通了项目的基本骨架就有了。很多初学者卡在“前后端联调”这一关单独跑通 SpringBoot 不难单独写小程序也不难难的是让两边通过 HTTP 协议把数据真正“聊”起来这个项目正好解决这个问题。从功能覆盖面上看教务管理系统该有的模块它都涵盖了学生端选课、查成绩、查课表、教师端录入成绩、管理课程、管理员端用户管理、课程管理、公告发布再加上角色权限控制。这里要提醒一句如果你的目标是做毕业设计功能不需要多到眼花缭乱但必须有一条完整业务闭环比如“学生选课→教师录入成绩→学生查看成绩”这就是一个闭环。面面俱到但每个模块都只做半截答辩时反而容易露怯。这个项目还配了源码所以适合三类人第一类是 Java 后端刚入门、想看看真实项目怎么组织代码结构的人第二类是正在做课程设计、想找一个可靠参考脚手架的人第三类是想快速跑通微信小程序全栈流程、验证自己想法的开发者。接下来我会从技术选型逻辑、核心功能拆解、源码部署步骤和常见坑点这四个方向把这个项目完整讲透。1.2 技术栈选型背后的逻辑为什么用 SpringBoot 而不是传统的 SSMSpring SpringMVC MyBatis因为 SpringBoot 最大的优势是零配置起步。SSM 时代最折磨人的就是那一堆 XML 配置文件applicationContext.xml、spring-mvc.xml、mybatis-config.xml三个文件互相引用稍不留神少写一个mvc:annotation-driven/接口就 404 给你看。SpringBoot 用自动配置把这一切都收了你只需要在application.yml里写上数据源、端口号、MyBatis 映射路径项目就能跑起来。省下来的时间用来专注业务代码这才是正路。为什么前端选微信小程序而不是 H5 网页两点原因一是触达成本低现在学生群体几乎全员微信小程序免安装、扫码即用在高校场景下传播效率远高于“打开浏览器输入网址”二是账号体系现成微信提供了wx.login jscode2session这一整套验证逻辑院校不需要自己搭一套账号系统减少了很多开发量。当然小程序也是有代价的——微信审核机制、API 限制、真机调试麻烦但这些都是后期的“甜蜜烦恼”初期开发利大于弊。MyBatis 作为持久层框架也没什么悬念。国内高校教学和绝大多数中小型项目都用它原因很简单SQL 是你自己写的可控性极强调优空间大对比 JPA/Hibernate 那种“自动生成 SQL”的黑盒机制MyBatis 更适合中国学生和开发者的思维习惯。这个项目用的是注解 XML 混合模式简单的 CRUD 走注解复杂查询写 XML这也是实际生产中最常用的写法。2. 系统架构与数据库设计拆解2.1 前后端分离架构与目录结构整个项目分为两个工程后端是标准的 SpringBoot 工程前端是独立的微信小程序工程。两者通过 HTTP JSON 通信典型的前后端分离架构。这种架构的好处是你接手项目时可以先各管各的——后端用 Postman 测接口前端用 Mock 数据测页面最后再联调排查问题的范围大大缩小。后端工程目录结构我拆给你看这是理解整个项目的钥匙course-system/ ├── src/main/java/com/kaic/ │ ├── controller/ # 控制层——接收HTTP请求做参数校验 │ ├── service/ # 业务层——写核心业务逻辑选课、成绩录入 │ ├── mapper/ # 数据访问层——MyBatis接口直接操作数据库 │ ├── entity/ # 实体类——对应数据库每一张表 │ ├── config/ # 配置类——拦截器、跨域配置等 │ ├── common/ # 公共工具——统一返回结果、异常捕获 │ └── CourseApplication.java # 启动类 ├── src/main/resources/ │ ├── mapper/ # MyBatis的XML映射文件 │ ├── application.yml # 全局配置端口、数据源 │ └── init.sql # 数据库初始化脚本 └── pom.xml # Maven依赖管理这种分层结构其实就是经典的三层架构Controller → Service → Mapper。Controller 只负责“接客”不写业务逻辑Service 只负责“处理事”不直接碰数据库Mapper 只负责“跑腿查数”不关心业务。每一层都只管自己的事后期改需求的时候才不会牵一发动全身。小程序端分页面模块划分更直白pages目录下按角色分目录student选课中心、我的课表、成绩查询、teacher我的课程、成绩录入、admin用户管理、课程管理、数据概览。每个目录下有四个同名文件.wxml页面结构、.wxss页面样式、.js页面逻辑、.json页面配置这就是小程序开发的基本节奏。第一次接触小程序的读者先记住一个点页面跳转靠路由wx.navigateTo是带返回的跳转wx.redirectTo是关闭当前页跳转wx.switchTab是跳转到底部 tab 栏页面三者别搞混。2.2 数据库表设计思路从角色到权限数据库是教务系统最核心的资产。我见过太多课程设计项目用户统一塞进一张表用一个role字段区分角色美其名曰“简化设计”——这在只有一个管理员加两个测试账号的场景下没问题但一旦规模上来三张角色表各管各的权限边界远比一张大而全的表稳得多。这个项目的建表思路是合理的学生表、教师表、管理员表分开建各自维护独立信息再通过统一登录表关联微信 openid。核心表大致是下面这几个表名核心字段作用说明studentid, name, student_no, class_name, openid学生基本信息student_no是学号用作唯一索引teacherid, name, teacher_no, title, openid教师基本信息adminid, name, username, password, openid管理员账号密码需加盐哈希存储courseid, course_name, teacher_id, credit, capacity, selected_count课程表capacity是容量selected_count是已选人数select_courseid, student_id, course_id, status选课记录表status标记选课/退课状态scoreid, student_id, course_id, score, remark成绩表score字段存成绩announcementid, title, content, create_time公告表重点看一下course表和select_course表的设计。课程表里有capacity和selected_count两个字段这其实是一个冗余设计——理论上选课人数可以通过查select_course表count(*)算出来但每次选课都实时 count 一遍并发高的时候数据库压力大。直接用selected_count记录已选人数选课时UPDATE course SET selected_count selected_count 1 WHERE course_id ? AND selected_count capacity一步操作就完成了“原子选课容量校验”。这个设计在生产环境里很常用也是面试官喜欢问的点。另外所有表都建议带上create_time和update_time字段MySQL 8.0 之后可以用DEFAULT CURRENT_TIMESTAMP和ON UPDATE CURRENT_TIMESTAMP自动维护这个习惯要养成。2.3 微信登录鉴权流程小程序与后端的握手协议在微信小程序生态里登录不再是你自己搞一套“输入用户名密码”的流程而是把身份验证这件事托管给微信。整个流程是小程序端调用wx.login()微信返回一个临时凭证code有效期只有 5 分钟且只能用一次小程序把code通过 HTTP 请求发给自己后端后端拿code appid secret去请求微信的jscode2session接口微信返回用户的openid用户在当前小程序的唯一标识和session_key后端拿到openid去数据库查找对应的用户如果查到了就说明是老用户直接生成一个自定义的 token比如 UUID返回给前端如果查不到就按前端传过来的角色参数走注册流程前端拿到 token 之后后续所有请求都带上这个 token后端通过拦截器校验 token 有效性。这里有个关键点jscode2session这个接口必须由后端调不能在小程序端直接调。因为接口需要用到secret这个密钥一旦暴露在客户端代码里相当于你把数据库密码贴在了大门上。这是微信官方规定的安全红线也是很多初学者最容易犯的错误——图省事把请求直接写在前端。这个项目里后端封装了一个WxAuthService专门处理与微信服务器的通信代码结构很清晰。3. 核心功能实现与前后端交互剖析3.1 学生端选课与成绩查询的完整链路选课是教务系统最核心的流程我来拆解一个学生从打开小程序到选课成功的完整请求链路。前端chooseCourse页面加载时会先向后端发送一个 GET 请求/course/list后端 Service 层关联查询course表、teacher表和select_course表把“课程名称、授课老师、学分、容量、已选人数、我是否已选”这些字段拼装成一个 VO 对象返回。前端拿到数据后通过wx:for循环渲染课程卡片列表这是小程序最基础但最核心的列表渲染模式。学生点击“选课”按钮前端发送 POST 请求/course/select请求体里带courseId和studentId后端选课流程分三步走// 伪代码真实代码逻辑会更完整 Transactional public Result selectCourse(Integer courseId, Integer studentId) { // 第一步查课程校验是否存在 Course course courseMapper.selectById(courseId); if (course null) { return Result.error(课程不存在); } // 第二步检查是否已选过防重复选课 Integer count selectCourseMapper.checkExists(studentId, courseId); if (count 0) { return Result.error(不能重复选课); } // 第三步原子更新选课人数带容量校验 int rows courseMapper.updateSelectedCount(courseId); if (rows 0) { return Result.error(课程已满员); } // 写入选课记录 selectCourseMapper.insert(studentId, courseId); return Result.success(选课成功); }注意三个细节第一方法上加了Transactional注解因为“更新课程人数 插入选课记录”是两步操作必须保证要么都成功要么都失败不能出现人数加了但选课记录没写进去的脏数据第二用UPDATE ... SET selected_count selected_count 1 WHERE id ? AND selected_count capacity这种带条件的 SQL 来实现容量控制而不是先 SELECT 再 UPDATE——因为并发场景下先查后改会出现“超卖”问题多人同时选最后一门课都查出还有名额结果实际超过容量了第三前端也要做一层校验按钮在学生已选或课程满员时置灰减少无效请求。成绩查询流程相对简单本质上是一次关联查询score表 LEFT JOINcourse表和teacher表按学期过滤后返回成绩列表。前端用wx:for渲染成表格样式总分和绩点可以放在前端计算也可以后端算好直接返回这个项目里放在了后端理由很简单让数据计算发生在数据所在的地方前端只负责展示。3.2 教师端与管理端权限控制的具体实现教师端最核心的功能是成绩录入。这里有一个好设计教师在myCourse列表页看到自己名下的所有课程点进某一门课之后系统关联查询select_course表和student表列出选了这门课的所有学生名单教师只需要在输入框里填分数然后一键提交。后端接收一个成绩数组批量写入score表个别成绩为空时给出提示避免漏填。权限控制是这个项目的灵魂。后端实现方式可以是一个简单的 Spring Boot 拦截器HandlerInterceptor在preHandle方法里校验请求头中的 token再根据 token 对应的用户角色判断当前访问的 URL 是否在白名单内。举个例子/teacher/score/save这个接口只允许教师角色访问/admin/user/delete只允许管理员访问。小程序端则在onShow生命周期里检查本地存储的role字段按角色动态渲染底部导航栏和操作按钮。这里的经验是前端隐藏入口只是提升体验后端强制校验才是安全底线前后两端必须同时做少一个都不行。管理端的用户管理模块就是一个标准的 CRUD分页查询用户列表、关键字模糊搜索支持学号/姓名/工号、新增用户时为其分配 openid 绑定关系、禁用账号时修改状态字段。公告发布模块也是类似操作不过它有一个小设计——公告按create_time倒序排列且置顶字段is_top为 1 的公告排在最前面这个小细节在教务场景下很实用开学通知、放假通知都需要置顶展示也给项目增加了一点交互设计感。3.3 前端组件与后端接口的契约约定前后端分离开发最大的痛点就是接口契约不统一——前端说后端返回的数据格式不对后端说前端传的参数名写错了吵得不可开交。这个项目提供了一个较好的解决方案后端统一返回一个ResultT对象格式固定为{ code: 200, message: success, data: { ... } }前端小程序端也统一封装了一个request工具函数基于wx.request封装所有网络请求都走这个函数自动处理三件事请求头里统一携带 token、HTTP 200 时判断code字段是否为 200 决定走成功分支还是错误提示、网络异常时统一弹wx.showToast。这是小程序开发必备的封装思维——如果每个页面都直接调wx.request光是处理重复代码就能让人崩溃。这里我强烈建议对于新手项目哪怕时间再紧也要养成写接口文档的习惯。不用搞复杂的 Swagger 或者 YApi就写一个简单的 Markdown 文档把每个接口的 URL、请求方式、传入参数、返回结果列清楚前后端对照着开发联调效率至少提升一倍。我见过太多项目前端和后端各写各的等到联调阶段才发现字段名对不上改来改去浪费大量时间。4. 源码部署与运行全流程实录4.1 环境准备与工具链清单如果你下载的是完整的源码想把它跑起来先按下面的清单准备好环境。这是整个流程中最容易出问题的环节很多同学的首次部署失败都栽在环境细节上。依赖工具版本建议用途说明JDK1.8 或 11SpringBoot 2.x 系列使用最稳的版本Maven3.6依赖管理和项目构建MySQL5.7 或 8.0数据库8.0 需要留意驱动版本差异IDEA2020.x后端开发 IDE微信开发者工具最新稳定版小程序前端开发调试Redis可选无版本要求如果项目带缓存配置则需要三个容易踩坑的地方提前说第一JDK 版本别用太高SpringBoot 2.x 对 JDK 17 的兼容性时有小问题如果本地只有新版本 JDK建议单独装一个 JDK 8 并在 IDEA 里配置好 Project Structure第二MySQL 8.0 和 5.7 的驱动配置不完全一样application.yml里driver-class-name如果是 5.7 用的com.mysql.jdbc.Driver换到 8.0 就必须改成com.mysql.cj.jdbc.Driver否则启动直接报错第三微信开发者工具的合法域名配置本地调试阶段可以在右上角“详情→本地设置”里勾选“不校验合法域名”但要真正上线所有接口域名必须配置到小程序后台的 request 合法域名列表里还必须备案过。4.2 从数据库初始化到后端启动拿到源码包之后解压你会看到两个目录course-system后端工程和wechat-miniprogram小程序工程以及一个init.sql数据库脚本文件。先说后端启动流程第一步用 Navicat 或命令行创建一个数据库比如course_system字符集选择utf8mb4然后导入init.sql。这一步建议用命令行方式mysql -u root -p course_system init.sql比图形界面快而且不容易漏执行。导入后你可以用SHOW TABLES;验证一下是否成功。第二步打开application.yml检查三处配置数据源用户名密码对应你的 MySQL 账号、数据库连接 URL注意localhost:3306和库名是否与你建的一致、端口号默认 8080如果冲突改成 8081但小程序端请求地址也要同步改。这里有个细节URL 里如果用了useSSLfalse和serverTimezoneAsia/Shanghai这两个参数建议保留省略时 MySQL 8.0 启动时会报时区警告。第三步打开 IDEA用 Maven 导入工程。等待依赖下载完成——这一步耗时长取决于网速建议配置阿里云镜像仓库加速。然后找到CourseApplication.java右键 Run看到Started CourseApplication日志输出说明后端骨架已经跑起来了。你可以先用 Postman 测一个公开接口比如/announcement/list能返回 JSON 列表说明 MyBatis 连接正常、数据库导入成功。4.3 小程序端导入与真机预览打开微信开发者工具选择“导入项目”把wechat-miniprogram目录导进来AppID 先选“测试号”就行等后续真有上线需求再换成注册好的正式 AppID。导入后第一件事是修改配置文件。小程序端的 API 地址通常集中放在一个utils/config.js文件里你要把baseUrl从默认的http://localhost:8080改成你后端实际的地址。这里注意微信开发者工具里不能用localhost指向你电脑上的后端服务——在模拟器里localhost指的是你电脑没问题但在真机上指的是你的手机所以如果要真机预览必须改成你电脑在局域网中的 IP比如http://192.168.1.100:8080。另外手机和电脑必须连同一个 Wi-Fi。然后需要在小程序后台或者开发者工具的本地设置中开启“不校验合法域名”选项开发调试模式下否则请求会被拦截。修改配置之后编译项目看到登录页渲染出来用wx.login自动登录后端控制台能看到日志输出说明整个链路已经通了。4.4 部署漫漫路上的几个“真香”建议如果项目不满足于本地跑通想部署到服务器上给你几条实操建议。第一后端用 Maven 打包成 jar 包mvn clean package之后在target目录下会生成course-system.jar直接nohup java -jar course-system.jar app.log 21 就能后台运行。如果服务器配置低比如 1G 内存建议加上-Xms256m -Xmx512m限制堆内存防止 OOM 崩溃。第二MySQL 数据库建议也部署在同一台服务器减少跨网络访问延迟。如果数据库放在云数据库上记得在云控制台的安全组里放行 3306 端口不然即使代码没问题也会连接超时。第三小程序的正式上线需要走微信审核审核前必须准备好小程序类目资质高校类目需要相关证明文件。如果只是课程设计展示用用“测试号 不校验合法域名 局域网 IP”完全够用但没有正式 AppID 的小程序限制很多有些 API比如获取手机号必须企业主体才能开通。这里要特别提醒不要在项目里写死任何密钥或密码真实项目中这些敏感信息必须通过环境变量或配置文件注入提交代码前一定要检查有没有泄露。5. 常见问题与排查技巧实录5.1 典型问题清单与快速定位思路问题现象常见原因排查方法与解决方案后端启动报Access denied for user数据库账号或密码错误检查application.yml中的 username/password确认 MySQL 中对应账号有权限后端启动报Unknown database course_system数据库未创建或库名不匹配创建数据库后重新执行init.sql核对 URL 中的库名大小写接口请求报 HTTP 404Controller 路径错误或类未扫描确认启动类所在包路径能扫描到 controller核对 URL 与RequestMapping是否一致接口请求报 HTTP 500代码运行时异常多为空指针查看后端日志堆栈定位到具体行号重点检查 MyBatis 返回是否为 null小程序请求提示url not in domain list未配置合法域名或未勾选不校验开发阶段在开发者工具详情中勾选“不校验合法域名”真机调试改成局域网 IP真机请求连不上后端手机和电脑不在同一局域网更换网络确保同一 Wi-Fi检查电脑防火墙是否拦截 8080 端口登录成功但查不到用户信息openid与数据库不一致清除小程序缓存重新登录检查jscode2session返回的 openid 与表中的 openid 字段是否绑定选课提示“课程已满员”但实际没满容量字段capacity维护错误检查init.sql中capacity默认值确认selected_count的原子更新 SQL 正确最核心的排查思路是分层定位先确认前端请求有没有发出去看开发者工具的 Network 面板再确认后端有没有收到请求看 IDEA 控制台日志最后确认 SQL 有没有执行打开 MyBatis 的 SQL 日志输出。沿着这条链路走一遍90% 的问题都能找出根因。5.2 我用 debug 模式定位 bug 的完整案例举个例子有一次我跑这个项目发现一个用户登录后跳转到首页课程列表一直加载不出来Network 面板显示请求返回 500。通过日志看到报错是NullPointerException指向CourseServiceImpl的第 48 行。打开代码一看那行是ListCourseVO courseList courseMapper.selectCourseList(studentId);问题出在studentId传进来是null了——前端调用course/list接口时请求参数里带的是openid但后端期望的是studentId。登录接口返回的data里同时包含studentId和token前端页面把 token 存在了本地页面初始化时从wx.getStorageSync(userInfo)里取值但userInfo这个 key 在登录时根本就没存过xor 顺序搞反。这种问题如果光看代码很难发现但用打断点的 debug 方式从前端onLoad开始一步步跟下去十分钟就能定位。所以说遇到报错别慌打开调试器一格一格走比自己瞎猜快得多。5.3 性能与安全的进阶技巧项目跑通只是起点如果要让它真正能扛住一定并发、能在生产环境活下来下面这几个点必须处理。关于 SQL 注入MyBatis 中用${}拼接字符串是最危险的写法任何用户输入都不要用它一律用#{}预编译这个项目在查询列表时使用的模糊搜索就是用了CONCAT(%, #{keyword}, %)这种防注入写法。关于跨域问题如果你的小程序端请求后端出现Access-Control-Allow-Origin相关报错在后端配置一个 CORS 过滤器即可。微信小程序的请求不受浏览器同源策略限制它不是浏览器环境但如果你后续做了 Web 管理端就必须处理跨域。推荐在后端写一个WebMvcConfigurer实现类全局配置跨域规则而不是在每个 Controller 上贴CrossOrigin注解。关于 token 安全这个项目的 token 是登录时生成的随机字符串存在 Redis 或内存 Map 中看具体实现。生产环境建议设置过期时间比如 2 小时并启用刷新机制——用户每次请求时若 token 剩余有效期小于 30 分钟则自动下发新 token。前端在封装的request方法里判断响应头或响应体替换本地旧 token 即可。注意加密存储管理员密码必须加盐哈希推荐 BCrypt。明文存储密码放在答辩现场就是一个重大安全减分项。6. 从课程设计到生产级系统的二次开发方向最后聊点实在的。这类 SpringBoot 微信小程序的教务系统每年全国高校不知道要提交多少份类似的课程设计。但大多数项目提交完就变成了“一次性代码”——答辩结束再也无人问津。从我的经验来看如果能在这个基础版本上继续做几个方向的延伸这个项目会瞬间升值不少。第一个方向是消息推送的闭环。目前系统的公告模块只是被动展示但真正好用的教务系统应该在发布公告、成绩录入、选课结果出来时主动给学生的微信推送一条服务通知。这里涉及微信小程序的subscribeMessage订阅消息能力——学生主动订阅“成绩通知”教师录入成绩后后端调用微信接口推送模板消息学生微信里直接弹出一条“你的 XX 课程成绩已出85 分”。这项能力保证了用户回访率也是“教务系统”从摆设变成实用工具的临界点。第二个方向是并发选课的可靠性加固。真正的选课高峰比如新学期第一天往往是全校学生同时操作数据库连接池瞬间被打满。可以从两个层面优化一是服务层面引入 Redis 分布式锁防止同一个学生同一门课并发重复选二是数据库层面改造成乐观锁SQL 语句带上版本号冲突时重试。再把 Redis 当作选课人数的预扣缓存异步同步回 MySQL。这套方案虽然在这个课程设计版本里用不上但写进论文或简历的“后续展望”会瞬间拉开和普通课程设计的差距。第三个方向是数据的可视化分析。给管理员端加一个数据概览大屏展示全校选课分布、各学院课程热度排行榜、教师工作量统计、成绩分布直方图。小程序端可以用echarts-for-weixin插件ECharts 官方提供的小程序适配版画图表后端接口直接聚合查询返回统计结果。这个功能视觉冲击力强答辩现场很加分。我在实际查看这个项目源码时最直观的感受是它真正做到了“麻雀虽小五脏俱全”——从用户体系到权限控制从核心教务流程到前后端完整联调该有的链路都打通了。对于刚学完 Java 基础、还没接触过真实全栈项目的人来说这就是一个完美的练手靶场可以把它从头到尾拆开把每一层代码都读懂再自己动手改一两个功能点收获会非常巨大。踩过几次坑之后你就明白了一个真理项目跑通不是终极目标弄懂每一行代码为什么这么写才是从“抄代码”到“写代码”的分水岭。