高等数学教辅资源管理平台：SpringBoot+Vue全栈实战

1. 这个项目要解决什么从教辅资源分发乱象说起先讲一个很典型的场景。期末复习周某高校的高等数学任课老师想把历年真题、答案解析、知识点总结文档发给全年级三百多名学生最后发现没有一个通道能同时满足按章节归类、按权限控制、按需要检索这三个基本要求。QQ群文件七零八落、版本混乱公共邮箱容易被误删云盘链接随时可能过期。学生一边在群里反复问课件发到哪了一边下载到命名是最终版2(1)(3).docx的重复文件——这种体验做过教师端工作的人都懂。这个项目就是在这个背景下做的。它的核心定位不是又一个文件管理系统而是面向高等数学课程的教辅资源全生命周期管理平台从资源上传、审核、分类、入库到学生端检索、浏览、习题练习、学习记录反馈再到教师端的数据统计整条链路都用独立的模块去承载。简单说它把以前散落在各种聊天工具、网盘和个人电脑里的教学资料统一收编进一套有权限、有结构、可追踪的系统里。如果你是在做毕业设计、课程设计或者想找一个能完整覆盖 Web 全栈开发流程的练手项目这篇复盘应该对你有参考价值。它不涉及复杂的算法但把 SpringBoot 后端开发里最常见的业务场景——多角色权限控制、文件上传与检索、批量数据导入、热点资源的缓存、接口并发安全性——全部过了一遍。读完你至少能弄清楚一个典型的教学管理类系统从建表、写接口、联调前端到部署上线完整走一遍会遇到多少坑。2. 技术选型复盘为什么是 SpringBoot Vue MySQL 这个组合选型这件事很多初学者容易犯的毛病是什么新用什么。轮子越换越新最后打磨业务的时间所剩无几。这个项目我的选型结果非常主流但每条选择背后都有明确依据。2.1 后端骨架SpringBoot 3.x而不是更炫的响应式框架后端毫无疑问选了 SpringBoot。理由很务实生态成熟度高等数学教辅系统的业务模块本质上是标准 CRUD 加文件流转SpringBoot 在这类场景下有大量经过验证的组件不需要自己造轮子。团队协作门槛低如果这是一个多人协作的课程设计或实验室项目找会 SpringBoot 的人远比找会响应式编程的人容易。后续维护的人不用重新理解一套复杂的非阻塞模型。和前端分离天然契合SpringBoot 很适合做纯后端 API 服务。用RestController暴露 JSON 接口前端用 Vite 脚手架搭一套管理后台两边通过 HTTP 通信分工清晰。我特意没有选 JDK 17 以下的版本搭配旧版 SpringBoot直接用了 SpringBoot 3.x JDK 17。原因很简单3.x 的jakarta.*命名空间虽然让一部分老资料里的导入语句失效但换来的是长期维护支持和更好的性能基线没必要为了一时熟悉用老版本。2.2 数据与缓存方案MySQL Redis各管一摊数据存储分了两层。结构化数据全部进 MySQL用户、角色、资源元信息、习题内容、学习记录、评论反馈这些关系型数据天然适合用表来组织也方便后期统计。Redis 在主业务里做了两件事。第一件事是缓存高频访问的数据比如首页的热门资源榜和最近更新列表这些数据如果每次请求都查数据库压力不小但缓存之后接口响应时间可以从几十毫秒降到个位数毫秒。第二件事是处理一些需要临时状态的场景比如用户下载资源的频率控制、验证码的存储这类数据丢了一点问题不大但放数据库里又太浪费。用 Redis 的EXPIRE机制做自动过期正合适。文件本身存哪里本地磁盘肯定不行项目一迁移就全部失效。我引入了 MinIO 作为对象存储服务把上传的课件、习题附件、试卷文档统一存到 MinIO数据库里只存文件的访问路径和指纹信息。这样即便部署环境变化只要对象存储服务不变资源数据就不会丢。2.3 检索方案Elasticsearch或者一个折中方案高等数学的教辅资源里有大量 Word 和 PDF 文档。学生搜的是洛必达法则相关习题、不定积分公式总结希望系统能给出文档内容级别的匹配结果。如果只靠 MySQL 的LIKE %关键词%量小的时候没感觉一旦某门课积累了上万个文件查询会明显变慢而且对中文分词的支持非常差。正规做法是引入 Elasticsearch 做全文检索用管道把文档内容抽取出来写入 ES 索引查询时走 ES 的匹配接口。但完整的 ELK 链路部署成本较高如果只是想做个能用的系统我建议先用 MySQL 的全文索引加上按标题、标签、简介三个字段的匹配查询顶一段时间。这个项目最终采用了 ES不过这里有个经验不要一开始就上 ES先把业务跑通线上数据量达到一定级别后再迁移检索模块避免在项目初期被运维复杂度拖死。2.4 前端框架Vue 3 Element Plus三端适配前端分了两个端。管理后台教师和系统管理员用采用 Vue 3 Element Plus组件库现成、后台布局模板丰富开发速度快。学生端界面则是同套前端代码通过路由级别的移动端适配来实现重点保证手机浏览器上浏览课件列表、做在线练习的体验。为什么不做独立 App一门课程的教辅系统用户的真实使用场景是临时查个资料、做几道题轻量化的移动端网页足够覆盖做成原生 App 反而增加了发布成本和使用门槛。3. 数据模型设计从业务实体到数据库表的拆解过程数据库设计是这类系统能不能撑到后期扩展的分水岭。我见过太多人的表设计是先建五六张表写代码时发现字段不够再继续加最后表之间关系混乱SQL 越写越痛苦。这个项目的表设计我先把业务实体画出来再逐层拆解成表结构。3.1 核心实体关系拆解系统里最关键的实体可以归纳成六个方向用户与权限用户主体是教师、助教、学生三类外加一个系统管理员。权限要细化到谁可以上传、谁可以审核、谁可以下载、谁可以删除所以需要用户表、角色表、权限表以及用户与角色的关联表。课程与章节高等数学课程本身要单独建模。一门课程下面有多个章节函数与极限、导数与微分、不定积分、定积分等每个章节再关联不同的教辅资源。把章节独立成表是为了后续的按知识点检索和学情统计打基础。教辅资源资源分为课件、习题、试卷、视频链接、参考资料五种类型。一张资源主表保存名称、类型、所属课程、简介、文件路径、上传人、审核状态再配一张资源版本表记录同名文件更新时的版本迭代信息。习题与练习记录习题本身有题干、选项、正确答案、解析、所属知识点、难度系数。学生做练习时产生的作答记录单独建表包含学生 ID、习题 ID、作答内容、对错状态、耗时这是后续统计分析模块的数据来源。学习行为日志资源下载记录、在线预览时长、习题练习频次。这部分数据量增长很快初期可以放 MySQL如果未来做学情分析报表再考虑迁移到独立的日志存储。评论与反馈学生对资源质量打分、提交纠错建议形成教师改进资源内容的闭环。3.2 关键表设计要点用户表userCREATE TABLE user ( id BIGINT PRIMARY KEY AUTO_INCREMENT COMMENT 用户ID, username VARCHAR(50) NOT NULL UNIQUE COMMENT 登录账号, password VARCHAR(255) NOT NULL COMMENT 加密后的密码, real_name VARCHAR(50) NULL COMMENT 真实姓名, avatar_url VARCHAR(255) NULL COMMENT 头像访问路径, role_type TINYINT NOT NULL DEFAULT 3 COMMENT 角色类型: 1管理员, 2教师, 3学生, department VARCHAR(100) NULL COMMENT 所属院系, student_no VARCHAR(20) NULL COMMENT 学号, status TINYINT NOT NULL DEFAULT 1 COMMENT 账号状态: 1正常, 0禁用, created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, updated_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT用户表;这里有个容易忽略的细节密码字段长度至少 255因为未来可能升级加密算法旧的哈希值长度未必匹配 60 位。角色的存储我直接用了冗余字段role_type没做三张表的经典 RBAC 模型。对于规模有限的助教系统角色维度固定三种硬拆成五张表是过度设计后续真的要扩展粒度的权限可以在资源表上加可见范围字段兜底。资源表resourceCREATE TABLE resource ( id BIGINT PRIMARY KEY AUTO_INCREMENT, course_id BIGINT NOT NULL COMMENT 所属课程ID, chapter_id BIGINT NULL COMMENT 所属章节ID可为空表示全课程, resource_name VARCHAR(200) NOT NULL COMMENT 资源名称, resource_type TINYINT NOT NULL COMMENT 类型: 1课件 2习题 3试卷 4视频 5参考资料, description TEXT NULL COMMENT 资源简介, file_path VARCHAR(500) NOT NULL COMMENT 对象存储路径, file_size BIGINT NOT NULL DEFAULT 0 COMMENT 文件大小单位字节, file_md5 VARCHAR(64) NULL COMMENT 文件内容指纹用于秒传与去重, uploader_id BIGINT NOT NULL COMMENT 上传人ID, audit_status TINYINT NOT NULL DEFAULT 0 COMMENT 审核状态: 0待审核 1通过 2驳回, download_count INT NOT NULL DEFAULT 0 COMMENT 下载次数, created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, INDEX idx_course_chapter (course_id, chapter_id), INDEX idx_type_status (resource_type, audit_status) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT教辅资源主表;索引设计上要遵循查询优先的原则。系统最频繁的查询是某课程某章节下状态为审核通过的资源列表所以联合索引(course_id, chapter_id)和(resource_type, audit_status)必须建。上传资源列表里必然有课程审核状态的组合条件索引覆盖不到的话数据量过万后性能立刻变差。习题表question习题表的设计自由度比较大难点在于答案的存储。选择题的选项我采用 JSON 字段把 A/B/C/D 四个选项一次性存入options字段正确答案单独存一个answer字段。这样既保留了灵活性又避免做正交表把问题复杂化。判断题用answer存正确/错误文本填空题则用多个|分隔的答案列表。CREATE TABLE question ( id BIGINT PRIMARY KEY AUTO_INCREMENT, chapter_id BIGINT NOT NULL COMMENT 所属章节ID, question_type TINYINT NOT NULL COMMENT 题型: 1单选 2多选 3判断 4填空 5解答, content TEXT NOT NULL COMMENT 题干内容, options JSON NULL COMMENT 选项内容JSON格式适用于选择题, answer TEXT NOT NULL COMMENT 标准答案解答题存要点提示, analysis TEXT NULL COMMENT 解析内容, difficulty TINYINT NOT NULL DEFAULT 3 COMMENT 难度系数: 1-5, creator_id BIGINT NOT NULL COMMENT 创建人ID, audit_status TINYINT NOT NULL DEFAULT 0, created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, INDEX idx_chapter_type (chapter_id, question_type) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT习题表;学习记录表study_record学习行为数据是这个系统后续最有价值的部分。它能回答教师最关心的一个问题哪些章节学生练得少、错得多记录表按学生习题作答时间的维度建模。每次作答插入一条记录统计时用COUNT()和GROUP BY就能得出正确率、练习量等指标。实际开发中要特别注意不要在每次请求时都去查总表做统计应该在学生提交练习之后异步更新一张学习统计汇总表秒级可查。3.3 数据库层面容易忽略的坑字符集一定要用utf8mb4因为学生上传的文档名里可能有生僻字和特殊符号MySQL 老版本默认的utf8mb3无法完整支持四字节字符会出现乱码。排序规则选utf8mb4_general_ci足够没必要上unicode_ci性能差异不大。时间字段统一使用DATETIME不要用TIMESTAMP。TIMESTAMP的取值范围到 2038 年而且受时区影响排查问题时会增加认知负担。所有表加created_at和updated_at这个习惯能让你在后面写数据修复脚本时省很多事。4. 核心业务模块拆解文件流转、权限控制和练习与组卷数据库结构定好之后真正的业务逻辑才是工作量最大头的地方。我把系统按模块拆解成了五块资源上传审核模块、课程与章节管理模块、习题与组卷模块、在线练习与学习记录模块、用户与权限模块。这里挑三个最有代表性的模块重点讲。4.1 教辅资源上传与审核的完整流程资源上传是系统的入口流程设计直接决定教师愿不愿意用这个系统。完整的流程是教师登录后进入课程空间选择所属章节上传文件到 MinIO 对象存储拿到文件路径和 MD5 指纹填写资源名称、类型、简介提交后进入待审核状态管理员或助教审核通过后资源对学生可见。实现上文件上传接口有一个规格限制单文件大小不能超过 100MB超过部分采用前端分片上传。分片上传在后端接口中需要接收两个参数chunkIndex当前分片序号和chunkTotal总片数。前端用File.slice()切分文件按顺序发起请求后端临时目录接收分片全部传完后按顺序合并文件计算 MD5然后存到对象存储。合并完成后清理临时分片避免垃圾文件积累。要特别提醒一个坑在上传接口里RequestParam(file) MultipartFile file的参数名必须和前端FormData中 append 的 key 完全一致。我见过不少人这里前后端各写各的前端传file后端写multipartFile上传请求一直没有反应控制台也不报错浪费了大量排查时间。审核流程的核心是状态机设计。audit_status只有三个值但状态流转要严格限制只有待审核才能变成通过或驳回通过不能直接打回驳回的资源可以修改后重新提交。我在 Service 层写了一个checkStateTransition(current, target)的私有方法所有接口在更新状态前都必须经过它防止逻辑漏洞。4.2 三角色权限控制不再只靠 if-else 判断身份用户权限这块如果只在每个 Controller 里写当前用户是不是教师的判断代码会迅速腐烂。系统里每个角色能做的事情不同教师含助教上传资源、创建习题、布置练习任务、查看所授课程的学习统计学生浏览和下载审核通过的资源、在线做题、查看个人练习记录系统管理员管理用户账号、审核资源、管理课程与章节、处理举报反馈。实现上我用了两套机制叠加。第一套是 Spring Security 的注解驱动控制在方法上标注PreAuthorize(hasRole(TEACHER))由框架统一拦截非法访问。第二套是数据级权限控制教师只能看自己创建的资源学生只能看审核通过且所属课程对自己开放的资源。数据级权限必须在 SQL 里带上WHERE条件不能取全量数据再到程序里过滤否则随着数据量增长系统一定会越来越慢。以一个查询资源列表接口为例Override public PageResultResourceVO listResource(ResourceQuery query) { User currentUser SecurityUtils.getCurrentUser(); LambdaQueryWrapperResource wrapper Wrappers.lambdaQuery(); // 学生只能看审核通过的 if (currentUser.isStudent()) { wrapper.eq(Resource::getAuditStatus, AuditStatus.APPROVED.getCode()); } // 教师只能看自己上传的 if (currentUser.isTeacher()) { wrapper.eq(Resource::getUploaderId, currentUser.getId()); } wrapper.eq(query.getCourseId() ! null, Resource::getCourseId, query.getCourseId()); wrapper.orderByDesc(Resource::getCreatedAt); PageResource page new Page(query.getPageNum(), query.getPageSize()); PageResource result resourceMapper.selectPage(page, wrapper); return assemblePageResult(result); }LambdaQueryWrapper这种链式条件写法比拼 Sql 字符串维护起来舒服得多。MyBatis Plus 在中小型项目里我基本都会用MyBatis-Plus作为持久层框架它把单表 CRUD 的模板代码全部省略了对于学生角色管理端和移动端可能还有 H5 端的适配。4.3 在线练习与自动组卷高频模块的性能优化在线练习是学生使用频率最高的模块。学生的诉求很单纯进入页面、看到一组题、作答提交、当场看到对错和解析。组卷逻辑我设计成三个维度章节范围、题型构成、难度系数。教师发起练习任务时选择第一章到第三章、单选 5 题、判断 3 题、解答 2 题、难度 2~4 之间系统从习题表里随机抽取符合条件的题目。随机抽取如果用ORDER BY RAND()实现数据量过万后性能惨不忍睹。我换了个思路先用查询条件查出符合条件的题目 ID 集合在内存里用Collections.shuffle()打乱后取前 N 条然后一次性SELECT出完整题目记录。对于练习题量只有几千条的规模这个方案足够高效。作答提交时前端逐题上传答案后端按题逐个比对。这里要控制接口的粒度不要每道题一个请求而是一次提交一个完整练习任务的所有答案。后端遍历作答列表、逐题判定并最终汇总正确率。整个判定过程没有复杂的分布式事务需求用数据库事务保证同步更新练习记录、题目作答明细、统计汇总表三张表即可。在做题体验上有一件很影响感受的小事在线编辑数学公式。正则表达式对纯文本的识别效果不错但如果学生需要输入根号、分式、积分符号纯文本完全不够用。我在这套系统里接入了轻量级的数学公式编辑组件支持 LaTeX 语法渲染。解答类题目用 LaTeX 作为标准输入格式统一存储和渲染这其实比富文本编辑更省心——存的是语法字符串渲染时才生成图片或 HTML查询、搜索都不受影响。5. 高频接口的性能优化与安全策略群体下载场景的应对学生用户有一个明显的使用高峰课程结束前一个月大量学生集中下载课件、刷题库。这部分流量和普通 Web 访问不一样瞬时并发高、重复请求多、下载量大。我主要从缓存、接口防刷、全文搜索三方面做了应对。5.1 资源列表接口的 Redis 缓存策略首页和章节详情页的资源列表是典型的高频读场景。直接查 MySQL 的数据每次平均响应约 15ms感觉还行但高峰期接口的 QPS 冲到 200 以上时数据库连接池容易被占满其他低频管理的接口跟着全部排队。我用 Redis 做了两级缓存一级缓存资源详情数据按资源 ID失效时间 30 分钟二级缓存章节资源列表按课程章节 ID失效时间 10 分钟。缓存更新策略不搞太复杂就采用先更新数据库再删除缓存的方式。发送删除缓存的延迟消息防止并发读把旧数据又塞回缓存。这个方案在实践里已经足够避免了引入消息队列组件后带来的运维负担。一个教训不要把 Redis 缓存失效时间设置得太长。有段时间我把资源列表缓存设为 24 小时导致教师修改资源简介后学生端怎么刷新都看到旧描述。这类管理系统对数据实时性是有要求的10 分钟以内是合理区间。5.2 防刷限制别让接口裸奔一个没有频率控制的下载接口在期末复习周很可能被各种爬虫脚本反复穿透。我用了两个层次的防刷单用户维度Redis 里设置rate:user:{id}:{resourceId}的 Key60 秒内同一个用户对同一个资源的下载请求只放行一次利用SETNX和EXPIRE实现IP 维度同一 IP 每分钟接口调用超过 120 次则限流返回提示信息由全局过滤器统一处理。防刷要考虑误伤问题。学生可能在自习室用同一网关 IP限流阈值一定要留足浮量IP 限流只做兜底不要设得太敏感。5.3 分页查询的深坑深分页问题后台管理端资源管理列表页面的分页查询是典型的高基数数据查询。最初我写的分页方式是LIMIT 10000, 20数据量来到 5 万条时这个查询耗时能到 5 秒以上。原因是 MySQL 需要先扫描前 10000 条记录再扔掉越往后越慢。修正方案是把普通分页改成游标分页。传入上一页最后一条记录的id查询条件变成WHERE id ? ORDER BY id DESC LIMIT 20这样每次查询都只扫描目标范围内的数据速度恒定。缺点是无法直接跳转到任意页但对于后台管理端的操作习惯来说完全够用。public ListResource listResourceWithCursor(Long cursor, Integer limit) { LambdaQueryWrapperResource wrapper Wrappers.lambdaQuery(); wrapper.lt(cursor ! null cursor 0, Resource::getId, cursor) .eq(Resource::getAuditStatus, AuditStatus.APPROVED.getCode()) .orderByDesc(Resource::getId) .last(LIMIT limit); return resourceMapper.selectList(wrapper); }5.4 安全加固的三件基础事这个系统不涉及支付交易安全上不需要过度设计但三件事必须做。第一密码绝不存明文。用 BCrypt 加密算法做密码哈希PasswordEncoder直接注入使用。授权方案用 JWT无状态令牌登录成功后服务端返回签名后的 Token前端在后续请求的Authorization头中携带。JWT 本身有泄露风险所以我把过期时间设成 24 小时并配合 Redis 做 Token 黑名单机制用户主动退出时立即失效。第二跨域配置必须显式设置。前后端分离部署时前端管理后台跑在 5173 端口后端跑在 8080 端口所有浏览器请求都是跨域请求。我在后端定义了一个全局的跨域配置类允许的源地址写死为前端地址绝不使用allowedOriginPatterns(*)。第三大文件上传要做类型校验。很多人只检查文件后缀名这远远不够。上传接口校验时要同时读取文件的 MIME 类型并配合MagicNumber判断文件真实格式。比如 PDF 文件的开头字节必然含%PDFWord 文件开头有特定的OLE2或ZIP标记。否则用户改了后缀名传上来一个伪装成课件的东西审核系统和学生端都毫无防备。6. 部署经验与排错记录这套系统上线中遇到的三个实际问题代码写完后真正的考验才开始。这里记录三个最有代表性的部署与排错问题它们的排查链路值得完整走一遍。6.1 中文文件名上传后变成乱码问题现象学生在 Windows 上上传高等数学-第一章-极限课件.pdf管理后台显示的文件名是一串乱码。排查链路第一步检查前端。前端用FormData上传时Content-Disposition中的文件名默认是 UTF-8 编码但浏览器配置和历史因素可能导致编码不一致。第二步检查后端接收。SpringBoot 默认对请求参数的处理使用charsetUTF-8最初我以为是配置问题检查server.servlet.encoding配置发现没错。第三步发现真正的根因Nginx 反代层没有正确传递请求头默认proxy_set_header没有把X-Forwarded-*之外的编码信息透传。实际上更准确地说是 Nginx 用默认的 ISO-8859-1 对了文件名做了重新编码。解决方案在 Nginx 配置的proxy_pass后面显式添加proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; charset utf-8;同时在后端解析文件名时对filename参数做一层兼容处理若是filename*格式则按 UTF-8 解码。这个坑只在 Windows 客户端 Linux 服务器 Nginx 反代三者同时出现时才会暴露本地开发环境完全测不出来。6.2 事务不生效Service 内部方法调用的经典问题问题现象教师删除一个课程资源时系统提示删除成功但数据库里资源记录还在。排查链路看到现象第一反应是Transactional没生效。检查了 Service 类、方法是不是 public、事务管理器配置都没有问题。最后发现真相Controller 注入的是ResourceService接口但实现类里定义了两个方法。deleteResource()方法里直接调用了同一个类内的removeResourceData()方法这个方法标注了Transactional然而 Spring 的声明式事务基于代理模式同类内部方法之间的this调用不会经过代理对象因此事务注解完全失效。解决方案结构重构把removeResourceData()的逻辑抽到一个独立的ResourceSupportService组件里由deleteResource()调用这个外部组件的开放方法。或者在外部配置一个事务性更强的方法让事务粒度覆盖到全部子操作。这类问题经典的排查手段就是看一下调用链路里有没有同类自调用。6.3 数据库连接池耗尽一个慢查询拖垮整个服务问题现象线上运行两周后某个时间点服务突然大面积超时后端日志中出现Connection is not available, request timed out after 30000ms。排查链路先看慢查询日志发现有一条 SQL 特别可疑在学习统计页面查询全年级某章节平均正确率时SQL 对study_record和question做了嵌套子查询中间结果集超过 20 万行执行耗时 6 秒以上。这条慢查询每触发一次数据库连接被占用 6 秒。在期末练习高峰期学生端同时做练习数据库连接池告急。解决方案第一步把统计查询改成异步执行。用户进入学习统计页时接口立刻返回统计数据生成中后台通过线程池异步计算完成后写入统计汇总表页面轮询获取结果。第二步优化原始 SQL。原来三次嵌套的IN子查询改为两段独立查询在应用层做数据拼装。第三步调整连接池参数。核心线程数从初始值调大到当前并发量的 1.5 倍最大连接数、等待超时时间都按线上监控数据重新配置。这个问题的本质暴露了一个设计缺陷在线业务和统计业务不能共享同一个数据源连接池。如果继续扩展应该把统计分析的数据导出到独立只读实例和在线业务物理隔离。7. 回头再看一次这个项目我最后想补的三处设计项目上线之后我对整个系统复盘了几轮其中有三个设计点如果重做一次会按照不同的思路处理。第一文件服务的存储抽象层应该在项目第一天就写好而不是第 15 天再补。我当时直接调用了 MinIO 的客户端代码后来测试环境和生产环境的存储桶配置不同代码里散落了一堆new MinioClient(...)的初始化逻辑。正确做法是定义一个FileStorageService接口包含upload、getFileUrl、deleteFile三个方法底层用 MinIO 实现将来换阿里云 OSS、腾讯云 COS 时只需要新增一个实现类。我在项目后期花了半天时间做了这个重构虽然不算太晚但前期如果写好可以省掉大约几十处调用代码的修改。第二练习题的知识点标签应该在初始阶段做结构化设计而不是让每个教师随意填写关键词。我做系统时在习题表里预留了chapter_id但函数极限这个知识点既属于第一章也和连续性的理论直接相关单一章节归属不够用。后续如果要基于知识点做精细化的学情分析需要单独建一张知识点表并在习题和知识点之间建立多对多关联。第三不要把业务日志和访问日志混在同一张表里。试运行阶段我看后台记录发现张三下载了课件和系统检测到上传失败混在一起排查问题时很难区分。如果时间充裕应该用 logback 或 Log4j2 的异步日志输出链路让业务日志直接进文件或独立库表通过交易流水号串联而不是依赖数据库后置写入。做这个项目从头到尾差不多花了两个多月大部分时间不是花在写 CRUD 接口上而是花在想清楚什么人用什么方式用什么数据这个问题上。高等数学教辅资源听上去是个很垂直的小系统但把它从零搭起来等于把教育信息化里最常见的一个分支完整摸了一遍。如果你也正在规划类似的课程资源类系统我的建议是先画清楚角色和状态机再动手建表写接口上线前多模拟几次并发场景别让接口裸奔在生产环境里。