Spring Boot + Web Service 教务管理系统毕业设计全流程实战解析

每年毕业季，计算机专业的同学都会面临同一个问题：毕业设计到底选什么题？很多同学一看到“教务管理系统”就摇头，觉得太老、太常见。但我想说的是，这个题目恰恰是最容易做出彩、也最考验工程基本功的方向之一。尤其是题目里同时出现了springboot和web service这两个关键词，项目的技术含量和答辩时的区分度一下就拉起来了。

这个系统本质上解决的是高校教务管理中的信息流转问题：学生信息、课程安排、选课、成绩录入与查询、教师授课任务……这些琐碎但高频的业务，全部需要在一个统一的平台里跑通。作为毕业设计，它既覆盖了CRUD（增删改查）的全部基础功，又要求你把前端页面、后端接口、数据库设计、权限控制这些环节串联起来，任何一个环节掉链子，系统就跑不顺。换句话说，做完这个题，你基本就把一个完整Web项目的全流程走了一遍。

这篇内容适合三类人：正在纠结选题的计算机专业学生、已经选了类似题目但不知道怎么下手的人、以及想摸清Spring Boot项目完整套路以便应付面试或实际工作的开发新手。我会从选题逻辑、技术选型、数据库设计、接口实现、踩坑记录到答辩准备，把整个项目的关键环节逐一拆开讲，尽量做到你看完就能照着做。

1. 项目整体设计与技术选型拆解

1.1 为什么这个题目值得选

先说选题。教务管理系统在毕业设计里确实属于“老面孔”，但为什么我还推荐它？因为毕业设计评分看重的从来不是题目新不新，而是你在系统实现里体现出多少工程能力。教务系统天生就是一套完整的业务闭环：有用户角色（管理员、教师、学生），有权限划分，有复杂业务（选课、排课、成绩统计），有数据关联（学生-班级-课程-成绩）。这套业务模型的复杂度刚刚好，既比图书管理、订餐系统更有层次，又不像大型电商系统那样超出本科生的能力范围。

更重要的是，加上“基于web service技术”这个限定以后，题目就从“又一个管理系统”变成了“有技术侧重点的系统”。答辩时老师很可能会追问：你的接口是怎么设计的？前后端数据是怎么交互的？请求和响应遵循什么规范？这些问题的答案，恰恰是区分一篇论文是否扎实的关键。很多人毕业设计做完了，接口就是随手写几个Servlet或者Controller，根本没有“服务”的概念，答辩一被追问就露馅。

1.2 技术栈选型的深层逻辑

这个题目最核心的技术点是springboot。为什么不用传统的SSM（Spring + SpringMVC + MyBatis）？不是不能用，而是Spring Boot在毕业设计里有三个压倒性的优势：

第一，起步成本低。Spring Boot通过自动配置把大量原本需要手写的XML配置全部省掉了。一个类加一个注解就能跑起Web应用，这对时间紧张的毕业生来说太重要了。你省下配置的时间，可以花在打磨业务逻辑和写论文上。

第二，生态成熟，资料多。社区里关于Spring Boot的教程、示例、踩坑记录遍地都是，遇到问题基本都能搜到答案。毕业设计阶段最怕的就是遇到一个冷门问题卡一周，Spring Boot能最大程度降低这种风险。

第三，面试认可度高。Spring Boot是目前企业级Java开发的事实标准。做完这个项目，你写进简历里的相关内容是真实可用的，面试官问起Spring Boot相关问题你也能有实际项目经验支撑，而不是背题。

再说web service这个关键词。这里要多说一句：很多同学一看到“web service”就以为必须用SOAP + WSDL那一套老掉牙的东西。其实在现在的工程实践中，web service这个概念早就泛化了，RESTful API就是最主流的一种web service实现方式。从毕业设计的角度，我建议在论文里这样处理：明确说明系统采用基于RESTful风格的Web Service技术，所有的业务能力以HTTP接口的形式对外提供服务，遵循无状态、统一资源定位、标准HTTP方法等设计原则。这样既扣住了题目的“web service技术”关键词，又符合当下工程实践的主流做法。当然，如果学校要求必须体现SOAP，你也可以在部分接口中用Spring Web Services集成一个SOAP服务作为补充，但主交互方式建议还是RESTful，原因很简单：够用、好写、好讲。

1.3 系统整体架构划分

教务管理系统的架构，我建议按“前后端分离 + 三层架构”的经典模式来做，这也是最不容易出错、最好讲清楚的方案。

前端单独用一个项目承载，技术上可以用Vue + Element UI（最主流）或者单纯的Bootstrap + Thymeleaf模板。如果你对前端不熟悉，我建议直接用Bootstrap + Thymeleaf，服务端渲染页面，Spring Boot直接返回视图；如果你对Vue有点基础，前后端分离会更出彩，但也意味着多一个项目、多一层联调工作。我的建议是：如果离答辩还有两个月以上，冲一下Vue前后端分离；如果时间紧张，别折腾，服务端渲染稳扎稳打也能拿高分。

后端用Spring Boot + MyBatis Plus + MySQL这条黄金组合。MyBatis Plus对比原生MyBatis，最大的价值是提供了单表CRUD的通用方法，你在写学生管理、课程管理这些基础模块时，几乎不用手写SQL，能省大量的重复劳动。数据库用MySQL，这个没啥好纠结的，教务系统这种规模用MySQL绰绰有余，出问题的概率最低。

整体分层上，严格按Controller-Service-Mapper三层走，实体类单独放entity包，DTO和VO根据情况使用。这里有个细节很多人不注意：Controller只做参数接收和结果封装，不能写业务逻辑；Service层处理业务规则；Mapper层只做数据访问。按照这个铁律来，你的代码结构就是干净的，答辩和论文里也更好写。

2. 核心功能模块与数据库设计

2.1 教务业务的核心流程梳理

先梳理业务。一个完整的教务管理系统，站在使用者角度可以拆成三类角色、四类核心业务。

三类角色是：管理员、教师、学生。管理员管全局，负责维护基础数据；教师管教学，负责录入成绩、查看授课任务；学生管学习，负责选课、查成绩、看课表。这三类角色的权限边界必须从一开始就划清楚，否则后面做权限控制的时候会非常痛苦。

四类核心业务分别是：

• 基础信息管理：学生信息、教师信息、班级信息、课程信息的增删改查
• 开课与选课管理：管理员发布开课计划，学生在规定时间内完成选课
• 成绩管理：教师录入成绩、学生查询成绩、管理员做成绩审核与统计
• 统计分析：按课程、按班级、按年级统计成绩分布、及格率等

这四类业务的流程是有先后依赖的：先有班级和教师，才能有开课计划；有了开课计划，学生才能选课；学生选完课，教师才能录入成绩。这个依赖关系直接决定了数据库表之间的外键关系设计，也决定了页面的操作顺序。

2.2 数据库表设计与关系建模

教务系统数据库设计是整个项目的基石。我见过太多人上来就写代码，写到关联查询的时候发现表结构不对，又回头改表，导致代码和数据库反复打架。先花两天把表设计好，后面会省掉至少一周的返工时间。

核心表我建议这样设计：

这里有一个关键设计点需要重点说：学生和课程是多对多关系，必须通过选课表（course_select）这个中间表来解耦。而且选课表上的成绩字段是放在中间表里，而不是放在课程表里——因为不同学生选修同一门课的成绩各不相同，成绩必须关联到“某个学生选某门课”这个事实上去。

表之间关系可以用一句话概述：学生属于班级，教师开设课程，学生通过选课表与开课记录产生关联，成绩挂在选课记录上。数据模型对了，后面的所有查询都顺。

设计表的时候还要注意三点。第一，主键统一用自增ID或雪花ID，不要用学号、工号这类业务字段做主键，因为业务字段有被修改的可能。第二，每张表都要加create_time和update_time两个字段，做数据追踪和排序都方便。第三，状态字段用tinyint，比如用户状态0表示禁用、1表示启用，不要用字符串，省空间又好查。

2.3 接口设计规范：把Web Service落到实处

接口设计是体现“基于web service技术”这个题眼的核心环节，一定不能随便写。我建议全系统统一遵循RESTful风格，并制定一套响应规范，让所有的接口返回格式完全一致。

统一响应格式长这样：

json复制{
  "code": 200,
  "message": "success",
  "data": { }
}

code是业务状态码，200代表成功，401代表未认证，403代表无权限，500代表服务器异常。data是真正的业务数据，成功时返回查询结果或操作结果，失败时返回null。前端拿到响应后先判断code，再决定渲染逻辑，这样前端只需要写一套统一的数据处理逻辑，不需要为每个接口单独判断。

接口路径的设计上，遵循资源命名规则：复数名词 + 标准HTTP方法。比如：

• GET /api/students 查询学生列表
• POST /api/students 新增学生
• PUT /api/students/{id} 修改学生信息
• DELETE /api/students/{id} 删除学生
• POST /api/login 登录（非资源型操作用动词）
• GET /api/courses/{courseId}/students 查询选修某门课的学生列表

这种设计的好处是接口自解释，你看路径就知道这个接口是干嘛的，老师一眼就能看出你的接口设计是有章法的。

权限设计上，我建议用JWT（JSON Web Token）做无状态认证，结合Spring Boot的拦截器（HandlerInterceptor）做统一鉴权。登录成功后服务端签发一个token，前端在请求头里带上Authorization: Bearer ，拦截器解析token并判断角色权限。这样做的好处是接口无状态，集群部署也无障碍，而且token过期策略好控制。如果你觉得JWT学习成本高，退一步用session + 拦截器也行，但论文里就要多写一段session机制的说明，答辩时也容易被追问集群场景下的session共享问题。相比之下，JWT是更省心的选择。

3. 实操过程与核心环节实现

3.1 项目初始化与基础环境搭建

环境准备方面：JDK建议用1.8或11，Spring Boot版本建议用2.x（比如2.7.x）。这里有个重要的避坑建议：不要一上来就追最新的Spring Boot 3.x，因为3.x基于Jakarta EE规范，很多老教程和依赖的导入路径变了，你照网上的教程抄容易踩版本不兼容的坑。毕业设计求的是稳，选一个资料最多、社区最成熟的版本，比选最新版本靠谱得多。

初始化项目直接用Spring Initializr（start.spring.io）就可以。需要的核心依赖有：

• spring-boot-starter-web：Web应用基础
• mybatis-plus-boot-starter：MyBatis Plus（注意版本要匹配Spring Boot版本）
• mysql-connector-java：MySQL驱动
• spring-boot-starter-validation：参数校验
• jjwt（或java-jwt）：JWT的工具库
• lombok：简化实体类代码

有一个版本匹配的细节必须讲：MyBatis Plus和Spring Boot之间的版本没有强绑定，但MyBatis Plus 3.5.x版本之后分成了针对Spring Boot 2和Spring Boot 3的两个starter路径（mybatis-plus-boot-starter 和 mybatis-plus-spring-boot3-starter）。你如果用Spring Boot 2.x，就用mybatis-plus-boot-starter；用Spring Boot 3.x，就必须改用mybatis-plus-spring-boot3-starter，千万别搞混。

application.yml配置文件的写法如下：

yaml复制server:
  port: 8080

spring:
  datasource:
    driver-class-name: com.mysql.cj.jdbc.Driver
    url: jdbc:mysql://localhost:3306/edu_admin?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai
    username: root
    password: 123456
  jackson:
    date-format: yyyy-MM-dd HH:mm:ss
    time-zone: Asia/Shanghai

mybatis-plus:
  configuration:
    log-impl: org.apache.ibatis.logging.stdout.StdOutImpl
  global-config:
    db-config:
      logic-delete-field: deleted
      logic-delete-value: 1
      logic-not-delete-value: 0

jwt:
  secret: your-secret-key
  expire: 7200000

这里有几个极易踩的坑，我一并说了。第一，数据库连接URL里的serverTimezone必须设置，否则会报时区异常。第二，characterEncoding=utf8一定要加，不然中文数据在库里就是一堆问号。第三，MyBatis Plus的logic-delete配置是逻辑删除的开关，教务系统的数据有连续性，不要物理删除学生或课程，用逻辑删除是更好的选择。

3.2 登录认证与角色权限实现

登录是系统的门面，也是权限控制的起点。我直接给一套完整可用的实现思路。

登录接口的流程是这样的：用户提交用户名和密码，Controller收到后交给Service处理，Service里通过MyBatis Plus的LambdaQueryWrapper查询用户表，用BCrypt去校验密码，校验通过后通过JWT工具类生成token，返回给前端。关键代码大致如下：

java复制@Override
public LoginVO login(LoginDTO dto) {
    SysUser user = userMapper.selectOne(
        new LambdaQueryWrapper<SysUser>()
            .eq(SysUser::getUsername, dto.getUsername()));
    if (user == null || !BCrypt.checkpw(dto.getPassword(), user.getPassword())) {
        throw new BusinessException("用户名或密码错误");
    }
    if (user.getStatus() == 0) {
        throw new BusinessException("账号已被禁用");
    }
    String token = jwtUtil.createToken(user.getId(), user.getRole());
    return new LoginVO(token, user.getRole());
}

这里的要点有两个。一是密码存储绝不能用明文，BCrypt是Spring Security自带的加密工具，单独引入spring-security-crypto依赖就能用，不需要引入整个Spring Security。二是登录接口本身必须在拦截器白名单里，否则就出现了“还没登录就无法访问登录接口”的死循环。

拦截器的写法要做三件事：从请求头里拿token，解析token判断是否有效，然后判断当前用户的角色是否允许访问当前接口。以管理员接口为例，可以在你的应用里写一个AdminInterceptor，专门拦截 /api/admin/** 路径，登录拦截器负责拦截 /api/** 下的其他所有请求。两个拦截器按顺序注册，先做登录校验再做权限校验，逻辑清晰也好讲解。

3.3 核心业务场景实操：选课并发与成绩录入

选课是教务系统里最有业务含金量的功能，因为涉及并发和数据一致性。稍微有经验的老师都会追问：如果100个学生同时选一门只剩5个名额的课，你的系统怎么保证不会超选？

这个问题在答辩时几乎必问，你的代码里一定要有对应的处理。最简单的方案是利用数据库的行锁机制，结合select ... for update来控制选课记录数。伪代码逻辑如下：

java复制@Transactional
public void selectCourse(Long studentId, Long openCourseId) {
    // 先锁住开课记录，防止并发超选
    CourseOpen openCourse = courseOpenMapper.selectByIdForUpdate(openCourseId);
    // 统计已选人数
    Long selectedCount = courseSelectMapper.selectCount(
        new LambdaQueryWrapper<CourseSelect>()
            .eq(CourseSelect::getOpenCourseId, openCourseId));
    if (selectedCount >= openCourse.getCapacity()) {
        throw new BusinessException("该课程选课人数已满");
    }
    // 判断是否重复选课
    Long exist = courseSelectMapper.selectCount(
        new LambdaQueryWrapper<CourseSelect>()
            .eq(CourseSelect::getStudentId, studentId)
            .eq(CourseSelect::getOpenCourseId, openCourseId));
    if (exist > 0) {
        throw new BusinessException("你已选修过该课程");
    }
    // 插入选课记录
    courseSelectMapper.insert(new CourseSelect(studentId, openCourseId));
}

selectByIdForUpdate这个方法是Mapper层的一个自定义查询，加上@Select注解写SQL即可：

java复制@Mapper
public interface CourseOpenMapper extends BaseMapper<CourseOpen> {
    @Select("SELECT * FROM course_open WHERE id = #{id} FOR UPDATE")
    CourseOpen selectByIdForUpdate(Long id);
}

这里必须注意三点。第一，@Transactional事务不能少，选课判断和插入必须在一个事务里，否则并发场景下会出问题。第二，selectByIdForUpdate使用行锁，锁住这一行之后其他事务对同一行的选课操作会排队等待，这样就避免了超选的竞态条件。第三，业务上还要加一个唯一索引来兜底，给course_select表加一个(student_id, open_course_id)的联合唯一索引，就算代码层面有bug导致重复插入，数据库层面也会拦住。

成绩录入模块相对简单些，教师按课程筛选选课学生列表，逐个录入平时成绩和期末成绩，系统自动计算总评。这里要注意的就是成绩字段的精度校验：用decimal(5,2)保留两位小数，并在后端用@DecimalMin和@DecimalMax注解限制成绩范围在0到100之间，防止异常数据进入系统。

成绩统计这块可以做一个分组查询，按课程统计选课人数、平均分、最高分、最低分、及格率。用MyBatis Plus的QueryWrapper配合groupBy和select方法就能实现，SQL层面类似于：

sql复制SELECT course_id, COUNT(*) AS total, AVG(total_score) AS avg_score,
       MAX(total_score) AS max_score, MIN(total_score) AS min_score
FROM course_select
WHERE course_id = ?
GROUP BY course_id

统计类的接口建议单独建一个StatisticsController，把相关的统计查询集中在里面，答辩时演示效果也更有冲击力。

3.4 前端页面与联调实操

前端这块，我分两种情况说。

如果你用Thymeleaf服务端渲染，那么页面放在src/main/resources/templates目录下，静态资源放在static目录下，Controller里直接返回视图名称。这种模式比较直观，不需要处理跨域，适合时间紧的同学。页面结构建议用adminlte这类免费后台模板，或者Bootstrap + 手写CSS，登录页和主页面分开，主页面用iframe嵌套各功能子页面。

如果你用Vue前后端分离，本地开发时前端在8081端口跑，后端在8080端口跑，必然遇到跨域问题。解决方式是在后端配置CORS，最省事的写法是加一个配置类：

java复制@Configuration
public class CorsConfig implements WebMvcConfigurer {
    @Override
    public void addCorsMappings(CorsRegistry registry) {
        registry.addMapping("/**")
                .allowedOriginPatterns("*")
                .allowedMethods("GET", "POST", "PUT", "DELETE", "OPTIONS")
                .allowedHeaders("*")
                .allowCredentials(true)
                .maxAge(3600);
    }
}

配置完CORS后还有个隐藏问题：预检请求OPTIONS会被拦截器拦住。所以你的登录拦截器对于OPTIONS请求要直接放行，否则前端会莫名其妙报跨域错误。这个坑我见过太多人踩了，提前写好能省很多联调时间。

另外，前端请求时统一封装一个http工具，自动在请求头里添加token。响应拦截器里判断code，如果code是401就跳转登录页。这套逻辑和上面的统一响应格式是配套的，代码量不大，但会让整个联调过程非常顺滑。

4. 常见问题与排查技巧实录

4.1 版本兼容性踩坑清单

先说版本。Spring Boot版本太高是很多人会遇到的问题。Spring Boot 3.x技术上来讲和2.x有不少差异，在校园的毕业设计环境下，网上大量现成教程是基于2.x的，当你搜到一段代码想抄的时候，如果是针对2.x的源码，放到3.x的项目里很可能直接编译报错。这不是你的问题，是版本差异导致。我个人的建议是Spring Boot选2.7.x，JDK选1.8或11，这个组合最稳。

另外常见的是数据库驱动类名问题。旧教程里写的是com.mysql.jdbc.Driver，新版MySQL驱动类名变成了com.mysql.cj.jdbc.Driver，用错的话启动会直接报加载驱动失败。虽然新版驱动可以自动识别，但配置文件里写错旧类名还是会报错。

Lombok也是一个容易出问题的点。IDEA里光加依赖还不够，必须安装Lombok插件，否则@Getter、@Setter这些注解完全不生效，代码一编译就报“找不到符号”。这个属于IDE配置问题，排查起来很容易卡住，提前确认可以少浪费半小时。

4.2 联调阶段的常见报错排查

联调阶段最常见的报错就是404和跨域。

404分两种。一种是后端接口路径写错了，前端访问/api/students路径，后端Controller的@RequestMapping写的却是/student，少了一个s，结果就404。这类问题建议直接用curl或者Postman测后端接口，后端口径没问题再查前端。另一种是服务端渲染时视图找不对，这个多半是templates目录路径或返回值名称写错，对照目录结构逐层检查一遍就能定位。

跨域报错的信息长这样：No 'Access-Control-Allow-Origin' header is present on the requested resource。看到这行字，第一反应查后端有没有配置CORS，第二反应查拦截器是否放行了OPTIONS预检请求。这两步排查完，90%的跨域问题都能解决。

还有一个中文乱码问题也高频发生。乱码的根源基本逃不出三层：数据库连接URL没加characterEncoding=utf8、数据库表和字段本身的字符集不是utf8mb4、前端页面没有声明UTF-8编码。从上往下一层层查，基本能定位到具体哪一层出了问题。创建数据库时直接指定字符集最省事：

sql复制CREATE DATABASE edu_admin DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;

4.3 业务逻辑层的隐蔽Bug

有些Bug不报错，但运行结果就是不对，这类问题最让人头疼。我分享两个典型的。

第一个是ID类型导致的精度丢失。如果你的后端用了雪花ID或长整型（Long）作为主键，返回给前端的JSON里如果ID超过JavaScript的安全整数范围（Number.MAX_SAFE_INTEGER），前端拿到后精度会丢，导致编辑、删除时传回后端的ID变了。解决办法是在实体类的ID字段上加@JsonSerialize(using = ToStringSerializer.class)，让ID以字符串形式返回给前端，前端不要做任何数值运算，原样传回。

第二个是删除数据时外键约束报错。比如你要删除一个班级，但该班级下还有学生，数据库会拒绝删除并报外键约束错误。这时候不能硬删，先处理关联数据，要么把下面的学生转到其他班级，要么逻辑删除这个班级。这也是为什么我之前建议用逻辑删除的其中一个重要原因，业务上更灵活，也不会触碰到外键约束。

5. 答辩准备与避坑指南

5.1 演示Demo要提前打磨的三个细节

答辩现场的演示环节，决定了老师对你项目的直观印象。我有三个建议。

第一，准备一份干净的演示数据。控制的学生人数不要太多也不要太少，比如每个班级30人左右，课程5到8门，数据之间要真实相关。千万不要用测试时随便造的数据去演示，名字、成绩、课程名都对不上号，老师一看就觉得项目是临时拼凑的。

第二，演示流程要按故事线走，而不是菜单式点开。先演示教师登录录成绩，再切学生登录查成绩、选课，最后用管理员账号看统计数据。让老师看到的是业务闭环，而不是一堆功能按钮的堆砌。你演示的时候嘴里同步讲业务逻辑，比如“学生选课后，教师端才能看到这个学生进行成绩录入”，这种表达非常加分。

第三，提前踩一遍所有演示操作，确认没有空指针、没有404、没有登录过期。答辩现场网络状况、电脑环境都不可控，能提前把服务启动好、数据库准备好，就绝不在现场等启动。

5.2 高频答辩问题与应对思路

老师最容易问的几个问题，我列一下，你可以照着准备：

• 为什么选Spring Boot？回答思路：自动配置简化开发、生态成熟、内嵌Tomcat免部署、符合企业主流技术栈。
• Web Service在你的系统里怎么体现的？回答思路：讲RESTful风格接口、统一响应格式、HTTP方法语义、无状态JWT认证，这四点就把“web service技术”落实到位了。
• 选课并发怎么处理？回答思路：事务 + 行锁 + 唯一索引三层保障，把代码逻辑讲清楚。
• 密码安全怎么做的？回答思路：BCrypt加盐哈希，不是明文存储，登录时校验哈希值。
• MyBatis Plus和MyBatis有什么区别？回答思路：MyBatis Plus在MyBatis基础上提供了通用CRUD、条件构造器、分页插件等增强功能，单表操作不用手写SQL。

准备这些回答时，不要背答案，而是对着自己的代码讲。老师问深一点的时候，你翻到代码页面指给他看，比背任何答案都有效果。

5.3 论文写作的几个建议

论文这里简单说两句。架构图一定要自己画，分前端、Controller层、Service层、Mapper层、数据库五层，每层标注职责和技术要点。核心功能的时序图选课和登录各画一张。图表在论文里的权重大到超出很多人的想象，同样的项目，图做得规范，评分能高一个档次。

论文里的技术描述要密密扣住题目关键词。Spring Boot、Web Service、RESTful、JWT、MyBatis Plus这些术语要分散出现在技术选型、系统设计、系统实现各章里，形成一条贯穿全文的技术主线。导师看论文最讨厌的就是系统设计讲技术，到了实现章节技术描述突然消失，代码和前面设计对不上。

最后说点个人体会。我带过的学生里，做教务管理系统的不在少数，最后拿高分的，往往不是功能做最多的，而是技术逻辑最自洽的。一个系统，功能再多，如果老师一追问就问倒你，分数一定不高；反过来，功能扎实、接口规范、关键技术点讲得清楚，哪怕少一两个附属功能，也是优秀项目。这篇内容里讲的每个环节，都是我反复被问、反复踩坑后总结出来的，你照着一步步做，稳扎稳打，毕业设计不会差。

另外再分享一个小技巧：开发过程中养成随时截图的习惯。数据库表设计、接口调试结果、页面效果、并发测试记录，这些截图后面写论文、做答辩PPT的时候全是素材。很多学生到写论文时才追悔莫及，发现前期忘了留档。现在看到这篇内容的你，正好来得及。