SpringBoot2+Vue3在线考试与学习交流系统开发实战解析

做了好几个 Java Web 课设说实话最让我耗时间的不是代码本身而是把业务关系想清楚。这次要聊的是一个基于 SpringBoot2 Vue3 MyBatis-Plus MySQL8.0 的“Java Web 语言在线考试与学习交流网页平台系统”标题看着长核心就两件事在线考试、学习交流。对大部分学生或刚转行的开发者来说这类系统是很好的练手素材因为它的业务边界相对清晰涉及的前后端交互点又足够多。本文不按教科书口吻讲就按实际开发顺序把自己的理解、设计取舍、踩过的坑全部展开希望能帮你省点弯路。1. 为什么选“在线考试学习交流”这个业务组合1.1 在线考试的核心痛点在线考试不是简单地把纸质试卷搬到网页上。真实场景里教师需要批量出题需要设置考试时间和时长需要自动统计成绩学生需要看到题目、完成答题、在规定时间内提交。这里天然包含两个核心对象试卷和答题记录。试卷又分为题目集合和分值规则答题记录则需要记录每道题的用户选项才能支持后续的得分计算和错题回顾。从开发角度讲这个业务域能把“一对一、一对多”这些关系都用上。一个用户有多条考试记录一条考试记录对应多道题目的答题明细。如果只在脑子里想着“用户表、试卷表、结果表”就动手写数据库会越来越乱。我见过不少项目把答题明细存在一个字段里比如“1:A,2:B,3:C”这种设计在演示阶段没问题一旦要按题目统计正确率或者批量导出成绩就会很难受。所以我在设计时把答题明细单独拆成一张表具体原因后面细说。1.2 学习交流模块的角色学习交流模块在这个系统里不是凑数的。它存在的意义是让整个平台在“考试”这种低频强交互场景之外有一个高频、轻量的内容场景。学生考完试可以发帖交流教师可以在帖子里答疑管理员还能做内容管理。这给项目增加了一个很关键的复杂度内容发布与列表展示。交流模块要处理帖子列表分页、发帖人信息联查、评论嵌套等问题很多初学者觉得“发帖嘛就是往表里插一条记录”但真正做起来会发现帖子和评论的查询性能、敏感词过滤、权限控制都是额外成本。把两个模块放在同一个平台里还有一个很实际的理由演示和答辩的时候你能讲的故事更完整。考试模块证明了你对业务数据建模和事务处理的理解交流模块证明了你对列表查询、权限拦截和前后端交互的掌握。两者拼在一起系统不是一堆孤立接口的堆叠而是一套有真实使用场景的产品。1.3 面向的用户角色与权限我按三种角色来划分管理员、教师、学生。管理员管用户和内容教师管试卷和题目学生参加考试和发帖交流。权限控制如果不做演示时还能勉强用一旦上线就没有安全感。实际项目里我用的是简单的拦截器加角色枚举没有引入特别重的权限框架因为角色数量固定业务规则也简单。拦截器的核心逻辑只有两步从请求头拿到 token解析出 userId 和 role再判断当前请求的 URL 是否需要特定角色。SpringBoot 里可以用 HandlerInterceptor 实现注册到 WebMvcConfigurer 里。这个方案足够应付中小型项目而且答辩时容易讲清楚比引入 Spring Security 但只用了其中一小部分功能要实在得多。2. 技术栈取舍SpringBoot2 Vue3 MyBatis-Plus MySQL8.0 为什么能搭到一起2.1 后端SpringBoot2 仍是主流基线截止到当前主流课程设计和公司内部项目SpringBoot2 依然是很多团队的实际选择。SpringBoot3 已经发布但大量第三方集成和旧教程还停留在 2.x尤其是 MyBatis-Plus 与 SpringBoot3 的兼容版本要求更严格。所以这个项目选 SpringBoot2 是稳妥的。它最核心的价值是自动配置。以前用 SSM 需要写一堆 XML 配置SpringBoot 用 starter 把所有可以自动装配的内容都处理了开发者只需要关心自己的业务逻辑。比如 spring-boot-starter-web、spring-boot-starter-validation 这些一加依赖就等于把常用能力都带进来。版本上建议用 2.7.x 的最后一个维护版本兼容性和稳定性都是 2.x 里最好的。2.2 前端Vue3 的 Composition API 实际改善了开发体验Vue3 相比 Vue2 最大的变化是 Composition API。对于考试页这种状态多的界面Composition API 能让你把“倒计时剩余时间”“当前题目索引”“答题记录 map”等相关变量集中管理而不是在 data、methods、computed 之间来回跳。很多人问 Vue3 难不难我的观点是如果没写过 Vue2直接学 Vue3 反而更顺如果写过 Vue2需要花点时间切换思维。本项目选 Vue3 是顺着技术趋势走配合 Vite 开发时体验很好项目冷启动和热更新都比 Vue CLI 快不少。有一点要提醒Vue3 项目默认用的是 ESM 模块规范有些旧教程里的 require 写法不能直接用遇到“Cannot use import statement outside a module”这类报错时先检查 package.json 里有没有 type: module。2.3 数据访问MyBatis-Plus 相比 JPA/原生 MyBatis 的取舍MyBatis-Plus 是 MyBatis 的增强工具核心卖点是内置通用 CRUD。JPA 也很方便但多表关联和复杂查询反而难控制 SQL原生 MyBatis 灵活但单表 CRUD 的 XML 写多了确实枯燥。MyBatis-Plus 正好在两者之间。比如分页查询只要配置一个分页插件调用 selectPage 就能拿到分页结果不用手动写 limit 计算。对于“用户、试卷、题目、答题记录”这些以单表为主、偶尔多表联查的业务它很合适。另一个实用功能是 LambdaQueryWrapper代码里写 eq(QuestionDO::getExamId, examId) 比手写字符串列名更安全编译期就能发现字段名拼写错误。MyBatis-Plus 也不是万能的。复杂多表 join 时我还是建议写 XML 里的自定义 SQL比如成绩排行榜需要联查 user 表和 exam_record 表用注解或 Wrapper 反而绕XML 里一句 SQL 就写清楚了。2.4 数据库MySQL8.0 的选择理由与注意点MySQL8.0 相比 5.7 有更好的性能和更清晰的字符集默认配置。默认 utf8mb4能直接存 emoji 表情这对学习交流模块很关键——帖子内容里出现表情是常见场景。注意点有两个。一是驱动类名和连接串变化了com.mysql.jdbc.Driver 在 8.0 中已经不建议使用要用 com.mysql.cj.jdbc.Driver连接串最好加上 allowPublicKeyRetrievaltrue 和 useSSLfalse 参数否则连接时会报错或提示。二是时区问题连接串要带上 serverTimezoneAsia/Shanghai否则后端日志会一直刷警告某些情况下还会导致时间字段相差 8 小时。MySQL8.0 的 root 用户默认加密方式可能和老纳维卡特客户端不兼容需要统一改成 mysql_native_password这个坑在部署那一节再展开讲。3. 数据库建模把用户、试卷、答题记录、交流帖子一次理清3.1 七张核心表的职责划分我建表喜欢先按“模块 业务关系”来。这个系统最终落到七张核心表用户表user、考试试卷表exam、题目表question、考试记录主表exam_record、答题明细表exam_record_detail、帖子表post、评论表comment。下面是字段设计时最核心的几张表结构新建数据库脚本时可以直接参考表名关键字段说明userid, username, password, role, avatar, create_timerole 用字符串存ADMIN / TEACHER / STUDENTexamid, name, duration, start_time, end_time, total_score, creator_idduration 单位用分钟start_time 和 end_time 控制考试窗口questionid, exam_id, content, options, answer, score, sortoptions 用 JSON 字符串存选项数组answer 存正确选项exam_recordid, exam_id, user_id, start_time, submit_time, score, statusstatus 标记考试中或已提交exam_record_detailid, record_id, question_id, user_answer, is_correct每道题一条记录postid, user_id, title, content, create_time, view_count交流帖子commentid, post_id, user_id, content, parent_id, create_timeparent_id 为空表示一级评论3.2 试卷表与题目表的关联设计试卷和题目是一对多关系question 表里用 exam_id 外键关联 exam 表。这种做法最大的好处是改卷时只需查一次题目列表按试卷 id 过滤即可。题目表里我把 options 字段设计成 JSON 字符串比如 [选项A内容,选项B内容,选项C内容,选项D内容]answer 字段存 A 或 B。很多初学者喜欢给每个选项建一个字段option_a、option_b、option_c、option_d这种设计在选择题里勉强能用但一旦出现不定项选择或者填空题表结构就不够灵活了。用 JSON 数组存储前端拿到后 foreach 渲染就完事后端也不需要拆字段整体更规整。MySQL8.0 对 JSON 类型支持很成熟甚至可以针对 JSON 字段建虚拟列索引但这个系统暂时用不到有兴趣可以往深处研究。3.3 考试记录明细表的设计关键exam_record 保存某次考试的整体信息比如用户、试卷、开始时间、提交时间、最终得分exam_record_detail 保存每一道题的作答结果字段包括 record_id、question_id、user_answer、is_correct。拆成两层的最大好处是可以按题目做统计。后来我想看“整份试卷哪道题正确率最低”直接对 exam_record_detail 按 question_id 分组统计 is_correct 为 true 的数量就行。如果只存一个总分的表这种统计永远做不了。还有就是答题卡恢复能力用户刷新页面后前端可以拿到作答明细重新勾选不用重新做。有一点要注意明细表的数据量会随着考试次数线性增长。如果系统里有一百个学生、每人参加十次考试、每次五十道题明细表会有五万条记录。对于本项目的规模来说完全够用但如果你计划做大规模并发考试后续可以考虑按考试场次分表这个后续演进章节会提。3.4 学习交流模块的表设计post 表存储帖子的标题、正文和浏览数。comment 表用 parent_id 支持两级评论比如“回复某人的回复”。如果只看评论展示一级评论也够用但加一个 parent_id 字段后续要做楼中楼时就不用改表结构。查询时要注意联表操作。帖子列表页需要显示作者名因此 post 表要 join user 表评论列表需要显示评论人昵称和头像comment 表也要 join user 表。建议在 post(id, create_time) 和 comment(post_id, create_time) 上建立联合索引否则随着帖子数据增长列表分页查询会越来越慢。这个系统里数据量不大但我还是提前把索引加上了养成好习惯。4. 后端核心实现链路鉴权、接口、自动判卷4.1 登录与鉴权从 Session 到 JWT 的落地这种前后端分离项目我选择 JWT 而不是传统 Session。原因是前端有可能部署在另一台服务器Session 依赖 Cookie 和服务器内存跨域互通比较麻烦。JWT 是无状态的后端只负责签发和校验。具体实现上用 jjwt 库生成 token登录成功后返回给前端。前端每次请求在 Authorization 头携带 token后端写一个拦截器统一解析。拦截器里解析出 userId 和 role放入 ThreadLocal 或请求属性后续 Controller 直接用。对于角色判断我在拦截器里维护一个“请求路径前缀到角色”的映射关系比如 /admin/** 要求 ADMIN/teacher/** 要求 TEACHER其他路径登录即可访问。JWT 有一个缺点需要注意token 无法在后端主动失效。如果用户被管理员封禁他手里的 token 在过期之前还是能访问接口。解决方法有几种比如把 token 版本号放进数据库、用 Redis 维护黑名单但这些都会增加复杂度。课程设计级别的项目我建议只做“用户状态校验”和“token 过期时间”这两件事把代码量控制住讲清楚原理就行。4.2 基于 MyBatis-Plus 的试卷接口开发用 MyBatis-Plus 写 exam、question 两个表的 CRUD 很高效。新增试卷时直接 examMapper.insert题目批量插入用 questionMapper.insertBatchSomeColumn这个方法是内置自定义注入器的一部分需要在 Mapper 接口里声明一下题量小的时候循环 insert 也完全没问题不用过度设计。列表查询只需要查试卷表因为列表页不需要题目详情。考试详情页需要联查题目我在 Service 层组装先查 exam再查 question list然后把返回结果合并成 ExamDetailVO。这种手动组装比数据库 join 更直观而且题目列表本来就是要全部读取的不会产生 N1 查询问题。写接口时有一点要养成习惯返回给前端的数据结构统一用 { code, message, data } 包装。我写了个 Result 类所有 Controller 都返回 Result.success(data) 或 Result.error(xx)。这一层抽象在联调阶段价值很大前端拦截器只要判断 code 是否为 0不用针对每个接口单独处理。4.3 自动判卷的核心逻辑与边界情况自动判卷是整个系统最有含金量的部分。核心逻辑不复杂遍历答题明细比对正确答案累加分数。但边界情况很容易踩坑。多选题的答案比较是一个典型问题。如果用户选的顺序是 C、A而正确答案存的是 A、C直接字符串比较就会失败。我的解决方案是前端提交前对每个多选题的答案做排序后端也排序后再比较两边按统一规则处理。这个统一规则必须写清楚否则你明明改了对的题系统却判错分。重复提交问题也要处理。我在 exam_record 表上建了 (exam_id, user_id) 的唯一索引同一个用户同一场考试只能有一条主记录。用户点提交时后端先查是否存在已经提交的记录如果存在就直接返回已有成绩不允许覆盖。这里不能用 selectById 之后判断因为并发情况下两个请求同时查到“不存在”就会插入两条记录唯一索引才是真正的兜底。4.4 考试防切屏、倒计时与提交策略这个功能我做成后端校验为主、前端体验为辅。后端记录考试开始时间提交时判断是否超时前端负责倒计时和防切屏提醒。防切屏最简单的方案是在浏览器端监听 visibilitychange 事件切出页面时提示并记录次数。服务器端很难感知用户是否切屏除非做大量埋点对于课设或中小型项目做到前端提醒加后端超时校验就够了。倒计时结束前端自动提交后端还需要在提交时再校验一次考试时间防止用户修改本地时间。后端超时判断的逻辑很简单提交时间减去考试记录的开始时间如果大于 exam.duration 指定的分钟数就按超时处理。我见过一些项目只在数据库里存 start_time 和 submit_time判卷时直接用 submit_time一旦有人篡改前端时间就能绕过限制。后端一定不能完全信任前端传过来的参数每次提交都拿服务器时间为准这是做考试类系统的基本素养。5. 前端 Vue3 页面实战考试页、社区页与后端联调5.1 用 Vite 初始化 Vue3 工程与路由规划项目用 Vite 创建 Vue3 工程命令是 npm create vitelatest frontend -- --template vue。创建完成后装上 vue-router 和 axios 就能开工。路由规划大概分几组/login 登录页、/exam/list 考试列表、/exam/:id 考试详情、/score 成绩页、/community 帖子列表、/post/:id 帖子详情、/admin 后台管理。路由守卫里面判断 localStorage 里有没有 token没有就跳登录页。这里要注意token 存在 localStorage 里有 XSS 风险更严谨的做法是存内存变量加刷新重新获取但课程设计项目里用 localStorage 是主流做法演示方便只要注意不要在前端打印 token 即可。5.2 考试页的倒计时与答题卡联动考试页是整个系统交互最复杂的页面。我的实现思路分成三块答题状态、倒计时、答题卡联动。答题状态用一个 reactive 对象存储key 是题目 idvalue 是用户选项。运行时不管用户点击上一题、下一题还是直接点答题卡跳题都只更新这个对象。答题卡渲染时根据对象里是否有对应 key 来染色。有值显示绿色没值显示灰色一目了然。一个典型的 Vue3 片段帮助理解script setup import { reactive, ref, onUnmounted, computed } from vue const answers reactive({}) const currentIndex ref(0) const remain ref(3600) let timer null const questionList ref([]) const selectOption (questionId, optionValue) { answers[questionId] optionValue } const isAnswered (questionId) { return answers[questionId] ! undefined answers[questionId] ! } const startCountdown () { timer setInterval(() { remain.value-- if (remain.value 0) { clearInterval(timer) // 自动提交逻辑 submitExam() } }, 1000) } onUnmounted(() { clearInterval(timer) }) /script倒计时组件这里我直接用 setInterval每秒递减。一个容易忽略的小细节是组件卸载前必须 clearInterval否则页面跳走之后计时器还在跑会在后台一直调用接口白白浪费服务器资源。5.3 学习交流页面帖子列表与评论组件帖子列表页只需要标题、作者、时间、浏览量点击进入详情。详情页的评论组件要支持发评论、展示子评论。后端接口返回扁平列表前端根据 parent_id 自己拼树这样能减少联表 SQL 的复杂度。具体拼树逻辑不复杂先把一级评论放在数组头上如果一个评论的 parent_id 等于另一个评论的 id就挂到后者的 children 字段下。注意评论排序要按照时间正序否则用户会搞不清楚讨论顺序。帖子内容如果包含换行和表情前端展示时注意 white-space 属性接口存储时依赖 MySQL8.0 的 utf8mb4 字符集基本不会出乱码。页面交互上发完评论后我建议重新拉取整个评论列表而不是用 push 把新评论插进数组。因为评论还需要把用户昵称和头像联查出来新评论对象里可能没有这些信息重拉一次最省事。等以后数据量大了再优化成“只返回新评论对象然后前端插入”的方式。5.4 Axios 封装与 token 刷新处理Axios 封装要处理三件事统一添加 Authorization 头、统一响应拦截处理业务码失败、统一处理 401 跳转登录页。我的做法是在 request.js 里创建一个 axios 实例配置 baseURL 为 /api然后在请求拦截器里从 localStorage 取 token 塞进 header。响应拦截器判断后端返回的数据结构如果 code 不是 0 就弹出提示信息比如“试卷不存在”或“考试已结束”。如果后端返回 401 状态码就清空本地 token 并跳转登录页。这里要注意区分后端自定义业务错误和 HTTP 状态错误。我的项目里业务逻辑错误统一返回 HTTP 200 code 非0只有 token 无效时才用 HTTP 401这样前端拦截逻辑最清晰。token 过期如果不希望用户太频繁重登可以做一个 refreshToken 机制但会增加后端复杂度。对于课程设计级项目我建议只做 accessToken 过期后跳登录。代码简单容易讲清楚也足够应付演示场景。6. 部署与排错复盘MySQL8.0、MyBatis-Plus、Nginx 的几个深坑6.1 本地环境版本选择对照先把版本环境列出来避免后面折腾。我实际使用的版本组合是比较稳妥的组件推荐版本说明JDK1.8 或 11SpringBoot2.7 都支持SpringBoot2.7.x最后一个 2.x 维护版本MySQL8.0.x用官方安装包或 Docker 都可以Node.js16 以上Vite5 需要 18 以上建议用 18 LTSMyBatis-Plus3.5.x对应 SpringBoot2Maven3.6后端依赖管理Nginx1.20前端静态资源服务和反向代理6.2 MySQL8.0 时区与连接驱动问题在 application.yml 里数据库连接串这样写spring: datasource: url: jdbc:mysql://localhost:3306/exam_db?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/ShanghaiuseSSLfalseallowPublicKeyRetrievaltrue username: root password: xxxxxx driver-class-name: com.mysql.cj.jdbc.Driver如果少了 serverTimezone连接时可能报错或者警告同时 MySQL8.0 的驱动类不再是 com.mysql.jdbc.Driver如果从旧项目复制配置启动会直接失败。allowPublicKeyRetrievaltrue 主要解决 MySQL8.0 默认 caching_sha2_password 认证插件在 JDBC 连接时对公钥获取的限制不加这个参数有时会出现 Public Key Retrieval is not allowed 的报错。6.3 MyBatis-Plus 分页插件踩坑记录MyBatis-Plus 的 selectPage 不能直接用必须先配置分页插件否则分页不生效且不会报错。这个问题我印象太深了第一次用的时候接口返回的数据一直在变但 total 始终是 0查了半天才发现是分页插件没配置。配置其实很简单Configuration public class MybatisPlusConfig { Bean public MybatisPlusInterceptor mybatisPlusInterceptor() { MybatisPlusInterceptor interceptor new MybatisPlusInterceptor(); interceptor.addInnerInterceptor(new PaginationInnerInterceptor(DbType.MYSQL)); return interceptor; } }这个错误特别隐蔽因为接口不会报红数据还能正常返回排查起来容易走弯路。你在网上搜 mybatis-plus selectPage 不生效绝大多数情况都是这个原因。另一个相关坑是分页插件要放在拦截器链的第一个位置如果项目里同时配置了其他拦截器顺序不对会导致分页失效。6.4 Nginx 反向代理与前端路由 history 模式前端构建后是静态文件部署到 Nginx。接口请求 /api 反向代理到后端 8080 端口。前端如果开启 history 路由Nginx 必须配置 try_files否则用户直接在浏览器里访问 /exam/3 这种深层链接Nginx 会返回 404。我的配置片段如下server { listen 80; server_name your_domain_or_ip; location / { root /usr/share/nginx/html; index index.html; try_files $uri $uri/ /index.html; } location /api/ { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } }注意 proxy_pass 的路径拼接规则。location /api/ 加上 proxy_pass http://127.0.0.1:8080末尾不带斜杠请求 /api/exam/list 会转发到后端 /api/exam/list如果 proxy_pass 末尾写成 http://127.0.0.1:8080/则会变成 /exam/list。这个小细节坑过很多人联调时接口一直 404 先检查这里。6.5 服务器部署的常规流程常规流程就这几步打包后端 jarmvn clean package -DskipTests、打包前端npm run build、拷贝 dist 到 Nginx 目录、启动 jar、做 Nginx 反向代理。Linux 服务器上跑 jar 用 nohup java -jar xxx.jar log.txt 21 用 logs 来排查启动错误。如果遇到 MySQL 无法远程连接先看 MySQL 的 bind-address 配置和用户 host 是不是 localhost8.0 版本下可以用 SQL 创建远程用户并赋予权限。同时注意云服务器安全组要放行 3306 端口但安全考虑不建议把 MySQL 端口直接对外暴露最好只允许服务器本机访问后端应用和数据库部署在同一台机器上就行了。还有一点后端 jar 包启动时会实时打印日志如果忘记重定向输出文件ssh 断开之后进程有可能被系统回收。有的发行版即使有 nohup 也可能会中断更保险的做法是用 systemd 写一个 service 文件管理进程启动、停止、自动重启都方便。对于课设项目nohup 够用但想学正规部署流程的话建议直接上 systemd 配置。7. 这套系统的后续演进空间7.1 从固定试卷到随机组卷与题库管理现在这个系统的试卷是提前固定好的教师手动往一张试卷里添加题目。改进方向是增加题库表按难度、知识点给题目打标签教师组卷时按条件随机抽题。数据库需要新增 question_type、difficulty、knowledge_point 等字段以及组卷规则表。这是一步非常大的扩展但架构上不会有太大改动因为题目表已经和试卷表解耦了加一个题库的概念不会破坏现有结构。随机组卷的业务逻辑是教师创建考试时选择题库和抽题规则后端从题库里随机选出题目同时生成一份试卷快照。注意“试卷快照”很重要考试过程中题目和答案不能变化否则判卷结果会受到题库数据变动的影响。这一块的业务复杂度比现在的固定试卷高不少却是在线考试系统的核心卖点值得深入研究。7.2 交流模块内容治理学习交流模块如果想继续演进可以考虑接入评论点赞、内容举报、管理员审核甚至简单的推荐算法。内容治理是社区的生死线如果不加审核很容易被垃圾内容淹没。我建议至少加一个“敏感词过滤”和“管理员删帖接口”。敏感词过滤最简单的实现是维护一个敏感词表发布帖子时遍历比对。商用级系统会用 DFA 算法但中小项目里一个 Trie 树或者简单的列表遍历就够了。管理员后台再加一个帖子管理页面可以查看全部帖子、下架违规内容、封禁用户这样整套平台的运营闭环才算完整。7.3 性能与安全增强性能上考虑 Redis 缓存试卷列表、考试成绩热点数据安全上考虑密码加密用 BCrypt接口做限流。另外如果并发考试人数上来要注意数据库连接池大小、前端静态资源 CDN 等。BCrypt 是 PasswordEncoder 的默认实现SpringSecurity 里直接能用即便你现在用的是自定义登录逻辑也建议把 MD5 换成 BCrypt成本极低但安全性提升明显。接口限流可以用拦截器加计数器实现每个用户每分钟最多调用多少次接口超过就返回 429。这个功能在防刷上很有用尤其学习交流模块的发帖接口容易被脚本批量灌水。真要到高并发场景再引入 Redis 和网关层限流也不迟当前项目的架构扩展空间是有的不会因为加功能就把底层推翻重建。这套系统后续还可以朝数据分析方向走比如根据考试记录自动生成学生的学习报告按知识点维度展示薄弱项那样产品价值就更高了。不过那些都是后话先把当前版本打磨扎实把每一张表、每一个接口、每一处边界条件想清楚比追新框架有意义得多。