Spring Boot+Vue教辅平台开发实战：需求、建模与踩坑复盘

前阵子接了个模拟项目X目标客户是某地区教育信息中心要建一套面向中小学生和老师的教辅平台项目代号就叫“行星”。这个号起得挺妙产品经理当时给的解释是学生是太阳学科课程像行星一样围着学生转教辅资源就是轨道上的补给站。项目定了调以后技术选型没纠结太久后端 Spring Boot前端 Vue也就是标题里那串“springboot行星中小学教辅平台vue”的由来。这篇文章不打算做成那种照着文档念的说明书我更想把这几个月做下来的真实链路捋一遍需求怎么拆、表怎么建、接口怎么设计、前后端怎么联调、上线又踩了哪些坑。如果你正在做类似的教辅、教务、在线练习系统或者准备用 Spring Boot Vue 这种组合接教育类单子这文应该能帮你省几天的墙。涉及代码的部分我会放关键片段不是全部代码因为全贴出来也没人看重点是设计思路和我不太想在文档里交代的那部分工程细节。1. “行星”平台的需求底色三个角色、四类业务、一个核心循环教辅平台看起来就是个资源网站真正做进去才发现它的业务复杂度比一般的管理系统高出一个量级。因为用户不是单一群体学生、教师、管理员各自要的东西完全不一样而且相互之间还有数据流转。我建议你接这类项目时第一步别急着搭架子先把人、事、数据流理清楚。1.1 三个角色各自真正需要什么学生端的核心诉求是“练”。不是看资料是做题、交作业、看错题、盯着自己哪块知识点没掌握。我们调研了几所学校的学生使用习惯发现学生真正高频使用的功能高度集中在线做题、查看批改结果、错题重练。什么课件下载、教案浏览学生几乎不碰那是老师要用的。老师端的核心诉求是“布置和监督”。老师要能上传教辅资源要能从题库选题组卷要把作业发给指定班级要能看到谁做了、谁没做、平均正确率多少。这个环节特别容易做重我见过很多项目把老师端做成一个内容管理后台各种分类树、各种富文本编辑器结果老师根本不买账。老师要的是简洁上传文件、选题、发作业、看反馈四步走完。管理端的核心诉求是“统计与配置”。账号管理、学科年级配置、数据看板、资源审核。学生的注册要审核老师上传的资源要审核敏感内容要过滤这些都是管理端的责任。1.2 四类业务的优先级排序和需求方开了三轮会最终我们把业务砍成四块按优先级排序如下。第一优先级是在线题库与作业系统。这是整个平台的命脉学生和老师都是冲这个来的没有这个不如不做。题库要支持学科、年级、知识点、题型、难度五个维度筛选作业要有截止时间、自动批改、正确率统计。第二优先级是教辅资源管理。包括文档、PPT、视频、音频的上传与分类老师备课用。资源上传后要经过管理员审核才能发布这个流程不能省尤其涉及试卷、教材解读这类内容。第三优先级是错题本。错题本不是简单记录错题而是要自动关联到知识点学生反复练习时系统从同知识点题库抽题形成“错题-知识点-同类题巩固”的闭环。第四优先级是学习数据看板。按班级、按学生维度的学习时长、答题数量、正确率趋势。这个和错题本配合做是平台后续做精准推荐的底层数据。1.3 核心业务循环选题、作答、批改、反馈“行星”这个平台说到底是一个循环驱动老师从题库选题组卷发布作业学生在规定时间内作答提交系统自动批改客观题同时采集答题数据老师和学生各自在反馈端看到结果错题自动沉淀到错题本之后老师根据数据决定下一次选题方向。想明白这个循环再去看功能模块就不会乱。很多开发商拿到需求就开始堆功能结果答题系统和题库系统的数据是两个孤岛错题本又接不上知识点数据整个平台就废了。我们做设计时所有模块都围绕这个循环展开哪个功能不在循环里就放进二期再说。2. Spring Boot Vue 的选型取舍为什么这对组合最适合教辅类系统这个项目选型的时候也有团队提过用 PHP 快速出活或者用 Python 做后端。最终定了 Spring Boot Vue不是因为它最新最潮而是在这个具体场景里它刚好把开发效率、生态成熟度、人才供给都占住了。2.1 后端非 Spring Boot 不可的四个理由第一是生态太成熟了。教育类项目绕不开权限管理、文件处理、定时任务这些事Spring Boot 里Spring Security、MinIO客户端、Quartz定时器都是现成的哪怕不用框架自己写社区里踩坑案例也多出了问题搜解决方案的成本极低。第二是事务和状态管理可靠。作业提交通常涉及多张表的写入答题记录要插、作业状态要更新、错题要生成、统计数据要累加这一串操作必须在一个事务里。Spring 的Transactional 声明式事务用起来干净利落配合 MySQL 的事务隔离级别基本不会出数据不一致的幺蛾子。第三是 Java 的稳定性和性能足够满足教辅平台这种中等并发的场景。中小学教辅平台的并发量再大通常白天上课时间集中高峰也远没到电商大促那种级别。Spring Boot 默认的Tomcat线程池配合 Redis 缓存撑住几千人同时在线做题是没问题的。第四是招人好招。我们团队里后来的实习生刚毕业就是学的 Spring Boot上手成本低不像某些小众框架写起来带劲后面维护的人找不到。这点你接外包项目时要多想一步甲方后期很可能自己招人维护技术栈选太偏就是在给自己挖坑。2.2 前端用 Vue 而不是 React 的真实考量前端这边React 和 Vue 我们内部也吵过。最后选 Vue 有两个很实在的原因。一是 Vue 对后端转前端的开发者友好。我们这个项目组后端为主前端就两个同学。Vue 的模板语法更接近传统的 HTML 思维单文件组件把模板、脚本、样式收拢在一个文件里心智负担小。用 React 也不难但 hooks 那套逻辑容易让不常写前端的人写出反模式。二是 Element UI 组件库太对口了。教辅平台大量页面是表单、表格、树形结构、分页Element 的 el-table、el-tree、el-form 基本把后台管理类页面覆盖完了开发的效率肉眼可见。后来我们升级到了 Element Plus配合 Vue 3 用体验更顺滑。2.3 前后端分离的部署结构对教辅场景的实际意义教辅平台有个特点就是文件资源多、页面交互多但机器资源往往有限。前后端分离让我们能把静态文件托管到 Nginx由 Nginx 直接返回前端资源后端只处理接口请求压力瞬间减半。同时后端的文件上传走独立接口文件的读写和业务接口分离日后如果流量上来把文件服务单独拆出去扩容也方便。另外前后端分离对开发调试也友好。前端同学开着自己的 Vue 开发服务器通过 Vite 的代理把 /api 请求转发到后端大家并行开发互不干扰联调时通过配置文件切换接口地址就行。这个节奏对项目周期紧张的教辅平台尤为重要。3. 数据库建模教辅资源、题库与错题本的核心表怎么设计数据库设计是整个项目里最费脑筋的部分也是最容易返工的部分。我们前后设计了三个版本最终沉淀下来的核心表是这样一套设计思路我挑关键部分讲每个表都说说当初为什么要这么设计。3.1 用户、角色与班级别把组织关系做成一棵简单的树用户表本身不复杂就是账号、密码、姓名、手机号、状态这些字段。复杂的是用户和组织的关系。中小学生有班级归属老师有任教班级和任教科目一个学生可能有多个班级比如走班制教学一个老师也可能跨年级教课。我见过很多项目直接做一个 user_class 单表关联把组织关系写死后面走班制一上来就得重构。我们最终的设计是角色独立、班级独立、用户和班级多对多关联。CREATE TABLE user ( id BIGINT PRIMARY KEY AUTO_INCREMENT, username VARCHAR(50) NOT NULL UNIQUE, password VARCHAR(100) NOT NULL, real_name VARCHAR(50), role TINYINT NOT NULL COMMENT 1学生 2教师 3管理员, status TINYINT DEFAULT 1, created_at DATETIME DEFAULT CURRENT_TIMESTAMP ); CREATE TABLE class_info ( id BIGINT PRIMARY KEY AUTO_INCREMENT, class_name VARCHAR(50) NOT NULL, grade INT NOT NULL, head_teacher_id BIGINT COMMENT 班主任用户ID ); CREATE TABLE user_class ( id BIGINT PRIMARY KEY AUTO_INCREMENT, user_id BIGINT NOT NULL, class_id BIGINT NOT NULL, subject_id BIGINT COMMENT 任教科目教师才需要, UNIQUE KEY uk_user_class (user_id, class_id, subject_id) );教师和班级关联时带上学科是为了支持同一老师在不同班级教不同课也是为后续作业按班级科目维度推送做铺垫。设计这套时加了一个唯一索引避免并发情况下同一关系插入多条。3.2 题库设计知识点拆到最细组卷才不费劲题库表是平台的地基。最初产品给的需求只是“学科、年级、题型、难度”我们做完之后发现要是没有知识点字段错题本和智能组卷就做不下去。所以题目表调整后变成这样CREATE TABLE question ( id BIGINT PRIMARY KEY AUTO_INCREMENT, subject_id INT NOT NULL, grade INT NOT NULL, knowledge_point VARCHAR(100) NOT NULL COMMENT 知识点如一元二次方程求解, question_type TINYINT NOT NULL COMMENT 1单选 2多选 3判断 4填空 5解答, difficulty TINYINT NOT NULL COMMENT 1-5, content TEXT NOT NULL COMMENT 题干, options TEXT COMMENT 选项JSON格式, answer TEXT COMMENT 正确答案, analysis TEXT COMMENT 解析, creator_id BIGINT, audit_status TINYINT DEFAULT 0 COMMENT 0待审核 1通过 2驳回, created_at DATETIME DEFAULT CURRENT_TIMESTAMP );选项和答案为什么用TEXT存JSON而不是建独立表我们讨论过结论是题目选项的增删改几乎都是整体替换没有单条操作的场景拆成子表反而让查询多一次连接性能不划算。但要注意答案和解析涉及敏感信息接口返回时一定要脱敏不能把答案直接扔给前端否则学生抓包就能看到答案。知识点字段我建议做成字典表加关联而不是直接存字符串。直接存字符串的问题是同一个知识点可能被录入成“一元二次方程”和“一元二次方程求解”两种写法统计时就乱了。正确做法是建一个 knowledge_point 表题目表存 knowledge_point_id。3.3 作业与答题记录读写分离才能扛住提交高峰作业表存作业的基础信息发布老师、班级、截止时间、卷面总分。作业题目关联表存的是这次作业选了哪些题。这两张表是低频写、高频读问题不大。真正的瓶颈是答题记录表。全班四五十个学生同时提交作业每份作业二三十道题一次提交就是上千条记录插入高峰时段几十个班同时交瞬间上万条写入。这个量对 MySQL 来说不算特别大但如果不做合理的表设计很容易锁表导致接口超时。我们的方案是把答题记录拆成两道层head 表和 detail 表。head 记录一次提交的概要信息detail 记录每道题的对错和具体答案。提交的时候先插 head 拿自增ID再批量插入 detail。CREATE TABLE homework_submit ( id BIGINT PRIMARY KEY AUTO_INCREMENT, homework_id BIGINT NOT NULL, student_id BIGINT NOT NULL, submit_time DATETIME, score DECIMAL(5,2), status TINYINT DEFAULT 0 COMMENT 0未提交 1已提交 2已批改, UNIQUE KEY uk_homework_student (homework_id, student_id) ); CREATE TABLE submit_detail ( id BIGINT PRIMARY KEY AUTO_INCREMENT, submit_id BIGINT NOT NULL, question_id BIGINT NOT NULL, student_answer TEXT, is_correct TINYINT, score DECIMAL(5,2), KEY idx_submit_id (submit_id) );注意作业表和提交表之间那个唯一键这是防止学生重复提交的关键。同一个学生同一份作业只能有一条提交记录第二次提交就做更新处理。这个唯一约束坑了我们一次初期漏了它测试阶段就出现了一个学生两份成绩的脏数据后来加了唯一键配合 ON DUPLICATE KEY UPDATE 才稳定下来。3.4 错题本它是生成数据不是手工记的账错题本千万不要做成长按提交的“手工记录”功能学生不会主动记的。正确定位是学生每次作业、每次练习提交后系统自动把答错的题写进错题本表。这张表的字段要能支撑“日后同类题巩固”这个场景所以必须冗余一份知识点ID。CREATE TABLE wrong_question ( id BIGINT PRIMARY KEY AUTO_INCREMENT, student_id BIGINT NOT NULL, question_id BIGINT NOT NULL, subject_id INT NOT NULL, knowledge_point_id BIGINT NOT NULL, wrong_count INT DEFAULT 1, last_wrong_time DATETIME, mastered TINYINT DEFAULT 0 COMMENT 是否已掌握, UNIQUE KEY uk_student_question (student_id, question_id) );同一个人同一道错题只保留一条记录通过 wrong_count 累计错误次数这样错题本就清爽不会越积越冗余。掌握与否可以由学生自己在页面上标记也可以让系统根据“连续三次做对同类题”自动判断我们两个都做了效果不错。4. 从上传教辅到在线答题关键接口与前后端联调的完整链路这一节讲三个核心接口的设计逻辑和联调细节。教辅平台最容易出问题的其实不是业务本身而是接口设计不合理导致的反复返工尤其是文件上传和状态流转一个是上传慢一个是容易乱。4.1 教辅资源上传断点续传不是标配但分片必须做老师端上传课件、试卷文件动不动就是几十上百MB。一开始我们走最简单的上传方式前端读文件直接 POST 给后端。测了下内网还行外网环境下经常传一半断掉老师就炸了说是你们平台有问题。后来改成前端分片上传每片1MB后端接收完再合并。更重要的是加了进度条老师们看到进度在走心态就稳住了。核心代码大概是这个逻辑PostMapping(/resource/upload/chunk) public Result uploadChunk(RequestParam(file) MultipartFile file, RequestParam(chunkIndex) Integer chunkIndex, RequestParam(totalChunks) Integer totalChunks, RequestParam(fileId) String fileId) { String chunkDir fileStoragePath / fileId /; File dir new File(chunkDir); if (!dir.exists()) { dir.mkdirs(); } try { file.transferTo(new File(chunkDir chunkIndex)); } catch (IOException e) { return Result.error(分片上传失败); } // 判断是否最后一个分片 if (chunkIndex totalChunks - 1) { mergeChunks(fileId, totalChunks); } return Result.success(); }分片合并的时候有个坑分片文件命名必须补零否则合并时排序会乱。比如第2片写成“2”第10片写成“10”按字符串排序时“10”会排到“2”前面合并出的文件就损坏了。正确做法是第2片命名为“0002”比如四位编号这样排序才对。4.2 组卷的接口设计让老师在页面上完成“选题-预览-发布”三步组卷接口是整个系统里最考验细节的。老师选题时希望看到题目的内容和难度不希望只看到一个列表编号选完之后希望整体预览一遍再发布发布时还要选择目标班级和截止日期。接口我们拆了三个选题查询接口、预览接口、发布接口。选题查询接口支持按学科、年级、知识点、题型、难度组合筛选返回题目内容但不返回答案。预览接口把选中试题拼成一份临时卷子返回也不带答案。发布接口接收一个试题ID数组、班级数组、截止时间生成作业记录。这里有个要强调的点千万不要把发布做成“把选题接口最后一次筛选结果直接保存”必须在前端维护一个独立的选中集合提交时把选中题目ID列表传给后端。有同学图省事发布时直接传筛选条件让后端重新查结果是老师中途改了一下筛选条件发布出去的卷子内容和自己看到的不一致这种事故出一次就够喝一壶的。4.3 答题与自动批改客观题秒批主观题走人工学生端答题页面是高频页面响应速度要快。进入答题页时前端调“获取作业详情”接口拿到试题列表和已提交的答案草稿如果之前做到一半。这个接口返回的试题内容不能带答案。有些团队不注意详情接口把答案也塞进去了学生浏览器开个调试面板就全看到了这是重大事故。提交接口会循环校验每个题的答案格式客观题在服务端即时批改把正误写进 detail 表同时异步触发错题本写入。解答题这种主观题先标记为“待批改”老师后面用批改页面看主观答案人工打分。异步写入错题本这步要注意不能直接在提交作业的事务里同步写。因为一个学生提交错题可能有十几道大量学生同时提交时事务时间太长。我们用 Spring 的 Async 异步方法处理交给线程池去做错题本和统计数据的更新。核心提交事务尽量短只保证答题记录和分数正确落库。4.4 前后端联调中的三处常见“擦枪走火”联调阶段最容易吵起来的问题我列三个典型的。第一个是时间格式。后端默认序列化 LocalDateTime 成 ISO 字符串“2025-06-08T14:30:00”前端一渲染中间多个T又得处理一遍。我们统一在配置里加了 Jackson 的全局时间格式全局输出“yyyy-MM-dd HH:mm:ss”前端直接展示就行。第二个是分页查询的参数命名。前端习惯写“pageNum/pageSize”后端框架惯例又是“current/size”不统一个标准两边的同学就要在参数映射上反复改。我们在项目一开始就定了规则所有分页接口统一用“pageNum”、“pageSize”后端自己在 Controller 里转。第三个是枚举状态的语义。同一套状态码前端理解的“1”是审核通过后端定义的“1”是待审核不在联调前拉齐就会出现数据在页面显示错乱。我们做法是把所有枚举常量定义在项目根目录的常量类前端同学直接看常量类对照表谁也别猜。5. 部署上线与真实踩坑文件存储、Token过期、慢查询三个坎上线前的部署相对顺因为架构定得早Nginx 托管前端静态资源反向代理后端接口到 Spring Boot数据库单独一台 MySQL 8.0Redis 做缓存和 Token 黑名单。真正磨人的是上线后的三个问题每个都值得单独展开讲讲。5.1 文件存储本地路径折腾完还是老老实实上对象存储最开始图省事上传的文件就存在应用服务器的本地目录里数据库只存相对路径。结果线上跑了两周问题就来了应用服务器磁盘有限老师传了大批视频课件几十GB说没就没而且偶尔需要发版重启文件路径没配好还出现过一段资源 404 的情况。后来把文件存储切换到云对象存储。前端上传接口收到文件后后端转存到对象存储的 Bucket返回一个公网可访问的 URL。这个改动一劳永逸存储空间不在本地了磁盘压力消失对象存储自带 CDN 加速老师下载大文件流畅很多图片和视频还能做基础的内容审核。唯一要注意的是 Bucket 的读写权限要配置好避免越权访问资源。5.2 Token过期引发的“选择题答案还在人却掉了”体验上线后天天有学生反馈做着题呢提交的时候突然提示“登录已过期请重新登录”刚做的一大半全没了。查了下问题出在 JWT Token 的过期时间设成了 2 小时。一节课加拖堂和排队交作业学生花了一节课时间慢慢做2小时刚好临界提交时就过期了。这个问题的解决方案是双层的前端在请求拦截器里统一捕获 401 状态码发现过期时先调用刷新 Token 接口刷新成功就自动重放原始请求而不是直接跳登录页后端把 Token 的有效期改成 8 小时同时用 Redis 维护一个活跃会话每次访问接口就刷新 Redis 里的过期时间相当于给活跃用户自动续期。// axios 响应拦截器里的自动续期逻辑 service.interceptors.response.use( (response) response, async (error) { if (error.response error.response.status 401) { try { const refreshRes await axios.post(/auth/refresh, { refreshToken: getRefreshToken() }); setToken(refreshRes.data.accessToken); // 重放原始请求 const config error.config; config.headers.Authorization Bearer refreshRes.data.accessToken; return service(config); } catch (refreshError) { router.push(/login); return Promise.reject(refreshError); } } return Promise.reject(error); } );前端这里有个实现细节要注意多个请求同时返回 401会同时触发多个刷新请求。我们一开始没加锁结果刷新接口被打了五六次后端压力不大但日志很丑。后来加了一个刷新请求的并发控制用一个 Promise 变量存住当前刷新任务其他请求都等待同一个 Promise 完成彻底解决了重复刷新问题。5.3 慢查询错题本页面刷了 5 秒问题在联表查询上线后学生反馈错题本页面特别慢点进去要等好几秒。查数据库慢查询日志发现是错题本列表接口的查询花了 4 秒多。SQL 大概是这样的逻辑查询错题表INNER JOIN 题目表、学科表、知识点表还要累加每个错题的错误次数。问题出在题目表按 student_id 关联查询时走了全表扫描。优化思路很直接错题本列表并不需要一次查出题目表全部字段只需要题干、答案、解析等几个关键字段而题目本身几乎是静态的很少修改。于是我们把题目表的关键内容做了 Redis 缓存错题本查询先按 student_id 从 MySQL 查出错题列表再把题目的详细内容从 Redis 批量取出来拼装数据库只承担轻量查询页面响应时间从 4 秒降到了 400 毫秒以内。这个方案说起来简单但做到了两点才会有效一是错题本列表接口返回前做了字段裁剪不返回题库里那些冗余字段二是 Redis 缓存设置了合理的过期时间题目内容修改后通过主动删除缓存来更新避免脏读。5.4 踩坑之后沉淀下来的固定上线检查清单这几轮上线踩坑下来后面再部署类似项目时我都会提前过一遍检查清单这里直接分享给你。数据库表有没有漏建唯一索引尤其是作业提交、错题本、用户班级关联这类高频写入表所有新增接口的返回值里有没有不小心带上答案字段这个要专门对一遍前端统一处理 401 自动续期和重放逻辑不要只拦截不重放文件上传配置了大小限制没有超限时前端提示是否友好生产环境的 Nginx 代理超时时间调过没有文件上传接口特别容易触发 504Redis 缓存键有没有做业务前缀隔离多个环境共用 Redis 时容易串数据这六条不一定全但都是我实际吃过的亏。尤其第二条前端同学可能不会主动发现问题要靠后端自查因为一旦答案泄露出去对学生考核的公平性影响非常大这个锅最后一定是后端的。6. 教辅平台做完之后的个人体会行星这个平台从需求评审到上线前后大概四个月。如果只挑最重要的复盘心得我想说三点。第一教育类系统的核心不是炫技是谁用着顺。老师要的就是三步发布作业学生要的就是打开就能做、提交别丢。我们中途好几个功能点都差点被产品经理拖着做复杂最后都靠“这不在核心循环里”给拦下来了。第二Spring Boot 加 Vue 的这套组合做这类系统是真的省心。框架把大部分琐碎细节兜住了我们能集中精力处理文件存储、Token续期、慢查询这些真实压力点。对中小团队和外包项目来说这套技术栈的容错率非常高。第三如果让我重新开工我会把题库的知识点体系设计得更早一些。它看似只是一个字典表实际上牵扯错题本、组卷推荐、学习数据看板是整个平台的数据骨架。前期多花三天把知识点树理清楚后期至少省下三周返工。最后再送一个小技巧。做教辅平台的联调时建议前端同学在浏览器里装一个网络请求拦截工具专门用来模拟请求失败、网络超时、Token过期这些异常场景。因为这类系统最怕的不是功能缺失而是像学生做到一半丢数据、提交时按钮反复点导致重复提交这类“体验事故”。把异常链路想得比业务链路更细这个项目就稳了大半。