企业官网建设流程全解析

简介：这是一套面向高校计算机专业本科生的校园失物招领管理系统毕设级源码，聚焦毕业设计、课程设计与期末大作业场景，采用前后端分离架构，以SpringBoot为后端核心、Vue.js构建响应式前端，切实解决校园内失物登记、招领匹配、信息公示与管理员协同管理等实际问题。压缩包共97个文件，含69个Java业务逻辑与实体类文件（覆盖Controller、Service、Mapper层）、13个XML映射配置、9张界面截图与图标资源（JPG）、2个YML配置文件（含数据库与服务配置）、1个完整建表SQL脚本及1个Gradle构建脚本（Groovy），整体仅1005KB，轻量易部署。已有202人下载学习，项目代码全程手打，关键模块均附中文注释，结构清晰、分层规范，含独立的core-redis、core-swagger等可扩展模块，便于新手理解MVC流程与常见中间件集成方式，亦可作为SpringBoot+Vue工程化实践的优质参考范例。 作为一个过来人，我深知每年毕业季，多少同学为毕设选题愁到头秃。如果你正在找“基于SpringBoot+Vue的校园失物招领管理系统”这类题目，说明你大概率已经意识到：技术栈主流、业务清晰、工作量适中的项目，才是最稳妥的拿高分选择。这套系统我前后帮人调过好几个版本，也陪跑过不少答辩，今天就把整个项目的思路、表结构、接口设计、前端交互细节，以及那些文档里不会写的踩坑经验，一次性整理出来。

这套系统解决的核心问题非常明确：校园里丢东西、捡到东西的人信息不对称。传统靠公告栏、QQ群、朋友圈，信息散且容易沉底。失物招领系统的价值就是把“丢失登记”和“拾获登记”统一到一个平台，并完成匹配、认领、审核、公告的闭环。作为毕设，它覆盖了用户注册登录、角色权限、CRUD、图片上传、模糊搜索、分页、状态流转这些核心知识点，麻雀虽小五脏俱全，特别适合拿来证明你掌握了前后端分离开发的基本功。

我写这篇东西，不是给你贴一堆网上随便能找到的代码片段，而是希望你看完之后，能真正理解这个系统为什么要这样设计，数据库为什么建这些表，接口为什么返回这个结构，以及更重要的是——老师可能会从哪些角度追问你。

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

1.1 为什么是SpringBoot+Vue这套组合

咱们先把技术栈这事聊透。你选SpringBoot+Vue，不是因为它“看起来主流”，而是这套组合确实最适合这类管理系统的毕设场景。

后端用SpringBoot，核心优势是零配置起步。你要写一个查询接口，只需要建Controller、Service、Mapper三个类，加上注解就能跑起来，不用像早期SSH框架那样写一堆XML配置文件。这一点对时间紧张的毕设党来说非常友好。而且SpringBoot内置了Tomcat，本地开发一个main方法就能启动，打成一个JAR包部署也很方便。

前端用Vue，理由同样实在。Vue对新手最友好的一点是渐进式——你不需要一开始就掌握全套工程化工具链，先学会data、methods、v-for、v-if这几个核心概念，再配合Vue CLI脚手架，几分钟就能拉起一个可用的前端工程。配合Element UI组件库，表格、表单、弹窗、菜单这些后台管理常见界面，几乎不用自己写样式，拖出组件填上数据就行。

数据库用MySQL，理由更简单——它是当前Web开发的事实标准，网上资料最多，遇到问题一搜基本都有现成答案。如果你后续想加分，把项目换成兼容MySQL的国产数据库（比如达梦或者人大金仓）作为亮点，也是很多老师认可的扩展方向。

1.2 系统模块划分与角色设计

失物招领系统的核心业务逻辑不复杂，但角色的划分很关键。我建议你按三种角色设计，刚好对应学生、管理人员两种真实使用场景：

• 普通用户（学生/教职工）：注册登录后可发布失物、发布招领、浏览信息、提交认领申请、收藏关注。
• 系统管理员：负责审核用户发布的失物/招领信息，管理公告，处理认领申请，封禁违规用户。
• 超级管理员：管理普通管理员账号，查看统计数据，系统配置维护。

为什么我要强调“认领申请需要审核”这个流程？很多同学图省事，把系统做成谁都能直接联系失主，这在功能上没错，但在业务上有个漏洞——你怎么确认认领人就是失主本人？所以合理的设计是，普通用户看到招领信息后提交“认领申请”，并填写物品特征描述，由管理员审核比对后，才能获取对方的联系方式或完成线下交接。这个状态流转的过程，恰好也是你答辩时可以重点讲解的亮点，因为它在业务层面体现了一个“合理闭环”。

1.3 技术架构与工程结构

我的建议是严格按照前后端分离来组织工程，前端一个文件夹，后端一个文件夹，不要混在一起。后端按分层分包：

com.example.lostfound ├── config // 配置类，如跨域配置、拦截器配置、Swagger配置 ├── controller // 控制层，接收前端请求 ├── service // 业务逻辑层，处理核心业务 │ └── impl // 业务实现类 ├── mapper // MyBatis-Plus数据访问层 ├── entity // 数据库实体类 ├── dto // 数据传输对象，用于接口参数接收 ├── vo // 视图对象，用于接口返回值封装 ├── common // 通用类，如统一返回结果、异常处理、常量定义 └── util // 工具类，如JWT工具、文件上传工具

前端用Vue CLI或者Vite创建工程后，按模块划分views目录，比如views/login、views/lost、views/found、views/admin、views/profile，每个人再配一个components子目录存放私有的子组件。针对vue路由，配置路由守卫，未登录的用户强制跳转登录页。

这套结构看起来很简单，但它体现了分层思想和模块化思想，这两个词在答辩现场是能直接说出口的“专业术语”。老师问你“你的项目架构是什么”，你不能只说“用了SpringBoot和Vue”，而是要说出谁负责接收请求、谁处理业务、谁操作数据库、谁渲染页面，这就把你的工程素养展示出来了。

2. 数据库设计与核心表结构

2.1 数据库设计思路

数据库是这类管理系统的根。我见过太多同学，代码写完了，数据库就两张表：一张用户表一张物品表，然后认领记录随便拿个字段存一下。这样虽然能跑，但业务逻辑完全没法展开，答辩时老师问两句就露馅了。

我按业务线给你拆一下，一个完整的失物招领系统，至少需要这几张核心表：

• 用户表（sys_user）：账号、密码、昵称、手机号、学号/工号、角色、头像、状态、创建时间。
• 失物表（tb_lost）：丢失物品名称、物品描述、丢失地点、丢失时间、图片、状态（待匹配/匹配中/已找回/已下架）、发布人ID、浏览量。
• 招领表（tb_found）：拾获物品名称、物品描述、拾获地点、拾获时间、图片、存放地点、状态（待认领/认领中/已完成/已下架）、发布人ID、浏览量。
• 认领申请表（tb_claim）：关联失物ID或招领ID、申请用户ID、申请描述、状态（待审核/已通过/已拒绝/已完成）、审核人ID、审核时间。
• 收藏表（tb_favorite）：用户ID、物品ID、物品类型（失物/招领）、收藏时间。
• 公告表（tb_notice）：标题、内容、发布时间、创建人。
• 评论表（tb_comment）：用户ID、物品ID、评论内容、评论时间。

这里有一个容易忽略的点：为什么认领申请表要设计成冗余关联，而不是单独区分“失物认领”和“招领认领”？从业务上讲，用户可以针对一条招领信息发起“我要认领”，也可以针对一条失物信息提供“我捡到了线索”。这两种场景的行为本质是相同的——都是用户与物品之间建立认领关系。合并成一张表，用type字段区分针对的是失物还是招领，能极大简化前后端的逻辑复杂度，也方便管理员在后台统一审核。这种“抽象共性”的设计思路，是答辩时的加分项。

2.2 表结构SQL示例

下面给出核心表的建表SQL，你可以直接参考使用。

-- 用户表 CREATE TABLE `sys_user` ( `id` bigint(20) NOT NULL AUTO_INCREMENT COMMENT '主键ID', `username` varchar(50) NOT NULL COMMENT '用户名', `password` varchar(100) NOT NULL COMMENT '密码(BCrypt加密)', `nickname` varchar(50) DEFAULT NULL COMMENT '昵称', `phone` varchar(11) DEFAULT NULL COMMENT '手机号', `student_no` varchar(20) DEFAULT NULL COMMENT '学号', `role` tinyint(1) DEFAULT '0' COMMENT '角色: 0-普通用户 1-管理员 2-超级管理员', `avatar` varchar(255) DEFAULT NULL COMMENT '头像地址', `status` tinyint(1) DEFAULT '1' COMMENT '状态: 0-禁用 1-正常', `create_time` datetime DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间', PRIMARY KEY (`id`), UNIQUE KEY `uk_username` (`username`) ) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8mb4 COMMENT='用户表'; -- 失物表 CREATE TABLE `tb_lost` ( `id` bigint(20) NOT NULL AUTO_INCREMENT COMMENT '主键ID', `user_id` bigint(20) NOT NULL COMMENT '发布人ID', `title` varchar(100) NOT NULL COMMENT '标题', `description` text COMMENT '详细描述(物品特征/颜色/品牌等)', `lost_location` varchar(100) DEFAULT NULL COMMENT '丢失地点', `lost_time` datetime DEFAULT NULL COMMENT '丢失时间', `image` varchar(500) DEFAULT NULL COMMENT '物品图片(可多个逗号分隔)', `status` tinyint(1) DEFAULT '0' COMMENT '状态: 0-待匹配 1-匹配中 2-已找回 3-已下架', `view_count` int(11) DEFAULT '0' COMMENT '浏览量', `create_time` datetime DEFAULT CURRENT_TIMESTAMP COMMENT '发布时间', PRIMARY KEY (`id`), KEY `idx_user_id` (`user_id`), KEY `idx_status` (`status`), KEY `idx_lost_location` (`lost_location`) ) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8mb4 COMMENT='失物表';

剩余几张表的SQL，建议你参考上面的注释风格。招领表结构与失物表基本对称，认领申请表需要额外包含type、target_id、description、status。这里要特别说的是，表引擎一定要用InnoDB，字符集用utf8mb4而不是utf8。原因很简单：InnoDB支持事务和行级锁，数据一致性才有保障，而且utf8mb4能完整支持emoji这种四字节字符，用户填个表情符号进来你不会被坑。

2.3 索引设计的重要性

这个细节我觉得值得单独拎出来讲，因为真的很多同学不重视。你在lost_location上建索引，是因为“按地点搜索”是失物招领系统最高频的查询场景之一。你在status上建索引，是因为列表页默认只查“待匹配”或“待认领”状态的数据。

索引不是建得越多越好。每张表额外建索引意味着写操作要维护索引树，占用存储空间。对于这种小体量毕设项目，合理建索引，比如主键加上一两个高频查询字段的普通索引就够了。答辩时你可以主动提一句“我对常用的查询字段建立了索引，经过测试查询速度可以控制在XX毫秒以内”，这种细节往往能给老师留下好印象。

3. 后端核心接口设计与实现

3.1 统一返回结果与异常处理

前后端分离项目里，接口返回的统一格式是底线。你如果接口一会儿返回{code: 200, data: xxx}，一会儿又直接返回裸数据，那前端处理起来就是灾难。我建议你封装一个统一返回类：

@Data public class Result<T> { private Integer code; // 状态码: 200成功, 500失败, 401未登录, 403无权限 private String message; // 提示信息 private T data; // 数据 public static <T> Result<T> success(T data) { Result<T> result = new Result<>(); result.setCode(200); result.setMessage("操作成功"); result.setData(data); return result; } public static <T> Result<T> error(String message) { Result<T> result = new Result<>(); result.setCode(500); result.setMessage(message); return result; } }

配合全局异常处理器，用@RestControllerAdvice拦截业务异常、参数校验异常、空指针异常等，统一转成Result格式返回。这样前端拿到code后，只需要判断一次，就能决定是展示数据还是弹出错误提示。

3.2 JWT鉴权机制详解

接口要保护，尤其是发布、修改、认领这些需要登录后才能执行的操作。JWT是目前最常见的无状态鉴权方案，它的核心思路是：用户登录成功后，后端生成一个带签名和过期时间的Token返回给前端，前端后续请求在HTTP头中携带这个Token，后端通过拦截器验证Token合法性，从而识别用户身份。

在后端，你需要一个拦截器：

@Component public class JwtInterceptor implements HandlerInterceptor { @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { // 放行登录注册等公开接口 if (request.getRequestURI().contains("/login") || request.getRequestURI().contains("/register")) { return true; } // 从Header中取出Token String token = request.getHeader("Authorization"); if (StringUtils.hasText(token) && token.startsWith("Bearer ")) { token = token.substring(7); try { // 解析Token，若过期或非法会抛出异常 Claims claims = JwtUtil.parseToken(token); request.setAttribute("userId", claims.get("userId")); return true; } catch (Exception e) { throw new BusinessException(401, "登录已过期，请重新登录"); } } throw new BusinessException(401, "未登录"); } }

这个设计里有几个细节值得留意：Token过期时间不要设置太长，我建议2小时，并配合前端路由守卫在登录状态失效时跳回登录页。在拦截器中解析出来的userId，后续Controller可以通过@RequestAttribute直接获取，不要在业务代码里再解析一遍Token。

3.3 分页查询与多条件筛选

失物/招领列表页需要支持分页、按状态筛选、按关键词搜索、按时间排序。这个功能看着简单，但实现方式却能体现你的技术水平。推荐用MyBatis-Plus的分页插件，配合LambdaQueryWrapper构建查询条件：

public PageResult<LostVO> queryLostPage(LostQueryDTO dto) { Page<Lost> page = new Page<>(dto.getPageNum(), dto.getPageSize()); LambdaQueryWrapper<Lost> wrapper = new LambdaQueryWrapper<>(); // 按标题或描述模糊搜索 if (StringUtils.hasText(dto.getKeyword())) { wrapper.and(w -> w.like(Lost::getTitle, dto.getKeyword()) .or().like(Lost::getDescription, dto.getKeyword())); } // 按状态筛选 if (dto.getStatus() != null) { wrapper.eq(Lost::getStatus, dto.getStatus()); } // 按丢失地点筛选 if (StringUtils.hasText(dto.getLocation())) { wrapper.like(Lost::getLostLocation, dto.getLocation()); } wrapper.orderByDesc(Lost::getCreateTime); Page<Lost> result = lostMapper.selectPage(page, wrapper); // 再关联查询用户表，组装VO返回 return convertToPageResult(result); }

这里要注意，前端传递关键词时，如果是空字符串，后端必须做空值判断，否则like条件会带上一个空串查询，影响性能。另一个隐藏问题是模糊搜索时如果关键词中包含%或_这两个SQL通配符，需要做转义处理，否则会出现意外的匹配结果。这个点可以作为你和同学交流技术时的一个小谈资，也是能体现工程经验的地方。

3.4 文件上传与静态资源映射

失物/招领物品的图片上传是很多同学容易卡住的环节。关于图片存储，方案就两种：本地存储或对象存储。我建议毕设阶段用本地存储，简单直接。

本地存储需要做两件事：上传接口接收MultipartFile并保存到服务器磁盘，和配置静态资源映射，让访问URL能映射到磁盘路径。

@PostMapping("/upload") public Result<String> upload(@RequestParam("file") MultipartFile file) { if (file.isEmpty()) { return Result.error("请选择文件"); } // 生成唯一文件名, 避免覆盖和中文乱码 String originalFilename = file.getOriginalFilename(); String suffix = originalFilename.substring(originalFilename.lastIndexOf(".")); String fileName = UUID.randomUUID().toString().replace("-", "") + suffix; // 配置的磁盘路径, 例如: D:/lost-found/upload/ String uploadPath = fileProperties.getPath(); File dest = new File(uploadPath + fileName); if (!dest.getParentFile().exists()) { dest.getParentFile().mkdirs(); } file.transferTo(dest); // 返回可访问的URL路径 return Result.success("/upload/" + fileName); }

这里有个经验之谈：文件名一定要用UUID重命名，不要保留原文件名。原因有二：第一，中文文件名会导致URL编码问题，前端展示图片时经常裂开；第二，保留原名容易造成同名文件互相覆盖。另外一个容易被忽略的是，上传接口要限制文件大小，SpringBoot中可以在application.yml里配置spring.servlet.multipart.max-file-size: 5MB，避免有人上传超大文件撑爆磁盘。

4. 前端核心实现与交互细节

4.1 前端请求封装与路由守卫

前端这一侧，我把核心问题放在Vue框架的整合应用上。首先，封装request.js作为统一的Axios实例，设置基础URL，加请求拦截器携带Token，加响应拦截器统一处理业务状态码：

import axios from 'axios' import router from '@/router' const request = axios.create({ baseURL: '/api', timeout: 10000 }) // 请求拦截器: 附加Token request.interceptors.request.use(config => { const token = localStorage.getItem('token') if (token) { config.headers.Authorization = 'Bearer ' + token } return config }) // 响应拦截器: 统一处理错误 request.interceptors.response.use( response => { const res = response.data if (res.code === 200) { return res } else { if (res.code === 401) { // 登录过期，清除本地凭证，跳转登录页 localStorage.removeItem('token') router.push('/login') } return Promise.reject(new Error(res.message)) } }, error => { return Promise.reject(error) } ) export default request

路由守卫方面，Vue Router的beforeEach全局前置守卫，检查要跳转的路由是否在requiresAuth白名单中，不在白名单且本地没有Token，就重定向到登录页。同时可以在守卫中动态设置页面标题，让每个页面标签页显示对应的名称，细节感拉满。

4.2 列表页与图片预览的实现思路

失物/招领列表页是用户看到的第一屏，交互体验直接影响系统评价。我用Element UI的el-table组件展示列表数据，每个数据行做成卡片式布局，点击图片可以放大预览。这里有个实操细节：图片加载失败时需要设置备用占位图。方法是在<img>标签上加上@error事件，替换成一张默认的“暂无图片”样式。

分页配合el-pagination组件，切换页码时重新请求接口。这个过程中常见的一个坑是：表格加载数据时的loading状态没有处理好，导致用户快速切换页码时，旧数据覆盖新数据。解决方式是在发起请求前把loading置为true，finally中再置为false，防止并发请求导致的数据错乱。这个细节用上，用户体验会好很多。

4.3 认领流程的状态机设计

这条流程是系统的核心亮点，我要展开讲讲。用户在招领详情页点击“我要认领”，填写物品特征描述后提交，此时对应tb_claim记录的状态是待审核。管理员在后台看到这条申请，根据描述判断是否与失主信息匹配，点击通过或拒绝。

这里建议用状态机的方式来管理认领状态流转，避免出现“已通过的申请又变回待审核”这种逻辑混乱。定义状态流转规则：

• 待审核：提交申请后的初始状态
• 已通过（认领中）：管理员审核通过，等待线下交接
• 已完成：失主成功取回物品，确认完成
• 已拒绝：管理员驳回申请

同时，当认领申请被通过后，对应招领信息的状态需要联动变化，比如从“待认领”变为“认领中”。这种多表状态联动是答辩时的高频考点，你需要把代码逻辑用清晰的时序讲出来。

4.4 Vuex还是Pinia？状态管理怎么选

如果你的项目里有“当前登录用户信息”、“未读消息数量”、“认领申请状态变更通知”这类跨组件共享的数据，建议用状态管理统一维护。现在新项目推荐使用Pinia，它是Vue官方推荐的下一代状态管理库，API更简洁，TypeScript支持更好，而且热更新体验比Vuex舒服很多。如果你用的是Vue3版本，直接学Pinia；如果是Vue2项目，继续用Vuex即可。

这里我多说一句：很多同学学Vue的时候，容易把精力花在状态管理的高级用法上，但实际这种体量的项目，你只需要在store中存一个userInfo和token，再写几个state和action就够了。不要为了炫技引入过多概念，简约本身就是专业性。

5. 环境配置与联调部署全流程

5.1 后端环境配置

后端开发环境的核心配置是application.yml。我直接给一份参考：

server: port: 8080 spring: datasource: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://localhost:3306/lost_found?useUnicode=true&characterEncoding=utf8&useSSL=false&serverTimezone=Asia/Shanghai username: root password: yourpassword servlet: multipart: max-file-size: 5MB max-request-size: 20MB 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

有几个配置项值得特别说明：serverTimezone=Asia/Shanghai必须加，否则MySQL连接会报时区错误；map-underscore-to-camel-case设为true后，数据库字段lost_location才能自动映射到实体类的lostLocation属性；logic-delete-field开启逻辑删除配置，删除操作就变成更新操作，数据不物理删除，这在管理类系统里是标准做法。

5.2 前端跨域配置

前后端分离开发，最常遇到的第一个坑就是跨域。浏览器出于安全策略，默认禁止前端从http://localhost:8081访问http://localhost:8080接口。解决办法有两种：

第一种，前端在Vue CLI的vue.config.js中配置代理：

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

这种方式是开发环境推荐的，因为代理服务器转发请求时不存在CORS限制。第二种，后端配置跨域过滤器，允许指定前端域名访问。

5.3 前后端分工与联调节奏

项目开发过程中，我建议给计划安排好时间。第一周，画好原型图，设计数据库，完成后端所有实体类和Mapper层；第二周到第三周，集中完成后端业务接口；第四周到第五周，前端页面开发与接口联调；最后留一周时间写文档、录演示视频、准备答辩。按这个节奏走，节奏好，也不会那么累。

我观察过很多做这个题目的学生，最容易陷入的困境是“先写前端还是先写后端”的纠结。我的建议是：先定好接口文档，再并行开发。你可以用Swagger来自动生成接口文档，也可以在涉及前后端交接时，先定义好请求和响应的JSON结构，然后用Mock数据把前端页面先做出来。只要接口约定好了，前后端开发就可以同时进行，最多在联调阶段花两三天统一收口。

5.4 部署上线流程

毕设项目不一定非要部署到云服务器，但如果你能现场演示一个外网可访问的版本，那是巨大的加分项。部署流程其实不复杂：后端在服务器上装好JDK和MySQL，导入数据库脚本，用mvn package打成JAR包，nohup java -jar后台启动即可。前端npm run build生成静态文件，用Nginx托管并配置反向代理，把/api开头的请求转发到后端8080端口。

这里有一个实操细节：部署服务器上MySQL的lower_case_table_names参数如果和本地不一致，导出的SQL脚本可能遇到表名大小写找不到的问题。建议建表时统一用小写表名，彻底规避这个坑。

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

6.1 数据库连接时区导致系统时差8小时

场景：你的系统时间显示和时间真实值差8小时，新发布的数据时间对不上。

原因：MySQL连接串没设置serverTimezone=Asia/Shanghai，JDBC默认使用服务器时区，而数据库时区是UTC。

排查思路：先看数据库show variables like '%time_zone%'，再看应用日志中的错误提示。添加时区参数并重启服务后，问题基本能解决。另外，前端展示时间时建议用Day.js做格式化，避免直接输出UTC时间字符串。

6.2 前端报错401，Token失效问题

场景：用户操作几分钟后就提示“登录已过期”。

原因：JWT过期时间设置太短，或者前端请求拦截器在Token加密时未正确传递。

排查思路：先用Swagger调用接口时检查携带的Token是否能正常解析，再到前端控制台Network面板看Authorization头是否真的有值。还有一个小众但常见的问题是：后端拦截器只对/api/**生效，但前端代理路又做了重写，导致部分请求路径没匹配上拦截器。

6.3 图片上传后页面无法访问

场景：图片上传成功，返回了/upload/xxx.jpg，但前端访问时404。

原因：图片保存到了本地磁盘，但SpringBoot没有配置静态资源映射，或者映射路径与返回URL不一致。

排查思路：检查application.yml中是否配置了spring.web.resources.static-locations，确认上传目录和映射路径是否有权限访问。如果你把项目打成了JAR包运行，new File(uploadPath)会指向服务器当前用户目录，而不是项目目录，这个要注意。

6.4 页面中文乱码问题

场景：接口返回的中文在页面显示为问号或乱码。

原因：数据库连接串未指定字符集，或者数据表/字段不是utf8mb4。

排查思路：依次检查数据库连接URL的characterEncoding=utf8参数、建表语句的DEFAULT CHARSET=utf8mb4、后端响应头是否设置了Content-Type: application/json;charset=UTF-8。

6.5 分页数据重复或遗漏

场景：切换排序字段后，分页数据出现重复。

原因：ORDER BY排序字段不是唯一性字段（比如只用create_time排序，多条记录时间相同），导致排序不稳定。

排查思路：分页查询的排序字段中附带主键字段，比如ORDER BY create_time DESC, id DESC，这是非常经典的坑，很多线上项目都会遇到。

7. 答辩前的准备与项目扩展方向

7.1 系统演示流程设计

答辩现场最忌临场乱点一通。我建议你提前准备一份演示脚本，流程大概是：演示前先介绍项目背景和功能模块，然后用测试账号登录；第一站是发布一条模拟失物信息，上传图片；第二站切换到另一个账号，演示学生提交认领申请；第三站切后台账号，演示信息审核、认领审批；最后走一个完整的“发布→申请→审核→确认找回”的闭环。整个流程要提前演两遍，录屏保存，免得现场出岔子。

7.2 高频答辩问题预判

老师大概率会围绕下面几个方向发问，你先自问自答一遍：

• 为什么选SpringBoot？为什么不直接用SSM？
• 数据库表之间的关系是什么？为什么这样设计？
• 认领功能如何防止冒领？
• JWT鉴权和传统Session方案的区别？
• 如果并发量大了，系统瓶颈在哪里？
• 逻辑删除和物理删除的区别，你项目用了哪种？

这些问题不难，但如果你答不上来，前期的工作量就白秀了。我的经验是，把答案组织成一份笔记文档，每个问题用三句话讲清楚本质，然后再配一个具体的项目内的实现细节作为例证，这样老师一听就知道你是自己动手写的。

7.3 项目的扩展方向

如果时间和精力允许，你可以给这个毕设做几个加分扩展：

• 增加钉钉或企业微信通知：当有新的认领申请时，通过webhook推送给管理员，这个小功能很容易实现，但很显眼。
• 使用Elasticsearch替换MySQL中的模糊搜索：作为优化点写进论文，能体现你对搜索引擎有认知。
• 做成小程序端：基于uni-app或原生小程序，复用现有接口，让系统从Web端延伸移动端，工作量可控且效果直观。

7.4 对于源码和数据库使用的建议

最后说说源码和数据库的使用问题。网上的毕业设计源码质量参差不齐，你要学会鉴别。拿到源码后一定要做三件事：第一，数据库脚本完整执行一遍，确认能跑通；第二，理清项目结构和模块依赖，不要只做“代码搬运工”；第三，跑起来后再去改代码，把核心逻辑看透。答辩现场，老师可能随时让你现场修改功能或解释代码，只靠背是应付不了的。

我个人在实际操作中体会最深的一件事是：这类管理系统的代码数量并不大，真正的壁垒在于你把每个页面、每张表、每个接口之间的逻辑关系梳理得清清楚楚。很多同学抄的时候是这里复制一段，那里贴一块，最后代码跑起来没问题，但让他在白板上画一下数据流和业务流程图，就支支吾吾了。我强烈建议你做完之后，自己用纸画一遍整个系统的数据流转图——从用户注册登录，到发布信息，到申请认领，到管理员审核，到状态变更，每一步涉及哪张表、哪个接口、哪个页面，画清楚了，你的项目就是你的，答辩也能顺利过关。

本文还有配套的精品资源，点击获取