SpringBoot+Vue互动课堂小程序：从需求到安全防护的完整实践

每年毕业设计选题季互动课堂这类题目都是绝对的热门光是标题就能看到「互动小课堂」「互动微课堂」「即时互动学堂」好几个版本。但说句实在话我见过太多最终交付的成品——登录注册、课程列表、加一个聊天室就敢叫互动课堂。功能看着齐全实际一测全是洞接口裸奔、权限形同虚设、富文本直接拼进页面随便一个抓包工具就能把数据翻个底朝天。所以这篇文章想聊的重点不是怎么把SpringBoot和Vue的项目跑起来而是怎么把一个基于SpringBoot Vue的教育小程序从需求拆分、接口设计到安全防护做成一个真正经得起推敲、扛得住答辩追问的作品。标题里反复强调的安全两个字才是这类项目真正的分水岭。这个内容适合谁看准备做毕设的在读学生、想从零搞一个教育类小程序实战项目的开发者以及那些已经写完功能但总觉得哪里不踏实、想回头补安全的同学。项目最终形态是三端配合微信小程序做学生用户端Vue写管理后台SpringBoot统一提供接口服务。下面我把整个项目的关键决策和实现链路按自己的实际经验拆开讲。1. 三个标题变体背后先想清楚互动课堂到底要做什么选题阶段最容易犯的错误是一上来就写代码。无论是「互动小课堂」「互动微课堂」还是「即时互动学堂」名字怎么变核心需求就两类词互动和课堂。互动意味着不是单向的视频播放要有课堂提问、实时讨论、签到点名、作业反馈这类双向动作课堂意味着有课程、有班级、有清晰的教师/学生角色划分。把这些映射成功能模块才是项目的第一步。1.1 从标题关键词反推出来的完整需求清单我建议你先别管页面长什么样直接用表格把业务需求列出来后面所有代码都是围绕这张表格生长出来的。端核心功能关键业务规则小程序学生端注册登录、课程浏览与加入、课堂签到、互动提问/讨论、作业提交、学习记录只能操作自己的数据签到每天限一次作业提交后截止时间前可修改Vue管理后台课程管理、用户管理、签到统计、互动内容审核、作业批改、数据看板教师负责自己的课程管理员拥有全局权限SpringBoot后端统一鉴权、业务接口、文件上传、定时任务、操作日志所有接口校验登录态敏感操作记录日志把这张表做出来之后你会发现互动小课堂这个题目其实是一个典型的RBAC基于角色的访问控制系统。角色只有三种学生、教师、管理员但权限边界要划得清清楚楚。这也是答辩时老师最爱问的地方一个学生能不能调用教师的接口一个教师能不能修改其他教师的课程这些问题从需求阶段就要回答。1.2 为什么标题里反复强调安全两个字如果你在知网或GitHub上搜互动课堂能找到几百个相似项目大部分功能都差不多。真正拉开差距的是安全设计的完整度。我接手过不少类似项目的代码评审最常见的隐患是这几类登录态用简单的UUID存在前端后端不做有效期校验Token一旦泄露等于账号白给。签到接口只传一个课程ID后端不校验请求者是否真的加入了这门课脚本刷签到毫无压力。讨论区、作业评论走富文本前端过滤了但接口层完全信任前端传过来的HTMLXSS脚本直接入库。文件上传只校验了后缀名改个扩展名就能传一个可执行脚本或者带恶意JS的PDF上去。学生把自己的ID换掉或者把课程ID换掉就能查到别人的成绩和记录——典型的越权漏洞。这些问题的根源是很多同学默认前端页面长啥样接口就收啥把安全责任全部交给前端。正确的做法是后端默认所有请求都不可信任何数据都要做身份校验、权限校验和内容校验。这篇文章后面会专门用一整章展开安全的落地姿势。1.3 互动课堂的核心业务闭环把需求理清楚之后我习惯画一条业务闭环教师在小程序或后台创建课程生成课程码或邀请链接学生通过课程码加入班级课堂上教师发起签到学生扫码或点击签到后端实时记录课堂中师生通过讨论区提问互动课后教师在后台布置作业学生提交附件或文字答案系统自动汇总签到率、互动次数、作业完成度形成学情数据。这条链路一眼看过去不复杂但对实时性和数据一致性有要求。比如签到接口要考虑重复提交的问题讨论区要考虑消息顺序和敏感内容过滤作业提交要处理文件大小和类型。这些细节就是项目从能跑走向能答辩的过程。2. 技术选型的取舍SpringBootVue这套组合为什么能打如果只是做功能演示用Node.jsExpress三小时也能搭一个原型。但作为毕设或者实战项目SpringBootVue这套组合的优势不在快而在稳和完整——生态成熟、资料多、面试聊起来有深度。下面逐个说我的选型理由。2.1 后端为什么是SpringBoot而不是SSH或SSM早几年毕设还流行SSHSpringStrutsHibernate现在基本没人用了。SpringBoot的核心价值是约定大于配置内置Tomcat一个java -jar就能起服务省掉一堆XML配置。它自带Spring MVC配合MyBatis-Plus做数据访问开发效率相当高。更重要的是SpringBoot的生态让你后面做安全、做限流、做日志都有现成的轮子Spring Security、Sa-Token、Logback、Redis都是面试能聊出东西的组件。我想特别提醒一点SpringBoot版本的选择直接影响后面所有的依赖兼容。SpringBoot 2.x搭配JDK 8是最稳的组合SpringBoot 3.x强制要求JDK 17很多同学遇到的IDEA不能创建SpringBoot项目不能使用JDK 1.8就是版本不匹配造成的。我的建议是毕设项目不要盲目追求最新版选择SpringBoot 2.7.x JDK 1.8 MyBatis-Plus 3.5.x这套经过大量项目验证的组合能省掉大量改依赖的烦恼。2.2 前端为什么是Vue管理后台怎么分工管理后台我选择了Vue 2 Element UI这套组合在国内中小企业后台管理系统里占有率极高组件齐全文档和踩坑帖都多。Vue的核心优势是数据驱动视图做课程列表、签到统计这类页面只需要维护好data里的数据页面自动更新开发效率和可维护性都比jQuery时代高一个量级。到了毕设答辩阶段Vue的响应式原理、生命周期、路由守卫这些都是高频问题。比如路由守卫就可以用在管理后台的登录态控制上用户没登录就访问后台页面直接通过router.beforeEach重定向到登录页。这一行代码在答辩时就能讲出前端路由级权限控制的亮点。2.3 小程序端选原生还是uni-app我的最终选择这是个老生常谈的问题。原生微信小程序语法简单文档齐全但如果后面想把项目扩展到支付宝、抖音小程序原生代码就得整套重写。uni-app基于Vue语法一套代码多端编译社区插件丰富而且它的API对原生能力扫码、定位、录音、支付封装得比较完善。从毕设的投入产出比来看我更推荐uni-app。理由有三第一你已经会了Vue学uni-app几乎没有额外成本第二uni-app的页面结构和Vue几乎一致答辩时可以顺带讲项目采用前后端分离架构多端复用业务逻辑第三像扫码签到这种功能原生写一遍uni-app也是封装好的API但后者的扩展性明显更好。如果你对性能有极致追求或者只瞄准微信生态不打算复用那原生也没问题技术选型本身没有标准答案关键是能自圆其说。3. 数据库设计与核心接口先把课堂互动的数据地基打牢很多同学喜欢边写代码边建表想到哪写到哪最后接口和表结构对不上改起来痛不欲生。我的习惯是先花半天时间把表结构设计确定下来再开始写代码。这一章我把核心表结构和接口设计思路直接放出来你可以照着抄。3.1 核心表结构设计从用户到学情统计互动课堂的数据模型围绕人—课—行为三条线展开。用户体系两张表user存账号密码、昵称、头像、角色user_role做用户和角色的关联虽然本项目角色是单值但保留关联表后面扩展更灵活。密码字段只存BCrypt加密后的密文绝对不存明文。课程体系三张表course存课程名称、简介、封面、教师ID、课程码course_member存学生加入的课程关系和加入时间sign_record存签到记录字段包括签到课程、签到学生、签到时间、签到状态。这三张表的关系是一个课程对应多个成员一个成员对应多条签到记录。互动体系两张表discussion存课堂讨论和问答包含内容、发送者、所属课程homework存作业信息包含作业标题、要求、截止时间homework_submit存学生提交记录关联作业ID和学生ID。我特意在每张表都加上create_time、update_time、deleted三个通用字段这是MyBatis-Plus自动填充和逻辑删除的基础后面做数据统计和恢复都靠它们。3.2 统一返回结构和接口设计规范接口设计的一个小习惯能让整个项目清爽不少所有接口统一返回同一个结构体。我用一个泛型类ResultT里面固定三个字段code业务状态码、message提示信息、data业务数据。成功返回200参数错误返回400未登录返回401无权限返回403服务器异常返回500。这样做的好处是前端可以统一处理错误不需要每个接口单独判断。配合一个全局异常处理器RestControllerAdvice后端一旦抛出业务异常框架自动包装成统一的JSON返回给前端代码里不需要写一大堆try-catch。这一套设计在答辩时是实打实的加分项能体现你对工程化的理解。3.3 分页查询的正确姿势MyBatis分页插件的使用细节课程列表、签到记录、作业列表这些都是典型的分页查询场景。MyBatis-Plus自带分页插件用法很简单先配置一个MybatisPlusInterceptor注册PaginationInnerInterceptor然后在Service层调用PageUser page userMapper.selectPage(new Page(current, size), queryWrapper)即可。这里有个容易踩的坑分页插件和逻辑删除插件、乐观锁插件要配置在同一个拦截器里且顺序不能乱。我在一个项目里就遇到过配置了逻辑删除之后分页总数不对的情况最后发现是拦截器注册顺序的问题。正确的配置方式是把PaginationInnerInterceptor放在最后Configuration public class MybatisPlusConfig { Bean public MybatisPlusInterceptor mybatisPlusInterceptor() { MybatisPlusInterceptor interceptor new MybatisPlusInterceptor(); interceptor.addInnerInterceptor(new BlockAttackInnerInterceptor()); interceptor.addInnerInterceptor(new OptimisticLockerInnerInterceptor()); interceptor.addInnerInterceptor(new PaginationInnerInterceptor(DbType.MYSQL)); return interceptor; } }BlockAttackInnerInterceptor是个很容易被忽略的组件它能阻止不带where条件的全表更新删除操作防止手滑把整张表清空。3.4 Vue路由参数与小程序的页面传参细节前端联调时页面跳转传参是高频操作。管理后台用Vue Router路由传参有两种方式query方式参数会出现在URL上适合传递课程ID这类简单参数params方式配合命名路由可以隐藏参数但刷新页面参数会丢失不适合存关键业务数据。我的习惯是业务主键一律放在query里页面刷新后能从URL恢复状态用户登录信息放在sessionStorage或localStorage里不通过路由传。小程序端的传参逻辑和Vue不太一样。uni.navigateTo的url后面拼参数目标页面的onLoad(options)里取参数// 页面A跳转到课程详情 uni.navigateTo({ url: /pages/course/detail?courseId courseId }); // 页面B接收参数 onLoad(options) { this.courseId options.courseId; }要注意的是小程序 URL 传参长度有限制且特殊字符需要编码如果参数是对象建议先用JSON.stringify再encodeURIComponent到目标页再解码。4. 安全构建的完整链路从登录鉴权到文件上传防护现在进入这篇博文最核心的章节。标题用了安全开发和实现安全构建这样的词说明安全不是可选项而是必选项。我按一条典型的攻击链路把防护措施一一配齐。4.1 登录鉴权从Session到Token的方案选择传统单体项目喜欢用Session保存登录态但小程序端不适合——小程序和服务的交互天然是分离的SessionId 存在Cookie里跨端管理麻烦而且小程序web-view和接口域名之间的Cookie策略经常出问题。我使用JWTJSON Web Token方案用户登录成功后后端签发一个带过期时间的Token返回给前端前端每次请求在Header里带上Authorization: Bearer token。JWT的优点是服务端无状态不需要额外存储登录态缺点是Token一旦签发到期前无法主动作废。为了解决这个问题我引入了Redis登录时把Token存入Redis并设置过期时间每次请求通过拦截器判断Redis里是否存在该Token。这样实现了可控的登录态管理用户退出或管理员封号时删掉Redis里的Key即可让Token立即失效。拦截器逻辑不复杂但有一个顺序问题要注意放行的路径登录、注册、获取课程列表要明确配置其余路径全部走鉴权。同时拦截器里不要只校验Token格式还要从Token中解析出用户ID塞到ThreadLocal里供后续业务使用避免每次查库。4.2 XSS攻击防护全局过滤器与富文本内容的清洗XSS攻击在互动课堂项目里的典型场景是讨论区和作业评论。攻击者在输入框里填一段scriptalert(xss)/script或更恶意的窃取Cookie脚本如果后端原样存储、前端原样渲染脚本就会在别的用户浏览器里执行。我的防护分三层第一层输入侧做HTML转义。对于普通文本字段昵称、标题在后端统一进行转义把、、、等字符转换为HTML实体。第二层对于富文本内容采用白名单策略只允许保留p、br、img、strong等安全标签其余全部剥除。这里推荐使用Jsoup的Cleaner配合Safelist.relaxed()或自定义白名单。第三层前端渲染时也要避免使用v-html直接渲染富文本如果必须用确保内容已经过后端清洗。针对上传PDF这类文件场景有一个很隐蔽的坑。前端上传了一个PDF后端只校验了后缀名但这个PDF里可能嵌入了JavaScript脚本PDF文件格式本身支持JS。如果程序后续把这个PDF直接嵌入页面预览或下载后本地打开恶意脚本可能被激活。解决思路是文件类型白名单加文件头校验PDF的魔数是%PDF图片的魔数是FF D8 FF等。只认后缀不认内容等于没校验。再配合把上传目录设置为不可执行、文件名服务端重命名等策略文件上传这关才算守住。4.3 SQL注入与越权访问的防范SQL注入的经典原因是字符串拼接SQL。MyBatis中#{}是预编译占位符安全${}是字符串替换直接拼入SQL存在注入风险。我的原则是业务代码中禁止使用${}排序字段等需要动态拼接的地方用白名单映射不允许用户直接传字段名进来。越权访问分两种。水平越权学生A拿着自己的Token去请求学生B的课程记录这需要在每个涉及按用户查数据的接口里强制从Token解析出的用户ID出发而不是信任前端传的用户ID。垂直越权学生去调用教师的后台接口这需要做角色权限校验。我的做法是自定义一个RequireRole注解加在接口方法上配合拦截器统一校验。比如签到的教师端统计接口标注RequireRole(TEACHER)学生Token过来直接返回403。4.4 接口防刷与敏感操作保护签到接口是最容易被脚本刷的。一个学生拿抓包工具抓到签到请求后写个循环一天签一百次后端如果只判断是否已签到那第一次成功后的请求至少会查库判断虽然结果不影响业务但白白消耗数据库性能。我的方案是三层防刷接口层做限流同一个用户对同一个接口的调用频率做限制比如用Redis的INCR 过期时间一分钟内最多调用N次业务层做幂等判断签到表对course_id user_id date建立唯一索引重复插入直接报错最后在展示层小程序端做个自定义签到按钮签到后置灰。敏感操作比如修改密码、管理员删除课程我会要求二次确认。前端弹窗让用户输入确认删除或登录密码后端再做校验。这套设计在演示时很有说服力能直观地告诉老师我考虑了实际操作中的风险。5. 小程序端实战踩坑记录那些文档里不会写的细节功能实现到小程序这一层真正的坑才开始显现。下面这几个问题都是我实际开发中遇到的每一个都能搜到大量类似提问说明都是高频问题。5.1 顶部导航栏高度与iPhone刘海屏适配小程序在iPhone X及以后机型上顶部会有刘海区域导航栏高度不是固定的。如果页面有自定义头部直接把内容定位到顶部就会被刘海遮住。正确做法是动态获取状态栏高度和菜单按钮胶囊位置// 计算自定义导航栏高度 const systemInfo uni.getSystemInfoSync(); const menuButton uni.getMenuButtonBoundingClientRect(); // 导航栏高度 (胶囊顶部 - 状态栏高度) * 2 胶囊高度 状态栏高度这套计算在开发者工具里模拟器和真机上的结果不一样务必以真机为准。另外Android和iOS的状态栏高度也不同Android一般是20px左右iOS刘海屏会到44px甚至更高写死任何一个都是错的。5.2 动态设置标题与页面栈管理课程详情页的标题我希望显示课程名称而不是固定的课程详情。原生小程序可以用wx.setNavigationBarTitle({ title: xxx })uni-app里是uni.setNavigationBarTitle。这个接口看似简单但有个细节它必须在页面onLoad或onShow里调用而且不能在请求课程信息的回调之前调用否则标题还没设置就被页面的默认标题覆盖了。正确做法是先在onLoad里设置一个加载中的标题然后在异步请求成功的回调里再次调用setNavigationBarTitle。同样的思路也适用于页面栈管理当页面栈很深时uni.navigateBack的delta参数要小心返回层数超过页面栈长度会失效建议用uni.navigateBack({ delta: getCurrentPages().length - 1 })返回首页。5.3 扫码签到功能的实现与后端幂等设计扫码签到是互动课堂的一个亮点功能。教师端生成一个包含课程ID和签到批次的二维码学生用小程序的扫一扫功能扫码完成签到。uni.scanCode调起相机扫码后返回二维码内容格式类似https://xxx/course/sign?courseId123batchId456学生端解析参数后调用签到接口。后端设计关键在幂等同一个学生同一门课同一次签到批次最多成功一次。我除了在业务层判断之外还在数据库层面加了unique(course_id, user_id, batch_id)唯一索引双重保障。另外签到二维码要有时效性教师发起签到后二维码有效期设为60秒后端校验batchId对应的批次是否在有效期内。这样既防止了学生把二维码截图传给没来上课的同学又能在答辩时讲出防代签的设计思路。5.4 iOS静音模式下播放音频的坑课堂互动里如果涉及音频播放比如英语听力、语音点评微信小程序在iOS上有两个著名的问题一是静音模式下audio组件不发声二是在原生iOS的静音拨片打开后音频会被强制静音。这两个问题本质是iOS系统的音频会话策略导致的。在uni-app里创建音频实例时可以尝试设置音频会话类别或者在用户点击播放时给出请检查设备静音状态的提示。比较稳妥的做法是不依赖系统自动判断播放前先判断当前音频上下文状态播放失败时主动弹出引导提示。这个坑平时开发注意不到但真机演示时遇到就是当场翻车提前处理好能避免很多尴尬。5.5 开发版过期、已过期请重新扫码与调试环境问题小程序开发版有有效期限制过期后工具会提示开发版小程序已过期请在开发者工具重新扫码。这个问题本质是本地代码和真机预览的会话失联重新编译并扫码即可解决。我建议日常开发时直接把不校验合法域名选项打开这样本地通过IP访问后端服务也能调试。但要注意上线前必须关闭这个选项并且小程序后台要配置HTTPS合法域名否则真机访问会因域名校验失败而白屏。6. 从本地到上线部署、验证与答辩加分项功能写完只是万里长征的第一步。很多同学在本地跑得好好的一到部署就抓瞎。我按自己的部署经验把从开发到上线的操作链路过一遍顺手把最容易踩的版本坑一起排掉。6.1 SpringBoot版本与JDK的兼容性自查这一步放在最前面因为版本不匹配会引发连锁报错。我见过最多的问题是装了JDK 1.8用IDEA的Spring Initializr创建项目时发现只能选SpringBoot 3.x一运行就报UnsupportedClassVersionError。原因很简单SpringBoot 3.0起强制JDK 17JDK 1.8根本跑不了。所以项目初始化之前先确认自己的环境组合。如果电脑装的是JDK 1.8就老老实实选择SpringBoot 2.7.x如果已经是JDK 17才能考虑SpringBoot 3.x。MyBatis-Plus同理3.5.3之前的版本对SpringBoot 3的支持不完整需要选择对应版本。这个检查做完后面能省一半的排错时间。6.2 多环境配置与打包发布SpringBoot的application.yml不要只写一份我习惯拆成application-dev.yml和application-prod.yml。开发环境连本地数据库、开启调试日志生产环境连云数据库、关闭详细日志、配置HTTPS证书路径。启动时通过--spring.profiles.activeprod指定环境。管理后台的前端打包用npm run build产物是dist目录扔到Nginx的html目录下即可。同时Nginx里还要配置反向代理把/api前缀的请求转发到SpringBoot服务端口。后端直接mvn clean package打jar包用nohup java -jar挂在后台运行。这里有个小技巧jar包启动后经常找不到问题原因先用java -jar xxx.jar --debug跑一次日志全开排查完再正式后台启动。小程序端则直接在HBuilderX里发行选择微信小程序将产物导入微信开发者工具上传后提交审核——审核不会要求展示全部功能但安全合法是底线。6.3 答辩演示时的加分设计能走到答辩这一步功能肯定都实现了大家拼的是细节和表达。我列几个性价比很高的小设计都来自我用过的项目里真实被老师称赞过的点操作日志用AOP切面记录关键操作登录、删除课程、修改成绩存库并提供简单的查询页面。老师问项目怎么审计直接打开日志页面就是最好答案。全局异常处理故意在演示时触发一个错误操作比如传一个非法参数页面弹出友好提示而不是一堆英文报错观感瞬间不一样。数据库唯一索引把签到表、作业表里的唯一索引拿出来讲清楚这是数据库层面的最后一道防线面试官会认定你懂数据一致性。再多说一句答辩表达别背概念讲场景。老师问你怎么防XSS不要背诵XSS定义而是说我在讨论区提交了一段脚本然后你们可以看到它被过滤了——边说边演示比任何理论都有说服力。做这个项目最大的感受是一个教育类小程序功能上限决定了它好不好用而安全下限决定了它敢不敢用。很多同学把时间全花在堆功能上却忽视了登录校验、权限控制、XSS过滤这些看不见的工程。但恰恰是这些看不见的地方最能体现一个开发者是否真的有项目经验。如果你正在做类似选题我真心建议你花一半的时间在安全设计上把Token鉴权、角色权限、内容过滤、防刷幂等这四件事做透答辩时会有底气得多。最后分享一个小习惯每写完一个接口都用抓包工具模拟一次恶意请求看看后端是友好拒绝还是直接崩掉——这一招帮我挡住了不知道多少个隐藏漏洞。