Spring Boot+MySQL员工信息管理系统：从数据库设计到部署避坑全指南

由于员工信息管理系统是计算机类毕业设计中出现频率最高的一类选题，很多同学拿到题目之后第一反应是“功能太简单、没啥可写”，但真正动手之后才发现处处是坑：框架版本不兼容、Mapper扫描不到、JSON序列化死循环、部署到服务器之后数据库连不上……我今年刚带完几个做这个题目的同学，前后花了大概三周帮他们梳理完整套流程，这里把整个项目的搭建思路、核心代码、数据库设计以及最容易踩的坑一次性说清楚。

先说结论：Spring Boot + MySQL 做员工管理系统，技术栈选得没问题，但如果你能在这个基础上把细节做扎实（比如权限控制、日志记录、分页查询异常处理），答辩的时候老师基本挑不出大问题。这篇文章不会只给你贴代码，我会把每一步为什么这么做的原因也讲清楚，方便你写到论文的“需求分析”和“系统设计”章节里，同时也会把我在实际指导过程中遇到过的高频报错整理成排查清单，希望能帮正在赶工的你少走点弯路。

1. 项目整体设计与技术选型思路

1.1 为什么只有Spring Boot还不够

很多同学拿到“基于Java Spring Boot MySQL的员工信息管理系统”这个题目，第一反应是直接用Spring Boot写个增删改查就完了。但实际情况是，毕业设计答辩时老师一定会问：你这个系统怎么保证安全性？多用户同时访问数据库会不会出问题？为什么用MyBatis而不是直接用JDBC？

所以我在指导时一般建议给系统加两个最基本的模块，一是登录认证与权限控制（至少区分管理员和普通员工），二是统一异常处理与日志记录。这套组合在本科毕设里属于“安全边际很高”的方案——功能完整度足够，代码量可控，每个模块也都有得写。

技术选型方面，我建议的搭配是：

• 后端框架：Spring Boot 2.7.x（不要一上来追新版本，后面讲原因）
• ORM框架：MyBatis Plus 3.5.x（比纯MyBatis省掉大量XML配置）
• 数据库：MySQL 5.7或8.0都能用，但驱动和连接串写法有区别
• 前端：Thymeleaf模板引擎 + Bootstrap（能少写大量JS代码，适合赶工）
• 权限控制：Spring Security或者自定义拦截器，二选一即可

抛开技术栈，你在论文里一定要写清楚这个系统面对的用户角色和使用场景。员工信息管理系统通常有两类用户：管理员和普通员工。管理员负责维护整个公司的员工档案，包括新增入职员工、编辑资料、调整部门、删除离职员工等操作；普通员工只能查看个人信息、修改部分字段，甚至只能看不能改。这种设定意味着你的数据库设计从一开始就要考虑权限问题，而不是等到写代码的时候才补。

1.2 功能模块划分与工作量预估

我在给同学规划任务时，一般把系统拆成以下模块：

• 用户登录与注销（验证用户名密码、Session保存登录态）
• 员工信息管理（增删改查，查询支持姓名、部门、入职时间等条件组合）
• 部门信息管理（用于员工表关联查询，同时减轻数据冗余）
• 个人信息查看与修改（普通员工登录后的权限范围）
• 操作日志记录（谁在什么时间操作了哪条数据，答辩加分项）
• 数据统计（各部门人数统计，用图表展示，可选）

我遇到过不少同学一开始想把功能设计得很丰富，什么考勤、薪资、请假审批全都塞进去，结果写到一半发现数据库表关系越来越复杂，代码Bug越改越多，最后临近提交才草草收尾。如果你的目标是“顺利通过答辩并能讲清楚自己的代码”，上面这六个模块就是比较合适的体量。再多的功能不是不行，而是你要考虑自己是否有足够的时间去调试。

1.3 目录结构与包命名规范

包结构这块，我要求同学统一按照Controller -> Service -> Mapper -> Entity 四层结构分包，不要图省事把什么都写在Controller里。这里给你一个可以直接照搬的包结构：

com.example.employee ├── controller // 接收前端请求，返回页面或JSON数据 ├── service // 业务逻辑层，处理具体业务规则 │ └── impl // 业务逻辑实现类 ├── mapper // 数据访问层，定义数据库操作方法 ├── entity // 实体类，对应数据库表结构 ├── config // 配置类（拦截器、跨域等） ├── common // 通用返回结果、异常处理类 ├── interceptor // 登录拦截器 └── EmployeeApplication.java // 启动类

为什么一定要这样拆？有三个原因：第一，答辩时候老师问你项目分层了没有，你直接指着项目结构就能讲清楚；第二，Spring容器帮你管理Bean的前提是类上标注明确，分包混淆会导致扫描不到Mapper或者Service；第三，后面排查Bug时，你能很快定位问题是出在数据层、业务层还是控制层。

2. 数据库设计与建表实操

2.1 表结构设计背后的核心思路

员工信息管理系统虽然名字叫“员工信息”，但实际开发时最少也要三张表：员工表、部门表、用户表。如果只建一张员工表然后所有信息全都堆进去，数据库设计这关就过不了。

员工表（employee）是核心表，需要存储姓名、性别、手机号、邮箱、入职日期、部门ID、岗位、薪资状态等字段。这里有个关键设计决策：部门ID是以外键关联的方式存在员工表里，还是直接存部门名称字符串？我在一开始就定了方案：存部门ID，然后通过SQL联表查询查出部门名称。

这样做的好处非常明显。假如有一天部门改名了，员工表里存的是“技术一部”，你就要写一个批量更新的SQL把所有员工的部门字段都改一遍；如果存的是部门ID，只需要修改部门表里那一条记录，员工表不用动。另外，存ID也方便后面按部门统计人数时直接用group by操作。

2.2 核心建表SQL参考

下面是我给同学整理过的一套可以直接执行的建表SQL，注释信息也符合毕设论文里“数据库设计”章节的截图要求：

-- 部门表 CREATE TABLE `department` ( `id` int NOT NULL AUTO_INCREMENT COMMENT '部门ID', `name` varchar(50) NOT NULL COMMENT '部门名称', `location` varchar(100) DEFAULT NULL COMMENT '办公地点', `created_time` datetime DEFAULT NULL COMMENT '创建时间', PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='部门信息表'; -- 员工表 CREATE TABLE `employee` ( `id` int NOT NULL AUTO_INCREMENT COMMENT '员工ID', `emp_no` varchar(20) NOT NULL COMMENT '工号', `name` varchar(50) NOT NULL COMMENT '姓名', `gender` tinyint DEFAULT NULL COMMENT '性别 0未知 1男 2女', `phone` varchar(20) DEFAULT NULL COMMENT '手机号', `email` varchar(100) DEFAULT NULL COMMENT '邮箱', `department_id` int DEFAULT NULL COMMENT '部门ID', `position` varchar(50) DEFAULT NULL COMMENT '岗位', `entry_date` date DEFAULT NULL COMMENT '入职日期', `status` tinyint DEFAULT '1' COMMENT '在职状态 1在职 0离职', `created_time` datetime DEFAULT NULL COMMENT '创建时间', `updated_time` datetime DEFAULT NULL COMMENT '更新时间', PRIMARY KEY (`id`), KEY `idx_department_id` (`department_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='员工信息表'; -- 用户表（用于登录认证） CREATE TABLE `sys_user` ( `id` int NOT NULL AUTO_INCREMENT COMMENT '用户ID', `username` varchar(50) NOT NULL COMMENT '登录用户名', `password` varchar(100) NOT NULL COMMENT '密码(BCrypt加密)', `role` varchar(20) DEFAULT 'EMPLOYEE' COMMENT '角色 ADMIN/EMPLOYEE', `employee_id` int DEFAULT NULL COMMENT '关联员工ID', `status` tinyint DEFAULT '1' COMMENT '账号状态', PRIMARY KEY (`id`), UNIQUE KEY `uk_username` (`username`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='系统用户表';

建表的时候要注意两个细节。第一个是字符集，直接指定utf8mb4而不是utf8，因为utf8在MySQL里最多只能存3字节，遇到生僻字或者特殊符号会报错。第二个是工号emp_no建议加唯一索引，因为工号是员工在公司的唯一标识，如果重号会导致后续数据混乱，我在实际操作里吃过这个亏，后面在问题排查部分会详细讲。

2.3 数据库连接配置与驱动版本选择

配置application.yml的时候，我见过太多同学在这里栽跟头。Spring Boot 2.7.x默认使用JDBC驱动是com.mysql.cj.jdbc.Driver，而旧教程里常见的com.mysql.jdbc.Driver在MySQL 8.0的驱动包中已经标记为过时，虽然还能跑但会一直输出警告日志。

推荐直接使用下面的配置：

spring: datasource: url: jdbc:mysql://localhost:3306/employee_db?useUnicode=true&characterEncoding=utf8&useSSL=false&serverTimezone=Asia/Shanghai&allowPublicKeyRetrieval=true username: root password: 你的数据库密码 driver-class-name: com.mysql.cj.jdbc.Driver mybatis-plus: mapper-locations: classpath:mapper/*.xml type-aliases-package: com.example.employee.entity configuration: map-underscore-to-camel-case: true log-impl: org.apache.ibatis.logging.stdout.StdOutImpl

这里重点讲一下serverTimezone=Asia/Shanghai这一项。MySQL 5.7版本默认时区不是UTC，但8.0版本安装时如果选的是系统默认时区，Java连接时会出现“The server time zone value”的异常。加上serverTimezone参数可以统一时区，避免数据库时间和程序时间相差8小时。另外allowPublicKeyRetrieval=true是MySQL 8.0在非SSL连接下经常需要加的参数，有时候漏掉这个会报Public Key Retrieval is not allowed权限错误。

3. 后端核心功能实现与踩坑记录

3.1 项目骨架搭建与依赖配置

创建一个Spring Boot项目，我建议直接使用Spring Initializr或者IDE自带的创建向导，手动在pom.xml里加依赖也完全没毛病，但要注意版本匹配。

核心依赖如下：

<dependencies> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-thymeleaf</artifactId> </dependency> <dependency> <groupId>com.baomidou</groupId> <artifactId>mybatis-plus-boot-starter</artifactId> <version>3.5.3.1</version> </dependency> <dependency> <groupId>mysql</groupId> <artifactId>mysql-connector-java</artifactId> <scope>runtime</scope> </dependency> <dependency> <groupId>org.projectlombok</groupId> <artifactId>lombok</artifactId> <optional>true</optional> </dependency> </dependencies>

我在指导同学做项目时，发现很多初次接触Spring Boot的人会忽略一个关键点：spring-boot-starter-parent父工程版本。用IDEA创建项目时如果没有指定Spring Boot版本，默认可能会生成3.x的最新版本，而网上能找到的教程大部分是2.x。Spring Boot 3.x要求JDK 17以上，且javax.servlet包名改成了jakarta.servlet，很多旧代码直接迁移会报“找不到符号”错误。如果你的电脑装的是JDK 8，建议创建项目时直接选择Spring Boot 2.7.16或相近的2.7.x版本，否则连编译器这关都过不了。

3.2 员工信息增删改查的实现要点

员工信息CRUD是整个系统最核心的业务，很多同学会以为只是简单的调用MyBatis Plus自带的insert、selectById、updateById、deleteById方法，但在真实场景里需要考虑更多的边界情况。

以新增员工为例，业务逻辑至少包含：先校验工号是否重复，再确认部门ID是否真实存在，最后才执行插入操作。直接用employeeService.save(employee)确实能插入数据，但如果工号重复，数据库就会爆出唯一索引冲突异常，最终返回给前端的是默认的错误页面。

我更推荐在Service层写一个明确的保存方法，示例代码：

@Service public class EmployeeServiceImpl implements EmployeeService { @Override public Result saveEmployee(Employee employee) { LambdaQueryWrapper<Employee> queryWrapper = Wrappers.lambdaQuery(); queryWrapper.eq(Employee::getEmpNo, employee.getEmpNo()); long count = this.count(queryWrapper); if (count > 0) { return Result.error("工号已存在，请检查后重试"); } employee.setCreatedTime(LocalDateTime.now()); this.save(employee); return Result.success("新增成功"); } }

这种做法的好处是逻辑一目了然，答辩时老师问“新增员工时怎么防止重复数据”，你可以直接指着这段代码解释。另外，删除员工时不要用物理删除（deleteById），而是更新状态字段把status置为0，也就是逻辑删除。员工离职了档案还需要保留，哪天需要查历史记录时，逻辑删除的数据还能查出来。这点在你写论文时也可以当作系统设计的一个亮点来写。

3.3 分页查询最容易忽略的条件封装

员工管理系统里的员工列表通常不是一次性加载全部数据的，数据量不大时可以全查，但几十条以上就会出现页面打开变慢、浏览器渲染卡顿的问题。分页查询是必做的一个功能。

MyBatis Plus提供了内置分页插件，需要在配置类里注册，否则调用分页方法不生效：

@Configuration public class MybatisPlusConfig { @Bean public MybatisPlusInterceptor mybatisPlusInterceptor() { MybatisPlusInterceptor interceptor = new MybatisPlusInterceptor(); PaginationInnerInterceptor paginationInnerInterceptor = new PaginationInnerInterceptor(DbType.MYSQL); paginationInnerInterceptor.setMaxLimit(100L); interceptor.addInnerInterceptor(paginationInnerInterceptor); return interceptor; } }

分页参数里边有几个点容易踩坑：

• current页码从1开始，前端传0的话查询结果会偏移，需要做空值校验
• size每页条数如果不限制，用户传一个100000就能把整个表全查出来，性能极其拉胯
• 条件查询（按姓名模糊匹配、按部门筛选）需要把条件封装进LambdaQueryWrapper再传给分页方法，顺序不能反

查询代码参考：

public Page<EmployeeVO> getEmployeePage(int pageNum, int pageSize, String name, Integer departmentId) { Page<Employee> page = new Page<>(pageNum, pageSize); LambdaQueryWrapper<Employee> wrapper = Wrappers.lambdaQuery(); wrapper.like(StringUtils.hasText(name), Employee::getName, name) .eq(departmentId != null, Employee::getDepartmentId, departmentId) .orderByDesc(Employee::getEntryDate); Page<Employee> employeePage = this.page(page, wrapper); // 接着把部门名称查询出来，封装成VO返回给前端 }

这段看起来简单，但藏着两个容易犯错的位置。StringUtils.hasText(name)是条件判断，如果name是null或者空串，like条件不追加；而departmentId != null则避免了eq条件把数据库里的null值字段全部过滤掉。我见过有同学没用这种条件写法，直接在拼接SQL时判断，结果要么忘记了判空导致空指针，要么条件全加进去导致查询结果为空。

3.4 登录认证与权限拦截的轻量实现

很多教程教你用Spring Security做权限控制，但配置类复杂且对新手不友好。在指导毕设的时候，我更推荐用自定义拦截器的方式实现登录认证，代码量小、逻辑清楚、答辩也好讲明白。

核心思路是：前端登录成功后把用户信息存入Session，写一个拦截器拦截所有页面请求，如果Session里没有登录用户就跳转到登录页。

登录Controller核心代码：

@PostMapping("/login") public String login(String username, String password, HttpSession session, Model model) { LambdaQueryWrapper<SysUser> wrapper = Wrappers.lambdaQuery(); wrapper.eq(SysUser::getUsername, username); SysUser user = userService.getOne(wrapper); if (user == null) { model.addAttribute("error", "用户不存在"); return "login"; } if (!BCrypt.checkpw(password, user.getPassword())) { model.addAttribute("error", "密码错误"); return "login"; } session.setAttribute("loginUser", user); return "redirect:/employee/list"; }

密码存储使用BCrypt加密而不是明文，这也是答辩加分项。明文密码一旦数据库泄露，用户的习惯性密码在其他平台也容易被撞库。Spring Security单独作为依赖引入有点重，其实spring-security-crypto这个轻量依赖里就有BCrypt工具类，不用启动整套Security过滤器链。

拦截器的实现也比较简单：

public class LoginInterceptor implements HandlerInterceptor { @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { HttpSession session = request.getSession(); if (session.getAttribute("loginUser") != null) { return true; } response.sendRedirect("/login"); return false; } }

写完拦截器之后还要在配置类里注册拦截路径，很多同学写了拦截器却忘记注册，导致拦截器完全没生效：

@Configuration public class WebMvcConfig implements WebMvcConfigurer { @Override public void addInterceptors(InterceptorRegistry registry) { registry.addInterceptor(new LoginInterceptor()) .addPathPatterns("/**") .excludePathPatterns("/login", "/loginPage", "/css/**", "/js/**", "/images/**"); } }

这里有个非常容易被忽略的问题：静态资源路径如果也被拦截，登录页的CSS和JS全部加载不出来，页面就会变成纯HTML的丑样子。所以我反复强调要把/css/**、/js/**等路径加进排除列表，不然排查半天都不知道问题出在哪。

4. 前端页面渲染与数据交互

4.1 Thymeleaf模板还是前后端分离

我见过不少同学在毕设里选择了前后端完全分离的方案，即Spring Boot只提供JSON接口，前端用Vue或者React单独写一套页面。这个方案对前端功底要求比较高，而且需要在服务器上额外部署Nginx处理静态文件，如果你时间紧或者前端基础一般，我不太建议。

Thymeleaf + Bootstrap组合的好处是Spring Boot内置支持，不用额外配置跨域，数据在服务端渲染好后直接输出HTML，代码量少，对毕设来说完全够用。

使用Thymeleaf时还要注意一个小坑：Spring Boot 2.x默认的模板前缀是classpath:/templates/，页面文件要放在resources/templates目录下，否则会报Error resolving template异常。之前指导的同学经常把HTML文件放在static目录下面，折腾半天报500错误，其实就是目录放错了。

4.2 列表页展示与表单校验要点

员工列表页是系统的门面，做得清楚会直接影响答辩时老师的第一印象。我的做法是表格上方放条件查询区域（工号/姓名输入框、部门下拉框、查询按钮），下方表格展示员工信息，最后一列放操作按钮（编辑、删除），再下边分页导航。

分页导航这部分，如果你用MyBatis Plus的Page对象，Thymeleaf页面里可以直接循环生成页码：

<div class="pagination"> <a th:href="@{'/employee/list?pageNum=1&size=' + ${page.size}}">首页</a> <a th:if="${page.current > 1}" th:href="@{'/employee/list?pageNum=' + ${page.current - 1} + '&size=' + ${page.size}}">上一页</a> <span th:text="${page.current} + ' / ' + ${page.pages}"></span> <a th:if="${page.current < page.pages}" th:href="@{'/employee/list?pageNum=' + ${page.current + 1} + '&size=' + ${page.size}}">下一页</a> <a th:href="@{'/employee/list?pageNum=' + ${page.pages} + '&size=' + ${page.size}}">末页</a> </div>

表单校验我给同学的建议是：前后端都做。前端用Bootstrap的required属性或者JS做基本非空校验，提升用户体验；后端在Service层再校验业务规则，比如工号重复、手机号格式。只做前端校验的后端接口，用Postman直接传脏数据就能绕过，老师如果懂行一眼就看出来系统的健壮性不够。

4.3 删除操作前的二次确认

直接点删除按钮就删数据，这个交互太鲁莽了。实际开发中删除前必须弹窗确认，防止误触。最简单的实现是在删除按钮上绑定一个JS确认事件：

<a th:href="@{'/employee/delete/' + ${emp.id}}" class="btn btn-danger btn-sm" onclick="return confirm('确定要删除该员工吗？此操作不可恢复。')">删除</a>

这种实现方式虽然简单，但效果好。线下答辩演示时，老师会点删除按钮，你弹个确认框既专业又能防止演示过程中误删数据导致尴尬。我遇到过同学演示时手滑删错了一条数据，又没有备份，结果在那手动还原数据库，画面非常混乱。如果你提前做了二次确认，这个坎基本能避开。

5. 项目测试与打包部署实录

5.1 本地功能测试清单

开发完成之后，我建议按照下面的测试清单过一遍，每一项都确认通过再进行打包部署：

• 登录成功/失败场景：正确密码能进入系统，错误密码有提示，未登录访问首页会跳登录
• 员工新增：必填字段为空能拦截，工号重复能提示，新增成功后列表页出现新数据
• 员工编辑：修改姓名、部门后再列表页刷新能看到新数据
• 员工删除：弹窗取消不删，确认后在列表页消失
• 分页查询：第二页数据与第一页不重复，条件查询结果与表格数据匹配
• 权限控制：普通员工账号看不到“删除”按钮或者删除接口返回无权限
• 数据库备份：操作完后再看一眼数据库表数据是否和页面显示一致

这个清单的关键价值在于防患于未然。很多同学开发时只测了自己写的“快乐路径”，比如登录成功进去能看见列表就觉得万事大吉，结果一测试删除就发现404，一查原因才发现路由映射写错了。答辩演示的时候，老师往往会敲几个边界条件，比如你输入一个不存在的人名来查，如果你没做空结果处理，页面直接白屏或者报错，印象分会掉一截。

5.2 项目打包部署的两种方式

毕设常见的部署方式有两种：一种是直接在IDEA里运行，另一种是打包成JAR放到服务器上运行。如果你只需要本地演示，方式一完全够。但答辩时如果电脑突然出问题，或者老师想看一下远端访问效果，方式二会更稳妥。

打包命令：

mvn clean package -DskipTests

打包成功后target目录下会生成一个employee-system-0.0.1-SNAPSHOT.jar文件。如果部署在服务器上，直接用：

java -jar employee-system-0.0.1-SNAPSHOT.jar --spring.profiles.active=prod

这里要提前规划好生产环境的配置。我一般建议单独写一个application-prod.yml，把数据库地址改成服务器的IP，然后端口使用80或者8080。如果你部署到某云服务器，记得在安全组或者防火墙规则里放行对应端口，否则外部访问不通。曾经有个同学的部署答辩演示环节挂了，就是他以为把端口号改成8080就行，结果安全组默认只开了80和3389，半天都连不上。

6. 常见问题与排查技巧速查表

6.1 高频报错及解决方案

这部分我整理成了表格，都是我实际带毕设时高频出现的问题，遇到对应报错可以直接按表格排查：

6.2 容易被忽略的版本兼容问题

Spring Boot与MyBatis Plus以及MySQL驱动之间的版本匹配，是“毕设十大隐形杀手”之首。前端时间某同学在pom.xml里加了Spring Boot 3.0.5的最新版本，结果MyBatis Plus 3.4.x不支持JDK 17的新特性，项目启动时直接报了一堆反射相关的错误。事实上MyBatis Plus官方适配Spring Boot 3是从3.5.3版本开始的，很多老版本3.3.x根本不兼容。

我给你的建议是尽量不要追新版本，直接用Spring Boot 2.7.16版本打底，搭配MyBatis Plus 3.5.3.1，这种组合我实测过很多台机器，稳定性很高。如果非得用Spring Boot 3.x，那你要做好心理准备，可能需要在网上翻更多的适配文档。

6.3 数据一致性维护的实操心得

这个点我一定要单独拿出来说，因为太多人做毕设时完全不考虑数据一致性问题。什么叫数据一致性问题？举个例子：员工表里有个部门ID为1的员工，你在部门管理页里把这个部门删了，员工那边就变成“无部门”状态。如果你编程时没处理这个逻辑，数据库里就是一堆脏数据。

我在这个项目的表结构设计中把员工表和部门表用外键关联，但没有物理外键约束。为什么不建物理外键？因为很多老师会拿“数据库设计合理性”来问问题，物理外键会锁表，插入和更新数据时性能开销比较大，更重要的是，如果建了物理外键，删除部门时MySQL会直接抛外键约束异常，而异常消息不友好，用户看到的是一堆乱码。所以更合适的做法是在部门删除的Service方法里，先查一下有没有员工还归属这个部门，有的话就拦截并提示“该部门下还有员工，请先调整员工部门”。

这算是一个比较符合实际业务经验的设计，也容易在答辩时展开讲，是一个不错的加分点。

6.4 关于实习和简历项目的延展

这个员工信息管理系统虽然叫“员工信息”，但如果你把它往简历上写，尽量不要太直接了事，我建议在技术点上做些延展：

• 引入Redis缓存热点员工数据，并说明缓存穿透和缓存击穿的解决方案
• 使用Spring AOP记录操作日志并持久化到数据库
• 通过Layui或Bootstrap完成响应式页面布局，说明自己对前端组件库有了解
• 给查询接口加上参数校验和统一返回结果处理，体现接口设计的规范思维

如果时间充裕，还可以把登录流程图和数据表ER图画出来，排版放进论文中，比单纯的文字描述直观很多。很多同学的项目答辩表上写的“熟练使用Spring Boot”只是嘴上说说，你把技术点真正摆出来，老师追问几句一样能答上，这才算扎实。

回到我自己的经验上：今年带过的某位同学就是按上面这套方案完成的，从需求分析到数据库设计到编码，大概花了十来个工作日的晚上，最后在答辩时演示了员工分页查询、部门联动下拉、操作权限控制以及异常提示几个场景，整个流程大约七分钟，老师问了两个问题他都顺利答上来了，最终评了个不错的分数。最关键的是这套体系不是靠“背代码”硬撑起来的，每块代码自己都理解透彻，碰上提问不会慌。

如果你正在做这个题目，希望这篇文章能减少你查资料的时间。最后再提醒一句：动手写代码前先把数据库表结构设计好，这是整个项目的地基。地基歪了，后面写再多代码都要返工。