这个题目我太熟了。每年到毕设季，总有人被分到"XX信息管理系统"这类题目，而"走失儿童认领与登记系统"算是其中业务逻辑最完整、又天然带着公益价值的一个。它能涉及用户权限、信息审核、状态流转、文件上传、前后端交互，基本把一个JavaWeb毕设该有的考点全部覆盖了。这篇文章我就拿这个项目作为完整案例，从业务设计、技术选型、数据库设计、核心代码，到跑通项目时容易踩的坑，一条线全部拆开讲清楚。
1. 先说清楚：这个毕设系统到底长什么样
1.1 从业务痛点看系统的存在价值
走失儿童这种事，真正经历过的人才知道，时间就是一切。孩子走失后的前几个小时是最关键的，而家人能做的事情非常有限：报警、张贴寻人启事、在本地微信群转发信息。这里面的核心痛点有两个——信息分散和核实困难。
各个渠道的寻人启事格式不统一，有的是图片，有的是文字，而且发出去之后就很难更新状态，可能孩子已经找到了，旧信息还在网上继续传播。另外，如果有人看到疑似走失的儿童，想提供线索，也缺少一个标准化的入口，不知道线索该往哪里报，报了之后有没有人在跟进。
这个系统本质上就是在解决这两件事：把走失信息结构化地登记入库，让所有人能浏览；把线索上报、认领申请这些后续行为统一引导到线上流程里，每一步都有审核和留痕。对于毕业设计来说，这种"登记→审核→线索→认领→核销"的闭环业务，非常容易在论文里写出东西来，答辩也有话讲。
1.2 系统的三个核心数据容器
拆解整个系统的时候，我会建议你先抓住三张核心数据表，所有功能都是围绕它们展开的：lost_person（走失信息）、clue（寻亲线索）、claim_record（认领申请）。
打个比方，可以把这三张表理解成一个寻亲事件的生命周期。lost_person是事件的开端，一条走失信息被发布，相当于向社会发出了一个"信号"；clue是外界对这个信号的各种反馈，比如有人看到过疑似孩子，在某地出现过；claim_record则是终局阶段——有人（可能是孩子本人成年后、或者某家庭）发起了认领申请，表示"这个孩子可能是我的家庭成员"。系统要做的，就是把这三种数据管好，并且通过审核机制确保每种数据都经过人工核验，而不是任由用户随便发。
1.3 五个核心角色与权限边界
系统的用户角色我建议拆成五个：未登录游客、普通用户、信息审核员、认领审核员（也可以合成一个"管理员"角色）、超级管理员。
这里要注意，很多毕设做权限系统喜欢搞得很复杂，其实没必要。走失儿童系统最合理的做法是设置两方审核职责：发布走失信息需要审核，避免恶意或虚假信息；提交认领申请更需要审核，这是最容易出问题的地方，如果没有审核机制，任何人都能从系统里轻易带走一个孩子的线索，会出大事。
所以我对权限的建议是：游客可以浏览已发布的走失信息列表和详情，但看不到完整联系方式（脱敏）；登录用户可以发布走失报备、查看自己的发布记录、提交线索、发起认领申请；审核员负责信息审核和线索审核；管理员负责最终结案和用户管理。这个权限模型覆盖了 Spring Security 或拦截器层面的多种练习场景，答辩时被问到权限设计也不会心虚。
2. 功能清单与流程梳理：报备、寻亲、认领的完整闭环
2.1 功能模块树逐个过
系统按功能模块可以分成这么几个板块：
- 走失信息管理：走失儿童的姓名、性别、年龄、身高、体貌特征、走失时间、走失地点、照片、联系人信息。操作上支持发布、修改（审核通过前可改）、下架、审核、结案。
- 线索管理：任何注册用户都可以对某条走失信息提交线索，包括线索内容、目击时间、目击地点、联系方式。审核员审核后标记为"有效/无效"。
- 认领管理：用户提交认领申请时，需要填申请理由、与走失儿童的疑似关系、佐证材料说明。审核员审核后进入"待核验"状态，最后由管理员确认是否结案。
- 公告管理：管理员可以发布寻亲相关的公告、安全提示等资讯。
- 个人中心：查看自己发布的走失信息列表、提交的线索、认领申请的审核进度。
模块数量不多不少，每个模块都有独立的表和接口，写论文时能形成"模块设计→数据库设计→接口设计→页面实现"的完整脉络。
2.2 一条走失信息从创建到结案的完整流程
很多人做这类系统，容易把功能做成单纯的CRUD，状态没有流转，这是最大的问题。走失信息必须是有状态的，而且要能"走完流程"。
我画的流程是这样的（用文字描述，你可以照着实现）：
- 用户登录后填写走失信息表单，提交后状态为
待审核。 - 审核员在后台看到待审核列表，检查信息是否完整、照片是否清晰、描述是否合理，点击通过或驳回。通过后状态变为
寻亲中，对外可见；驳回则填写原因，用户可以在原记录基础上修改后重新提交。 - 公众浏览信息时，看到可疑情况可以提交线索。线索统一进入待审核队列。
- 如果有人发起认领申请，系统自动关联到对应的走失信息。审核员审核通过后，双方（发布者与认领申请人）进行线下核验。
- 核验成功后，管理员在系统内执行"结案"操作，走失信息状态变为
已结案；如果核验中发现信息不符，认领申请被驳回，走失信息继续维持寻亲中状态对外公开。
这个流程看似简单，但你把它画成状态图放进论文里，占的篇幅很足，而且答辩老师一看就知道你有完整的业务思考。
2.3 流程设计时容易被忽略的两个细节
细节一：结案信息要有"结案原因"字段。因为结案不等于"一定找到了"，可能是孩子已经安全回家，也可能是信息过期需要撤回。不区分原因的话，数据就不够严谨。
细节二：用户发布走失信息后，应该允许修改和补充照片。走失时间越长，照片可能越需要更新。所以lost_person表里我建议不要只放一个photo字段，而是放一个 JSON数组或者多个照片的逗号分隔字符串，方便后续追加。
这两个细节看起来小，实际做的时候会发现它们直接影响前端组件的设计：照片是动态增减的，状态修改需要弹出原因输入框，这些都属于后端设计没做好就返工的地方。
3. 技术选型复盘：为什么Spring Boot + Vue是稳妥答案
3.1 前后端分离结构各部分职责
项目标题里写着 "springboot+vue"，这是目前JavaWeb方向毕设的主流标准答案，几乎没有之一。它的合理性在于前后端各司其职：Spring Boot 负责提供 RESTful API、业务逻辑、数据持久化、权限校验；Vue 负责页面渲染、交互逻辑、前端路由、状态管理。
运行结构是：前端开发时用npm run serve跑在 8080 端口，后端跑在 8081 或 8082；部署时前端npm run build生成本地静态文件后放入后端的src/main/resources/static目录，打成一个 jar 包运行。这样既能在开发期享受前后端分离的热更新，又能在毕业答辩时"一个jar包演示完毕"，不用现场开两个服务。
3.2 具体版本组合和各自原因
直接给你一套我实际验证过比较稳的组合：
| 技术项 | 推荐版本 | 选择理由 |
|---|---|---|
| JDK | 1.8 | 兼容性最好，学校机器和云服务器都养得起，不会有新版本语法问题 |
| Spring Boot | 2.7.x | 稳定、文档多，比3.x好配各种老项目环境 |
| MyBatis-Plus | 3.5.x | 代码生成器、分页插件、LambdaQueryWrapper 写起来极快 |
| MySQL | 8.0 或 5.7 | 多数毕设用5.7，8.0也没问题，看学校环境 |
| Vue | 2.x + Element UI | 版本老但资料多，任何报错都能搜得到；新手别冒险上Vue3 |
| Node.js | 16.x | 和Vue2的构建工具兼容性好，新版本node编译老项目有时直接报错 |
| Maven | 3.8.x | 常规选择，无特殊要求 |
如果你有一定前端基础，用 Vue3 + Element Plus + Vite 也可以，但我要提醒一句：毕设时间紧，Vue2 生态的坑已经被踩平了，Element UI 的表格、表单、上传组件案例非常多，建议求稳。
3.3 这套选型对毕业设计的特殊价值
选技术栈不能只看"能不能做出来"，还要看"论文怎么写"。Spring Boot + Vue 这个组合对毕设的产出是有直接加分的：后端按 Controller、Service、Mapper、Entity 分层，论文里天然有"系统总体设计"和"系统详细设计与实现"两个章节可写；前端按组件化拆页面，每个组件对应一个功能模块，测试章节又能分模块写测试用例。
另外Spring Boot自带Spring Security或拦截器方案、全局异常处理、参数校验、文件上传静态映射，每一个都是答辩老师爱问的考点。你在项目里只要用到其中两三个，问答环节基本不会冷场。
4. 数据库设计核心：九张表怎么撑起整个业务
4.1 用户与权限相关的表结构
数据库是整个项目的地基。我先说表数量：推荐九到十张，既有复杂度又不冗余。用户权限部分我建议设计sys_user、sys_role、user_role三张表，其中sys_user存账号、密码（BCrypt加密后的密文）、昵称、手机号、头像、状态；sys_role存角色编码和角色名；user_role做多对多关联。
有的毕设图省事，直接在sys_user里加一个role字符串字段，也不是不能用，但答辩时老师问"如果用户需要多个角色怎么办"就会卡壳。用标准的三表方案，反而能展示你懂数据库范式。
4.2 走失信息表：业务最重要的字段设计
lost_person表我建议核心字段这样设计：
- id：主键，MyBatis-Plus 雪花ID
- name：走失儿童姓名
- gender：性别
- age：走失时年龄
- height_cm：身高，存整数，方便筛选
- body_feature：体貌特征，文本
- clothing_desc：走失时衣着描述，文本
- photo_urls：照片地址，多个用逗号分隔
- lost_time：走失时间，datetime
- lost_address：走失地点，文本
- status：状态，0待审核 1寻亲中 2已结案 3已下架
- close_reason：结案原因，状态为2或3时必填
- contact_name、contact_phone：联系人或发布人信息
- create_time、update_time：时间审计字段
这里我特别想强调两个字段的设计逻辑。第一个是status，它是整个系统的业务开关，所有列表查询都要按状态过滤；第二个是close_reason，没有它，状态流转智能化程度就少了一半，论文里状态机设计也不好画。
4.3 线索、认领申请和审核记录的关联设计
clue表是重要的关联表：字段包括 id、lost_id（关联走失信息）、user_id（线索提供人）、clue_content、clue_time、clue_address、contact_phone、status（0待审核 1有效 2无效）。这里的技巧是lost_id必须建索引，因为一个走失信息可能收到几十条线索，不建索引后期查询会变慢，答辩演示时数据量一多页面上明显卡顿。
claim_record认领申请表字段：id、lost_id、user_id、relation_desc（与走失儿童的关系描述）、claim_reason（申请理由）、evidence_desc（佐证材料说明）、status（0待审核 1待核验 2已核验通过 3已驳回）、audit_comment（审核意见）、create_time。
audit_record审核记录表可以统一管理所有审核操作：id、target_type（LOST/CLUE/CLAIM）、target_id、auditor_id、audit_status、audit_comment、create_time。这张表的作用是"留痕"，答辩的时候你可以直接演示：一条信息的所有审核记录都查得出来，证明系统有操作日志概念。
4.4 数据字段上的两个隐蔽决定
第一，联系方式必须脱敏展示。列表页展示手机号时，应该只显示138****1234。实现上可以写一个脱敏工具方法，在后端直接处理，返回给前端的已经是脱敏后的数据。这个细节非常能体现公益系统的隐私意识，答辩加分点。
第二，年龄字段要能"动态变化"。走失年龄是当时填报的确定值，但用户搜"6岁走失"时，系统真正展示的应该是一个区间。所以age字段存走失时年龄没问题，但前端展示最好写成"走失时6岁"，避免歧义。如果你要做高级功能，还可以加一个lost_years计算字段，显示"已走失X年"。
5. 核心代码落地：权限、状态机与关键接口
5.1 JWT拦截器：前后端分离下的登录校验
毕业设计阶段我不建议上 Spring Security 全家桶，配置复杂、学习曲线陡，用JWT + 拦截器反而是更清晰的做法。流程是：用户登录成功后，后端生成一个JWT令牌返回给前端，前端存到 localStorage，每次请求时在 header 里带Authorization: Bearer xxx，后端拦截器解析令牌、拿到用户信息放入 ThreadLocal 后放行。
核心代码分三块：
// 登录接口：校验用户名密码后签发token public String login(String username, String password) { // 1. 查询用户 SysUser user = userService.getByUsername(username); // 2. 使用BCrypt校验密码，千万别明文比对 if (!BCrypt.checkpw(password, user.getPassword())) { throw new BizException("用户名或密码错误"); } // 3. 生成JWT，过期时间设为24小时 String token = JwtUtil.createToken(user.getId(), user.getUsername(), user.getRoleCodes()); return token; }拦截器里要做的事很明确：放行登录接口和公开查询接口，其余接口全部校验token。校验通过后，把userId放进去：
public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) { String token = request.getHeader("Authorization"); if (StringUtils.hasText(token) && JwtUtil.verify(token)) { Long userId = JwtUtil.getUserId(token); UserContext.setUserId(userId); return true; } // 未登录统一返回401 response.setStatus(401); return false; }5.2 发布走失报备的核心Service实现
发布走失信息这个接口要注意三件事：状态初始值、联系方式校验、照片处理。状态初始值直接写成0（待审核），而不是默认直接公开；前端上传的照片需要做大小和类型校验；联系方式必须是本人填写的电话，可以做简单的手机号正则校验。
ServiceImpl 大致长这样：
@Transactional public Long publishLostPerson(LostPersonCreateDTO dto, Long userId) { LostPerson entity = new LostPerson(); BeanUtils.copyProperties(dto, entity); // 初始状态：待审核 entity.setStatus(0); entity.setRegisterId(userId); // 照片是逗号分隔字符串 entity.setPhotoUrls(String.join(",", dto.getPhotoUrls())); lostPersonMapper.insert(entity); return entity.getId(); }@Transactional注解在这里必须加，虽然现在看起来只有一次插入，但后续如果加了"操作日志记录"逻辑，事务就能保证要么全成功要么全回滚。
5.3 认领审核与状态流转的并发安全写法
毕设项目并发量不高，但代码写法上要体现出"防止错误操作"的意识。审核认领申请时，不能用"查出状态→判断→更新"这种三步操作，会存在竞态问题。更稳的做法是用条件更新SQL：
// 只允许从待审核状态流转到待核验 int rows = claimRecordMapper.updateStatusByIdAndOldStatus( claimId, 1, 0, auditorId, auditComment); if (rows == 0) { throw new BizException("当前状态已被其他审核员处理，请刷新后再试"); }updateStatusByIdAndOldStatus对应的 SQL 是：
UPDATE claim_record SET status = #{newStatus}, auditor_id = #{auditorId}, audit_comment = #{auditComment}, update_time = NOW() WHERE id = #{claimId} AND status = #{oldStatus}这种写法在并发场景下只有一个人能改成功，其他人会拿到0行受影响从而得到提示。答辩老师问"如果两个人同时审核怎么办"，你直接把这个代码贴出来，比解释一堆理论管用得多。
6. 实际跑通项目的六个坑，每个都值得记笔记
6.1 跨域配置：不解决整个前端都白搭
开发环境下前端跑在 8080，后端跑在 8082，不配置跨域的话，浏览器的同源策略会直接拦掉所有请求。这是前后端分离项目第一个会遇到的问题。后端加一个跨域过滤器就行：
@Configuration public class CorsConfig { @Bean public CorsFilter corsFilter() { CorsConfiguration config = new CorsConfiguration(); config.addAllowedOriginPattern("*"); config.addAllowedMethod("*"); config.addAllowedHeader("*"); config.setAllowCredentials(true); UrlBasedCorsConfigurationSource source = new UrlBasedCorsConfigurationSource(); source.registerCorsConfiguration("/**", config); return new CorsFilter(source); } }注意addAllowedOriginPattern("*")和allowCredentials(true)的组合问题，如果只写addAllowedOrigin("*")，在携带凭证的请求下会报错，这是一个非常经典的小坑。
6.2 MyBatis-Plus雪花ID在前端的精度丢失
这个坑几乎人人都会踩。MyBatis-Plus 默认用雪花算法生成19位长度的 Long 型主键，JavaScript 的 Number 类型最多安全表示 2^53-1，也就是16位左右。前端拿到数据库的19位ID后，最后几位会变成0，然后导致详情页、编辑页跳转时ID对不上。
解决方案是在实体的 id 字段上加一个序列化注解：
@JsonSerialize(using = ToStringSerializer.class) private Long id;这样后端返回给前端的就是字符串形式，精度不会再丢。强烈建议每个实体类都要记得处理，不然后面排查起来非常费劲。
6.3 走失时间字段的JSON序列化问题
用 LocalDateTime 类型时，不配置格式化的话，前端拿到的是类似2024-05-01T12:30:00的格式，非常难看。建议在全局配置文件里加上：
spring: jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: GMT+8同时可以配合@JsonFormat(pattern = "yyyy-MM-dd HH:mm:ss", timezone = "GMT+8")双保险。注意时区问题，不设置 GMT+8 的话，数据库里的时间在展示时会差8小时，容易被误判为Bug。
6.4 图片上传后的访问路径配置
走失儿童系统里照片很关键。需要区分"上传存储"和"访问查看"两步。上传建议保存到服务器本地目录（如D:/upload/或/usr/local/upload/），返回给前端的是一个虚拟路径如/upload/xxx.jpg。然后需要在Spring Boot里配置静态资源映射：
@Configuration public class WebConfig implements WebMvcConfigurer { @Override public void addResourceHandlers(ResourceHandlerRegistry registry) { registry.addResourceHandler("/upload/**") .addResourceLocations("file:D:/upload/"); } }这里最容易踩的坑是路径分隔符：Windows下要用file:D:/upload/，Linux下要写file:/usr/local/upload/，如果写死就导致本地能跑、部署到Linux服务器就图片全挂。建议做成配置项。
6.5 Vue组件版本、Node版本的低级问题
Element UI 的 upload 组件、表格组件版本和 Vue2 匹配没问题，但如果你按照网上教程安装的是最新版Node.js，执行npm install时可能遇到 node-sass 编译失败。我现在建议用sass替代node-sass，或者干脆用低版本Node 16。这类环境问题本身不是业务逻辑问题，但会浪费你一整天的调试时间。
6.6 打包部署后接口404的路径问题
前端单独开发时接口地址写的是http://localhost:8082/api，打包后部署到后端jar包里时必须把接口前缀改成相对路径/api，否则线上环境死路一条。解决方式是统一在vue.config.js里配置代理，开发环境代理到8082，生产环境用相对路径。
module.exports = { devServer: { proxy: { '/api': { target: 'http://localhost:8082', changeOrigin: true } } } };后端接口统一用/api前缀，前端请求写/api/lost/list这种相对路径，这样本地开发和打包部署都不用改代码。
7. 从"能跑"到"能答辩"：给毕设加分的实战建议
7.1 演示脚本：让评委5分钟看懂你的系统
系统做完了，很多同学答辩时只会乱点。我建议准备一条固定的演示路线：登录普通用户账号 → 发布一条走失信息（附照片）→ 切换到审核员账号 → 通过审核 → 切换回前台看到信息已公开 → 提交一条线索 → 发起认领申请 → 管理员审核认领 → 结案 → 列表里变成已结案状态。
这条线正好把系统的状态流转完整串了一遍，每一步都有页面变化，不用多说评委就能看到系统的核心价值。演示的时候记得把网络关掉或用本地环境，尽量避开"接口突然挂掉"这种尴尬。
7.2 文档撰写：毕设论文的核心章节如何与项目对应
写论文时，第二章"需求分析"就写系统目标和功能需求，直接把章节2.1的功能模块树拿过来扩写。第三章"总体设计"画系统架构图和数据库E-R图，数据库部分就把第四章的九张表画一遍。第五章"详细设计"按模块写代码逻辑，把JWT拦截器、认领审核的条件更新SQL作为核心代码贴进去。第六章"测试"用功能测试用例表格覆盖主要的业务流程。
这么一来，每个论文章节都有实打实的项目内容对应，字数很容易达标，而且没有一句空话。
7.3 可以往哪些方向扩展
如果在基础功能之外还想做得更高分，我给三个比较可行的方向：
- 用ECharts做一个可视化大屏页面，展示走失信息的地区分布、年龄分布、状态统计。这个图表展示效果非常好，答辩开场用它先震一下评委。
- 接入地图API，在走失地点和线索地点上做地图标记，让用户直观看到信息距离自己有多远。
- 增加"相似度匹配"功能，通过年龄、身高、体貌特征、走失地点等字段做简单评分排序，自动推荐可能相关的线索给审核员。
这三个扩展方向每一个都能在论文里单独开一小节，工作量从两天到一周不等，适合学有余力的同学选做。
我最后再提醒一句：这种公益场景的系统，一定要把"审核"和"状态流转"当成重中之重来做，而不是只做一个信息发布平台。代码可以抄，流程设计必须自己想清楚。状态图跑通了，答辩问你业务逻辑的时候，你心里才真正有底气。
