企业官网建设流程全解析

每年到课程设计或者项目设计季，总能在技术社群里看到同一类提问：Spring Boot的校园疫情防控系统怎么做？代码跑不起来怎么办？数据库怎么导？论文怎么写？这套系统我前后带过不少同学从零搭到完整交付，正好借这篇博文把完整链路捋一遍。本文会围绕Spring Boot校园疫情防控系统的需求拆解、MySQL数据库表结构设计、后端核心接口实现、前端界面交互、调试部署要点，以及配套论文文档的组织方式展开，适合正在做课程设计、毕业设计，或者想快速上手Spring Boot全栈项目的人参考。我会把开发环境版本、表结构字段、接口写法、部署报错这些实际会踩到的细节都摊开讲，尽量让你照着做就能把系统跑起来。

1. 先搞清楚系统到底要做什么：校园疫情防控的业务拆解

很多人拿到题目直接开码，结果做出来的东西要么功能对不上业务，要么页面堆了一堆用不上的按钮。做这类系统，第一步永远是先把需求盘清楚。

1.1 三种核心角色与权限边界

校园场景下的疫情防控，参与的人大致可以分成学生、辅导员/教师、管理员三档。角色不同，能看到的数据和能做的操作完全不同，这一点直接决定了你的权限模块怎么写。

• 学生：每日健康打卡、查看自己的健康状态与打卡记录、发起出入校申请、查看学校发布的公告。
• 辅导员/教师：查看本班或本年级学生的健康打卡情况、收到异常预警、审批学生的出入校申请。
• 管理员（校医、后勤或系统维护人员）：全部数据看板、管理学生和教职工基础信息、处理异常预警、发布公告、导出健康统计数据。

权限设计这块，我建议直接用基于角色的访问控制模型，也就是RBAC。不要偷懒在用户表里加一个"role"字段了事，因为后续你会发现管理员和辅导员的可见范围差异很大，单字段根本描述不了。正确做法是拆三张表：用户表、角色表、用户角色关联表，再配合拦截器对接口做权限校验，这样后面扩展"楼栋管理员""宿管"之类的角色也方便。

1.2 从每日打卡到异常处置的完整业务闭环

一个能真正落地运行的校园疫情防控系统，核心不只是"填体温"，而是一条完整的闭环：

1. 学生每天在移动端填写体温、健康状况（正常/咳嗽/乏力等）、当前所在地、是否去过风险地区、随行人员情况等信息。
2. 系统根据规则自动判断风险等级。比如体温超过37.3℃、或勾选了"近14天去过中高风险地区"时，系统自动标记该学生的健康状态为"异常"。
3. 辅导员的页面出现异常提醒，点击查看详情后可以电话核实，并在系统内填写处理结果，例如"已联系，校医跟进"、"疑似普通感冒"等。
4. 管理员在统计看板看到全校异常数量、各学院打卡率，可以按条件导出Excel表格上报。

这个闭环里，"打卡-判定-预警-处置-统计"五个环节缺一不可。做系统的时候，不要只把打卡记录存进去就完事，异常规则判定和预警列表是老师最关心的功能，也是论文里最好写"系统特色"的地方。

1.3 功能清单与优先级排序

根据上面业务拆解，推荐功能清单如下表所示，标注清楚哪些是必需项，哪些是加分项。

我见过不少同学把大量时间花在做公告管理的富文本编辑上，结果核心的打卡和审批反而做得粗糙。合理的时间分配应该是：数据库设计和核心接口各占三成时间，页面展示占两成，剩余两成留给调试部署和论文。

2. 数据库设计：决定你后面会不会大改版的表结构

数据库是整个系统的地基，也是最容易返工的地方。很多同学一开始建表字段不全，做到接口才发现要加字段，改起来牵一发动全身。下面直接给出一套我验证过可以直接用的表结构方案。

2.1 用户、角色与人员基础信息表

首先是用户体系相关的三张核心表。

sys_user表（用户表）：

sys_role表：id、role_code（如STUDENT、TEACHER、ADMIN）、role_name。

sys_user_role表：id、user_id、role_id。这张关联表可以一个用户挂多个角色，虽然本系统用不到，但保留了扩展空间。

接下来是业务数据。学生和教职工的基本信息我建议单独建表，不要全部塞进sys_user，因为学生有学号、学院、班级、宿舍，教师有工号、所属院系，字段差异较大。

student表（学生信息表）：

这里有一个值得注意的设计细节：为什么不把所有字段直接放sys_user，然后冗余一个"身份类型"字段？因为学生和教师将来可能需要维护的字段不同，比如学生有班级和宿舍，教师有职称和所属系部。把它们拆开，各自的表结构更清爽，后续扩展各自模块不会干扰主登录表。

2.2 健康打卡记录表：宁可多冗余，不要多联表

健康打卡是本系统最高频操作的表，每天会产生大量数据，它的设计直接关系到列表查询速度。

health_check_record表（健康打卡记录表）：

注意这里我把学生姓名、学号、学院、班级冗余进了打卡记录表。有些同学会觉得这违反了数据库范式，但实际项目里这样做非常实用，因为打卡记录查询场景基本是"按学院统计""按班级筛选"，如果每次都要去关联student表甚至sys_user表，数据量大了以后查询会明显变慢。而且打卡记录是流水数据，每天学生信息即使改了，打卡时的快照信息也不应该变，冗余反而保留了历史客观性。

给表加上联合索引KEY idx_user_time (user_id, create_time)，以及单独为college和class_name建索引，因为统计报表经常按这两个字段分组。

2.3 出入校申请与审批记录表

出入校管理需要两张表：申请主表和审批记录表，不要试图用一堆状态字段塞在同一张表里。

entry_exit_apply表（出入申请主表）：id、user_id、student_no、real_name、apply_type（出校/入校）、reason、destination、leave_time、expected_return_time、status（0待审批，1通过，2驳回）、create_time。

approval_record表（审批记录表）：id、apply_id（关联申请主表）、approver_id（审批人用户ID）、approver_name、approve_result（通过/驳回）、approve_comment、approve_time。

审批记录单独建表的价值在于：一次申请可能被驳回后再提交，每次审批意见都需要留痕。你要是只用一个字段存审批意见，后面写"历史审批记录"功能时还得重新设计表，不如一开始就拆清楚。

2.4 运行初始化SQL的注意点

数据库这块我建议用MySQL 5.7或8.0都行，但要注意字符集统一使用utf8mb4，否则存emoji表情或特殊符号时会报错。建库语句记得加：

CREATE DATABASE IF NOT EXISTS campus_epidemic DEFAULT CHARACTER SET utf8mb4 DEFAULT COLLATE utf8mb4_general_ci;

3. Spring Boot后端实现：从Maven配置到核心接口

后端是整个项目的大脑。这里我直接介绍一套最稳妥的技术组合：Spring Boot 2.7.x + MyBatis Plus + MySQL + Lombok。为什么选 MyBatis Plus？因为它内置了单表CRUD方法，能省掉大量重复的Mapper XML代码，对课设和毕设项目来说性价比非常高。如果精力充足，想体现"手写SQL能力"，也可以保留部分自定义Mapper XML，两者不冲突。

3.1 项目初始化与pom.xml依赖

创建Spring Boot项目时，建议使用Spring Initializr或者IDEA自带的Spring Boot创建向导，Java版本选1.8（如果电脑装了更高版本JDK，要注意Spring Boot 2.7系列对Java 8到Java 17都有比较好的支持，但稳妥起见还是用JDK 8）。

核心依赖如下：

<dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</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> <version>8.0.33</version> </dependency> <dependency> <groupId>org.projectlombok</groupId> <artifactId>lombok</artifactId> <optional>true</optional> </dependency> <dependency> <groupId>cn.hutool</groupId> <artifactId>hutool-all</artifactId> <version>5.8.18</version> </dependency>

Hutool是我个人非常推荐的工具包，里面有验证码生成、日期处理、Excel导出、加密工具等方法，做课设级项目能省下大量"造轮子"的时间。

3.2 application.yml环境配置

配置文件的正确写法是跑通项目的第一步，也往往是新手最容易卡住的地方。这里给出一份可以直接用的配置，注意数据库用户名密码要改成你自己的。

server: port: 8080 spring: datasource: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://localhost:3306/campus_epidemic?useUnicode=true&characterEncoding=utf8mb4&useSSL=false&serverTimezone=Asia/Shanghai username: root password: 123456 jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: GMT+8 mybatis-plus: configuration: log-impl: org.apache.ibatis.logging.stdout.StdOutImpl map-underscore-to-camel-case: true global-config: db-config: logic-delete-field: deleted logic-delete-value: 1 logic-not-delete-value: 0

map-underscore-to-camel-case这个配置一定要开，它能把数据库的create_time自动映射成Java实体类的createTime，少写很多@TableField注解。log-impl配成StdOutImpl能在控制台输出SQL日志，调试时看实际执行的SQL语句非常方便，但正式部署建议去掉，否则日志会刷得很快。

3.3 登录认证：JWT还是Session

登录方案我推荐用JWT，也就是JSON Web Token。很多课设还在用传统的Session + Cookie，但在前后端分离的场景下，JWT的体验明显更好：前端把Token存在本地，每次请求往请求头里带Authorization: Bearer xxx，后端用一个拦截器统一校验。

生成Token用Hutool自带的JWT工具就能实现：

String token = JWT.create() .setPayload("userId", user.getId()) .setPayload("roleCode", role.getRoleCode()) .setExpiresAt(new Date(System.currentTimeMillis() + 7 * 24 * 3600 * 1000)) .sign();

密码存储绝对不能用明文。推荐使用BCryptPasswordEncoder，Spring Security里可以直接拿来用，不引入完整Spring Security，单独引入spring-security-crypto这个依赖即可。

3.4 健康打卡接口：Controller、Service、Mapper三层写法

健康打卡是系统的核心功能，直接上代码。先写实体类：

@Data @TableName("health_check_record") public class HealthCheckRecord { @TableId(type = IdType.AUTO) private Long id; private Long userId; private String studentNo; private String realName; private String college; private String className; private BigDecimal temperature; private String healthStatus; private Integer isHaveCough; private Integer isHaveFatigue; private String currentLocation; private Integer isRiskArea; private String riskLevel; private String remark; private Date createTime; }

Controller层很薄，只做参数接收和结果返回：

@RestController @RequestMapping("/api/health") public class HealthCheckController { @Resource private HealthCheckService healthCheckService; @PostMapping("/submit") public Result submit(@RequestBody HealthCheckRecord record) { return healthCheckService.submitCheck(record); } @GetMapping("/my-records") public Result myRecords(@RequestParam Integer page, @RequestParam Integer limit) { return healthCheckService.getMyRecords(page, limit); } }

Service层里需要写核心的业务规则，也就是风险等级的自动判定逻辑：

public Result submitCheck(HealthCheckRecord record) { // 规则1：体温大于37.3度，风险等级设为"高" if (record.getTemperature().compareTo(new BigDecimal("37.3")) > 0) { record.setRiskLevel("高"); record.setHealthStatus("异常"); } // 规则2：近14天去过中高风险地区，风险等级设为"高" else if (record.getIsRiskArea() == 1) { record.setRiskLevel("高"); record.setHealthStatus("异常"); } // 规则3：有咳嗽或乏力症状，风险等级设为"中" else if (record.getIsHaveCough() == 1 || record.getIsHaveFatigue() == 1) { record.setRiskLevel("中"); record.setHealthStatus("关注"); } // 规则4：全部正常，低风险 else { record.setRiskLevel("低"); record.setHealthStatus("正常"); } // 防止同一天重复打卡，业务上一天只允许一次有效打卡 LambdaQueryWrapper<HealthCheckRecord> wrapper = new LambdaQueryWrapper<>(); wrapper.eq(HealthCheckRecord::getUserId, record.getUserId()) .ge(HealthCheckRecord::getCreateTime, DateUtil.beginOfDay(new Date())) .le(HealthCheckRecord::getCreateTime, DateUtil.endOfDay(new Date())); Long count = baseMapper.selectCount(wrapper); if (count > 0) { // 这里按业务需求选择：可以更新原记录，也可以直接拒绝。一般情况下当天可补卡修改。 record.setId(baseMapper.selectOne(wrapper).getId()); return Result.success(baseMapper.updateById(record)); } baseMapper.insert(record); return Result.success("打卡成功"); }

这里有一个关键点：很多同学拿到需求后在Service里疯狂堆if...else...，代码越写越长。实际上可以将规则判定抽成一个独立的方法，比如private String evaluateRiskLevel(HealthCheckRecord record)，然后在submitCheck里调用。这样一方面代码更整洁，另一方面论文的"核心算法描述"章节也有独立素材可写。

3.5 统计报表接口：SQL聚合与Excel导出

统计报表是使用方（辅导员、管理员）最常用的功能，比如统计各学院当天的打卡人数、打卡率、异常人数。这类接口写起来不复杂，重点是SQL语句。

<select id="selectCollegeStats" resultType="map"> SELECT college, COUNT(*) AS total_count, SUM(CASE WHEN health_status IN ('正常', '关注') THEN 1 ELSE 0 END) AS normal_count, SUM(CASE WHEN health_status = '异常' THEN 1 ELSE 0 END) AS abnormal_count FROM health_check_record WHERE DATE(create_time) = #{date} GROUP BY college ORDER BY abnormal_count DESC </select>

如果还要算打卡率，需要和student表做一次关联，统计每个学院应打卡总人数，再进行除法计算。这一部分在Mapper XML里写SQL就可以，不必用MyBatis Plus的QueryWrapper硬凑，因为复杂聚合语句用QueryWrapper反而难读。

数据导出Excel方面，使用Hutool的ExcelWriter可以快速实现：

public void exportCollegeStats(HttpServletResponse response) { List<Map<String, Object>> stats = healthCheckMapper.selectCollegeStats(DateUtil.today()); ExcelWriter writer = ExcelUtil.getWriter(true); writer.write(stats, true); response.setContentType("application/vnd.openxmlformats-officedocument.spreadsheetml.sheet;charset=utf-8"); response.setHeader("Content-Disposition", "attachment;filename=stats.xlsx"); ServletOutputStream out = response.getOutputStream(); writer.flush(out, true); writer.close(); }

这样一个实时导出的功能就完成了，非常适合做每日上报场景，也方便论文里写"系统实现了数据导出功能"这一节。

3.6 拦截器与权限校验：容易忽略但必须做

接口写完之后，一定要加一个拦截器做登录态和权限校验。不然别人知道你的接口路径，直接跳过前端页面就能调接口拿数据，这在答辩时被老师问一句"你的系统怎么保证数据安全"就很容易答不上来。

写一个AuthInterceptor，实现HandlerInterceptor接口：

public class AuthInterceptor implements HandlerInterceptor { @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { // 放行登录接口 String uri = request.getRequestURI(); if (uri.contains("/api/auth/login") || uri.contains("/api/auth/captcha")) { return true; } String token = request.getHeader("Authorization"); if (StringUtils.isBlank(token)) { response.setStatus(401); return false; } try { JWTValidator.of(token).validateDate(); // 解析token中的用户信息，放入request，供后续接口获取当前登录用户 String userId = JWTUtil.parseToken(token).getPayload("userId").toString(); request.setAttribute("userId", userId); return true; } catch (Exception e) { response.setStatus(401); return false; } } }

然后在配置类中注册拦截器，并配置放行路径：

@Configuration public class WebConfig implements WebMvcConfigurer { @Override public void addInterceptors(InterceptorRegistry registry) { registry.addInterceptor(new AuthInterceptor()) .addPathPatterns("/api/**") .excludePathPatterns("/api/auth/login", "/api/auth/captcha"); } }

如果想进一步做角色级权限控制，可以在拦截器里解析出roleCode，再根据角色放行或拒绝某些路径。比如/api/admin/**只允许ADMIN角色访问，/api/student/**只允许STUDENT角色访问。

4. 前端页面与系统界面：功能完整还要好看

标题里提到"系统界面在最后面"，说明界面展示是这类项目的亮点之一。一个好的界面不仅仅是好看，更重要的是信息架构清晰，符合角色使用习惯。

4.1 技术选型：Vue + Element UI还是Thymeleaf

如果对前端不熟悉，建议直接用Thymeleaf + Bootstrap，学习成本低、服务端渲染简单，页面代码全部塞在Spring Boot的resources/templates目录下，不用处理跨域问题。

如果前端有一定基础，可以选Vue 2 + Element UI，配合Vue Router和Axios做前后端分离，界面质感会明显更好。项目跑起来时开两个端口，前端在8081，后端在8080，开发时配置一个proxy转发即可。

// vue.config.js module.exports = { devServer: { port: 8081, proxy: { '/api': { target: 'http://localhost:8080', changeOrigin: true } } } }

对于课设和毕设项目，我更推荐Vue + Element UI的方案，因为界面美观程度直接影响答辩老师和评分人的第一印象。

4.2 管理端页面布局

管理端界面建议采用经典的"左侧菜单 + 右侧内容区"布局，左侧菜单按角色动态渲染。管理员看到的菜单包括：数据看板、学生管理、健康记录查询、出入校审批、异常预警、公告管理。学生登录后看到的菜单则要精简：健康打卡、我的记录、出入校申请、公告查看。

数据看板是视觉重心，建议用ECharts做图表展示。比如用柱状图展示各学院打卡率，用折线图展示近7天健康打卡人数变化，用饼图展示全校健康状况分布。ECharts的引入和使用非常简单：

import * as echarts from 'echarts'; mounted() { this.initChart(); }, methods: { async initChart() { const res = await axios.get('/api/admin/dashboard/trend'); const chart = echarts.init(this.$refs.trendChart); chart.setOption({ xAxis: { type: 'category', data: res.data.dates }, yAxis: { type: 'value' }, series: [{ type: 'line', data: res.data.counts, areaStyle: {} }] }); } }

4.3 移动端/学生端打卡页面

学生端的核心页面就是健康打卡表单。表单设计要尽量降低填写成本，能选择的就不要让用户手动输入。比如健康状况用单选按钮、是否咳嗽用开关、当前所在地用下拉选择，体温用数字输入框并限制范围。

前端需要做的基本校验不要省略。体温的合理范围、必填项是否为空，这些在提交之前就应该拦下，而不是等后端返回报错再提示。

submitForm() { this.$refs.form.validate((valid) => { if (valid) { axios.post('/api/health/submit', this.form) .then(res => { this.$message.success('打卡成功'); this.loadRecords(); }); } else { this.$message.warning('请检查表单填写内容'); } }); }

4.4 联调中的跨域、Token携带问题

前端联调时最容易碰到两个问题：跨域和Token没带上。

跨域在开发阶段可以用Vue的proxy解决，但如果你把前端打包后放在Nginx里，就需要后端配合配置CORS，或者在Nginx里配置proxy_pass反向代理。推荐直接用Nginx统一代理前端和后端，这样浏览器看到的始终是同源地址，跨域问题从根上消失。

Token携带则在Axios请求拦截器里统一处理：

axios.interceptors.request.use(config => { const token = localStorage.getItem('token'); if (token) { config.headers.Authorization = `Bearer ${token}`; } return config; }); axios.interceptors.response.use( response => response, error => { if (error.response && error.response.status === 401) { localStorage.removeItem('token'); this.$router.push('/login'); } return Promise.reject(error); } );

这一套逻辑可以说是我在用Vue做各种系统时积累下来的标准模板，任何前后端分离项目中都能直接复用。

5. 调试部署与开发环境：解决跑不起来的常见坑

这一部分是全篇文章里含金量比较高的实操内容。我帮不少同学排查过项目跑不起来的各种问题，很多最终都落在环境配置而不是代码本身。

5.1 开发环境版本清单

建议按以下版本组合来搭建，避免版本兼容问题：

Maven依赖下载慢的问题建议提前配好阿里云镜像，在settings.xml里的mirror节点加：

<mirror> <id>aliyunmaven</id> <mirrorOf>central</mirrorOf> <name>阿里云公共仓库</name> <url>https://maven.aliyun.com/repository/public</url> </mirror>

5.2 本地启动报错的完整排查链路

场景一：启动类报Failed to configure a DataSource错误。

这个报错的本质是Spring Boot启动时自动寻找DataSource配置，但找不到或者配置不对。排查链路如下：

1. 检查application.yml里的数据库URL、用户名、密码是否正确。
2. 检查MySQL服务是否已启动，命令行执行mysql -u root -p能否连接。
3. 检查是否缺少数据库驱动依赖，MySQL 8.0对应mysql-connector-java的8.x版本。
4. 检查数据库是否已创建，执行SHOW DATABASES;确认campus_epidemic这个库存在。

场景二：端口被占用报Port 8080 was already in use。

这种情况很常见，尤其是电脑上装了其他Web服务。解决方式：要么用netstat -ano | findstr 8080找出占用进程关掉，要么在application.yml里改端口号。

场景三：前端页面能打开但接口报404。

这通常是接口路径写错了。Spring Boot的接口路径由@RequestMapping和方法的@GetMapping拼接而成，如果你在类上写了/api/health，方法上写了/submit，那完整路径就是/api/health/submit。前端请求时少了一个/api或拼错单词都会报404。前端F12查看网络请求的URL，再与后端Controller对比，基本一眼就能发现问题。

5.3 数据库初始化与数据迁移

项目压缩包自带的SQL脚本，在MySQL中执行时要注意执行方式：

mysql -u root -p campus_epidemic < campus_epidemic.sql

或者使用可视化工具Navicat/DBeaver直接导入SQL文件。导入之后务必检查几个关键点：

• 表是否全部创建成功
• 初始管理员账号是否存在（通常是admin/admin123）
• 测试学生账号密码是否正确
• 表数据中时间字段是否为NULL（如果为NULL会报错）

5.4 打包部署到服务器

项目本地跑通后，想部署到服务器，用Maven打包：

mvn clean package -DskipTests

打包后在target目录下会生成一个xxx.jar文件。上传到服务器后执行：

nohup java -jar campus-epidemic-0.0.1-SNAPSHOT.jar > app.log 2>&1 &

访问http://服务器IP:8080即可。如果访问不通，检查阿里云/腾讯云安全组的8080端口是否放行。很多同学部署之后发现页面打不开，排查一圈发现是云服务器安全组规则没配置，这种低级错误反而最耽误时间。

6. 论文文档写作：一万字论文怎么组织才容易过审

标题里明确提到带论文文档1万字以上，所以项目做完，还得把论文写好。很多技术能力不错的同学卡在论文上，不是不会写，而是不知道结构怎么搭。

6.1 论文结构如何与系统模块呼应

一份标准的系统开发类论文，结构一般为：

1. 绪论：研究背景、国内外现状、研究内容与方法。这里要写清楚为什么要做校园疫情防控系统，现有人工管理方式存在哪些问题。
2. 相关技术介绍：Spring Boot框架、MyBatis Plus、MySQL、前端框架、JWT等。每个技术写2-3段，介绍是什么、为什么选它。
3. 需求分析：可行性分析、功能需求分析、角色分析、用例图、非功能需求。
4. 系统设计：总体架构设计、功能模块设计、数据库设计（ER图、数据表字段说明）。这一章节是重点，可以直接把本文第2节的表结构内容展开写。
5. 系统实现：核心功能模块的界面截图和关键代码片段。截图要清晰，代码要选有代表性的，不要大段贴Controller层毫无营养的代码。
6. 系统测试：测试环境、测试用例设计、测试过程与结果分析。
7. 总结与展望：总结完成的工作，分析不足和后续改进方向。

6.2 图表与测试数据怎么准备

论文里图表的重要性怎么强调都不为过。一份有大量图表的论文，给老师的印象分至少比纯文字高一个档次。

需要准备的核心图包括：

• 系统总体架构图
• 功能模块图
• 数据库ER图（用PowerDesigner或者draw.io都能画）
• 核心业务流程图（比如健康打卡流程图）
• 登录时序图

测试数据方面，不要只准备一条"正常打卡"的用例。建议准备以下几类：

6.3 答辩前一定要准备的问题

答辩环节老师最喜欢从这几个角度提问：

1. 系统有哪些角色？每个角色能做什么？——对应需求分析章节。
2. 数据库表之间是什么关系？——要能指着ER图解释一对一、一对多关系。
3. 健康打卡的风险判定规则是什么？——要能说出判定逻辑和阈值，最好强调这是系统的创新点。
4. 密码是怎么存储的？如何防止SQL注入？——要能说出BCrypt加密和MyBatis的预编译机制。
5. 系统还有什么不足？——建议回答一些诚实且合理的不足，比如"数据可视化形式还可以更丰富""暂未接入真实定位和行程数据"等，避免过于自夸。

把这些准备充分，答辩基本就没有太大问题。

7. 写在最后的个人经验

我在给多个课程设计项目做代码审查和调试时发现，校园疫情防控系统这类"信息管理+流程审批+统计分析"的项目，最锻炼人的不是某个高深算法，而是把一个完整业务落到数据库表、后端接口、前端页面上的工程能力。做得好的同学，往往赢在表结构设计合理、异常流程考虑周全、部署文档齐全，而不是谁写的代码更炫技。这里分享一个我自己常用的项目验收清单：拿到一份项目压缩包后，按"导入数据库—配置环境—启动后端—启动前端—跑通核心流程"的顺序过一遍，任何一环卡住都能快速定位是环境问题还是代码问题。这套思路用熟了，以后接手任何新项目心里都有底。希望这篇从业务拆解到表结构、接口实现、界面联调、部署排错、论文答辩的完整复盘，能让你少走一些我当年走过的弯路。