【毕业设计】失物招领小程序：从信息发布到证件核验，做一套能防冒领的失物招领系统
技术栈：uni-app + Vue 3 + Element Plus + Pinia + Spring Boot 3.3.1 + MyBatis-Plus + MySQL + JWT + DeepSeek + WebSocket + 百度语音 + ECharts
功能关键词：失物发布、招领发布、信息审核、证件识别、认领核验、线索反馈、认领状态流转、积分激励、奖品兑换、AI 智能助手、即时聊天、语音消息、运营数据分析
找毕设选题的时候我翻了很久，最后把目光落在了一个特别普通、但特别真实的地方——失物招领。
起因是室友丢了他的耳机充电盒。他在三个群里各发了一条消息，又跑到宿舍楼公告栏贴了张纸条，结果三天过去，一点回音都没有。后来我们一起琢磨：失物招领这件事，难的不是"有没有人捡到"，而是信息该放在哪、认领凭什么说是你的。群里消息会沉、纸条会掉、口口相传全凭感觉；更麻烦的是，一件值钱的东西挂出来，谁都能说"是我的"，你凭什么判断？
顺着这个念头，我把题目定成了"失物招领系统"。这篇文章会把整套系统的设计思路和实现要点完整讲一遍，包括信息怎么审核、证件类物品怎么用 AI 识别并核验、积分激励怎么做、AI 助手和即时聊天怎么接进去的，希望能给同样在找选题的同学一些参考。
一、选题背景与系统定位
先把这套系统要解决的问题说清楚。
传统的失物招领大多靠三种方式：群消息、公告栏、熟人转告。问题有三个很突出：
- 信息分散：失物和招领混在聊天流里，翻不到、搜不了、也没有分类；
- 认领靠感觉：捡到的人无法判断来认领的人是不是真的失主，全凭"描述得像"；
- 没有记录：谁发布的、谁认领的、处理到哪一步，事后都查不到。
我想做的，是把这三个问题用系统的方式逐个解决：
- 信息分散 → 失物和招领分开建库，都按"发布—审核—公开"走，支持关键词、分类、地点、时间、状态多维检索；
- 认领靠感觉 → 证件类物品先走 AI 识别，认领时要求逐项填写并核验字段，达到正确率门槛才能提交申请；
- 没有记录 → 每一次发布、审核、认领、兑换都进操作日志和积分流水，全程可追溯。
系统采用前后端分离架构，一共两个角色：
| 角色 | 主要使用范围 |
|---|---|
| 用户 | 发布失物或招领信息、按条件浏览筛选、提交认领申请与线索、查看认领历史、收藏信息、查看积分与兑换奖品、使用 AI 助手与即时聊天 |
| 管理员 | 审核失物与招领信息、维护分类与公告、处理认领申请与线索、维护奖品并处理兑换、查看积分记录与操作日志、分析运营数据 |
二、技术选型与整体架构
技术选型上，我尽量让每一层都"有理由"，而不是堆名词：
| 层级 | 主要技术与职责 |
|---|---|
| uni-app 小程序端 | 基于 uni-app、Vue 3、Pinia 和 uni-ui，提供账号登录、失物/招领发布、分类筛选、地图位置、认领申请、证件验证、线索提交、收藏、积分商城、AI 对话及即时聊天等功能 |
| 管理端 | 基于 Vue 3、Vite、Element Plus、Pinia 与 ECharts，实现用户、失物、招领、分类、线索、认领、奖品、公告、积分、日志和数据分析的集中管理 |
| 服务端 | 基于 Spring Boot 3.3.1、Java 17、MyBatis-Plus、MySQL 与 JWT，提供 REST 接口、分页查询、身份解析、状态控制、文件上传和数据持久化能力 |
| 智能与实时能力 | 使用 DeepSeek 兼容接口提供流式 AI 问答与证件图片解析；通过 WebSocket 发送即时消息；集成百度语音服务实现文字转语音和语音转文字 |
有几个设计取舍想特别说明一下：
第一，为什么证件核验要放在服务端而不是小程序端。证件图片识别涉及模型调用和密钥，放在前端既不安全也不好维护。我的做法是：小程序只负责上传图片，服务端把本地图片转成 Data URL 后调用 DeepSeek 视觉模型，识别结果落库；认领时由服务端生成核验字段并逐项比对，前端只拿到"要填哪些字段"和"是否通过"。
第二，为什么 AI 问答用 SSE。DeepSeek 的接口天然适合流式输出，一问一答逐字返回的体验比等一坨结果好很多。服务端以text/event-stream持续推送生成片段，回答完整后再写入助手消息记录，保证会话历史可查。
第三，为什么即时聊天用 WebSocket 而不是轮询。失物认领是一个"等消息"的场景，发布者想第一时间知道有没有人认领，用轮询既费资源又有延迟。WebSocket 按用户 ID 维护在线连接，消息落库后直接推给双方，同时保留历史记录供离线查看。
三、数据库与核心表设计
系统围绕"信息发布 → 审核公开 → 认领核验 → 处理反馈 → 积分激励"这条主数据链来建表，核心表大致分成四组：
第一组：信息主体
- 失物信息表：物品名称、分类、丢失时间、丢失地点、经纬度、特征描述、图片、联系方式、发布人、状态、浏览次数
- 招领信息表：物品名称、分类、拾获时间、拾获地点、经纬度、特征描述、图片、联系方式、发布人、状态、浏览次数
- 物品分类表：失物与招领共用的分类维度
第二组：认领与线索
- 认领记录表：申请人、关联物品、申请说明、联系方式、证明材料、处理状态、审核人、审核时间
- 物品线索表：关联失物或招领信息、提交人、线索内容、图片、审核状态（有效/无效）
- 证件字段记录表：关联招领信息、字段名、字段值、原始识别结果，按纵表存储
第三组：积分与奖品
- 积分记录表：用户、变动值、变动类型、变动原因、关联业务标识、变动后余额
- 奖品表：奖品名称、图片、所需积分、库存、状态
- 兑换记录表：用户、奖品、所需积分、联系人、电话、地址、状态、处理时间
第四组：沟通与审计
- 聊天会话表 / 聊天消息表：会话双方、消息类型（文本/图片/语音/视频/文件）、内容、发送时间、已读状态、收藏状态
- AI 会话表 / AI 消息表：会话标题、最后更新时间、角色（用户/助手）、内容
- 操作日志表：操作用户、操作类型、操作内容、时间、IP
- 用户表：账号、密码、昵称、头像、角色、微信授权信息、积分余额
这里有个小设计我觉得挺关键：证件识别结果用纵表存（一行一个字段），而不是横表（一列一个字段）。因为证件类型不同，字段数量也不一样，纵表可以灵活扩展，核验时也方便按字段逐项比对。
四、核心功能与实现要点
4.1 失物与招领信息发布、审核和浏览
用户发布信息时填写物品名称、物品分类、发生时间、地点、特征描述、联系方式及图片，并可保存经纬度位置。失物和招领信息提交后均初始化为"待审核"状态，浏览次数从零开始；管理员审核通过后信息进入"已发布"状态，审核驳回时保存审核人、审核时间和驳回原因。小程序端支持按关键词、物品类别、地点、时间及状态检索公开信息，并在详情页展示物品描述、发布者和地点信息。
填写物品资料与图片 → 提交失物或招领信息 → 进入待审核 → 管理员审核通过或驳回 → 已发布信息进入列表与详情页 → 用户搜索、筛选、查看和收藏关键点在于审核是公开的前置条件。只有审核通过的信息才会进入公开列表，驳回的保留审核备注，整个动作链同步写操作日志，防止信息乱入或被随意改动。
4.2 证件识别、脱敏认领与信息核验
这是整套系统里我最想讲清楚的一段。针对证件类招领物品，用户上传图片后可调用证件识别接口。服务端将本地图片转换为 Data URL，并调用 DeepSeek 视觉模型提取证件类型、姓名、证件号码、性别、出生日期、地址、签发机关和有效期等字段；非空识别字段按纵表记录并与招领信息关联。认领证件时，系统先返回需要核验的字段和数量要求，申请人填写信息后由服务端逐项比对，避免仅凭物品图片直接认领。
上传证件图片 → DeepSeek 视觉模型识别 → 保存证件字段记录 → 获取认领核验字段 → 用户填写身份信息 → 比对通过后进入认领申请核验规则有三个细节值得注意：
| 核验环节 | 系统处理结果 |
|---|---|
| 证件图片解析 | 对证件图片生成结构化识别结果；无法识别的字段按空值处理，原始识别结果可随记录保存 |
| 核验字段生成 | 排除原始结果和证件类型后，根据有效识别字段生成待填写项；系统要求至少正确填写有效字段总数的 70%，结果向上取整 |
| 认领信息校验 | 字段完全一致，或文本相似度不低于 90% 时视为匹配；正确字段达到要求后才允许进入认领表单 |
为什么是 70% 而不是 100%？因为证件图有反光、有遮挡，识别本身就有误差，如果卡得太死，真实失主可能也填不对；但门槛太低又挡不住冒领。折中取 70% 并要求向上取整，既能容忍识别误差，又能挡住"随便试试"的人。
4.3 认领申请、状态处理与线索反馈
用户可对招领物品发起认领申请，也可围绕失物或招领信息提交文字和图片线索。认领记录保存申请人、关联物品、申请说明、联系方式、证明材料和处理状态。服务端在创建申请时检查同一用户是否已对同一物品存在待处理申请，防止重复提交；管理员处理申请时校验当前状态，审核通过后同步更新关联物品状态，并自动拒绝该物品的其他待处理申请。
查看物品详情 → 证件类物品先完成核验 → 提交认领说明与证明材料 → 待处理 → 管理员审核通过或拒绝 → 更新物品状态并处理同物品的其他申请发现有效线索 → 提交文字与图片 → 线索进入待处理 → 管理员标记有效或无效 → 发布者在个人记录中查看线索处理情况各主体的状态设计如下：
| 状态对象 | 状态与处理 |
|---|---|
| 失物信息 | 支持待审核、已发布、已找到、已驳回和已关闭等状态；标记已找到或关闭时会校验当前状态，避免重复或冲突操作 |
| 招领信息 | 审核通过后可公开浏览；认领申请审核通过后，关联招领信息更新为已认领 |
| 认领记录 | 支持待处理、已通过、已拒绝、已完成和已取消等状态；待处理申请可由申请人取消，已处理记录不允许重复审核 |
| 物品线索 | 线索关联失物或招领信息，保存提交人、线索内容和图片；管理员可将线索审核为有效或无效 |
这里有个容易忽略的并发一致性问题：一件物品可能有多人同时申请认领，如果不同步处理其他申请，会出现"一件东西认领给两个人"的矛盾。所以认领通过后要自动拒绝该物品的其他待处理申请。
4.4 积分激励、奖品兑换与积分记录
系统通过积分机制鼓励用户发布信息和完成认领。发布失物或招领信息时，服务端写入对应积分流水；失物标记为已找到时，为发布者增加成功归还积分；认领审核通过后，为申请人增加成功认领积分。积分记录保存变动值、变动类型、变动原因、关联业务标识和变动后的余额，用户可在小程序中查看积分明细与兑换记录。
发布失物或招领 → 写入积分流水 → 查看积分余额和奖品库存 → 填写兑换信息 → 创建待处理兑换记录并扣减积分 → 管理员处理发放 → 待处理兑换可取消并返还积分| 积分场景 | 系统处理结果 |
|---|---|
| 发布信息 | 发布失物或招领信息时分别记录"发布失物"或"发布招领"类型的积分变动，当前实现每次发布增加 15 积分 |
| 成功处理 | 失物标记已找到时增加成功归还积分；认领审核通过时增加成功认领积分，当前实现的成功认领奖励为 30 积分 |
| 奖品兑换 | 小程序依据用户积分和奖品库存控制兑换入口；兑换申请保存联系人、电话、地址、奖品和积分信息，管理员可查看并处理记录 |
| 取消兑换 | 仅待处理兑换允许取消；取消后写入返还积分流水并删除对应兑换记录 |
积分这块的设计思路是每一次变动都要有流水：变动值、类型、原因、关联业务 ID、变动后余额都记下来，这样用户能看到自己的积分是怎么来的、怎么花的，出现争议也能对账。
4.5 AI 智能助手、即时聊天与语音消息
系统提供面向失物招领场景的 AI 助手和用户间即时沟通能力。AI 助手为每位用户维护独立会话及消息记录，提问时保存用户消息，读取当前会话的历史上下文后调用 DeepSeek 模型，并以 SSE 持续返回生成片段；回答结束后保存助手消息，首次提问会以问题内容更新会话标题。即时聊天以用户 ID 建立 WebSocket 连接，消息保存成功后推送给双方并同步会话摘要。聊天支持文本、图片、语音、视频和文件等消息类型，语音内容可通过百度语音服务进行识别或合成。
创建或选择 AI 会话 → 保存用户问题 → 读取会话历史 → 调用 DeepSeek 流式生成 → SSE 返回回答片段 → 保存助手消息并更新时间与标题建立 WebSocket 连接 → 发送消息 → 消息落库 → 同步双方会话列表 → 向发送方和接收方推送消息 → 查询历史记录或收藏消息| 能力 | 实现方式 |
|---|---|
| AI 会话管理 | 会话按最后更新时间倒序展示；删除会话时同步删除其消息，保障会话与消息数据一致 |
| AI 流式问答 | 接口以text/event-stream返回模型生成片段，完整回答生成后写入助手消息记录 |
| 即时聊天 | 服务端维护在线用户连接映射，消息经 WebSocket 持久化后以 JSON 结构推送给双方；离线用户仍可通过历史记录查看消息 |
| 语音能力 | 调用百度 AI 提供短文本、长文本语音合成和语音转文字能力，生成音频保存在服务端外部资源目录中 |
消息为什么先落库再推送？因为网络不可靠，如果先推送再落库，推送失败消息就丢了。先落库保证消息一定存在，推送只是"锦上添花"，对方离线也能通过历史记录补看。
4.6 管理端维护、身份认证与操作日志
系统角色包括管理员和普通用户。用户可通过账号密码或微信授权方式登录，服务端签发 JWT 并在请求拦截器中解析用户 ID 与角色信息，写入当前请求上下文；小程序和管理端分别保存登录状态，并根据角色控制功能入口。管理端集中维护用户、分类、失物、招领、线索、认领、奖品、公告、积分、兑换、聊天及日志等业务数据，同时支持分页查询、关键字检索、审核、批量删除和 Excel 导出等操作。
用户登录 → 生成 JWT → 请求携带 Authorization → 拦截器解析用户与角色 → 前端按角色展示入口 → 业务操作写入登录日志或操作日志| 管理能力 | 系统处理结果 |
|---|---|
| 身份认证 | JWT 携带用户 ID 和角色类型；服务端拦截器统一解析身份，前端使用 Token 维持登录状态 |
| 内容与资源维护 | 管理员可维护用户、物品分类、公告、奖品及全部失物招领业务记录，并处理审核、认领和兑换事项 |
| 操作审计 | 发布、审核、关闭、标记找到、取消认领和处理认领等关键动作会记录操作用户、操作类型、内容、时间和 IP 信息 |
| 统一接口响应 | 后端通过全局响应增强返回统一数据结构，并由全局异常处理器将业务异常转换为前端可识别的提示信息 |
4.7 失物招领与积分运营数据分析
管理端基于 ECharts 展示失物招领和积分运营数据。首页看板汇总普通用户数、失物信息数、招领信息数、认领记录数、成功找回数及当日新增量，并展示近 7 天发布趋势、物品分类统计、失物/招领/认领状态分布和待处理事项。信息分析页面进一步输出近 7 天失物、招领和认领趋势，招领与认领状态分布、分类对比，以及从发布信息、申请认领、审核通过到认领完成的漏斗数据。积分分析则聚合积分发放、消费、用户积分余额、奖品兑换和兑换状态等指标。
失物、招领、认领、积分和兑换数据 → 服务端聚合统计 → 输出趋势、分布、分类对比、排行和漏斗数据 → ECharts 渲染管理端数据看板| 分析主题 | 统计维度 |
|---|---|
| 首页看板 | 普通用户、失物、招领、认领、成功找回和今日新增数量；近 7 天失物/招领发布趋势、分类统计和待处理事项 |
| 信息分析 | 失物、招领和认领的近 7 天趋势，招领与认领状态分布，物品分类对比，以及发布、申请、审核和完成环节的认领漏斗 |
| 积分分析 | 积分发放与消费、积分变动类型分布、用户积分排行、奖品兑换排行、兑换状态分布及兑换趋势 |
认领漏斗是我比较满意的设计：从"发布信息 → 申请认领 → 审核通过 → 认领完成"四个环节看转化，能直观看出哪个环节流失最多——如果申请量很大但通过率低，说明核验门槛或信息描述可能有问题。
五、界面展示
系统总览
失物招领系统登录页，验证码登录入口与"让遗失美好·重新相遇"主视觉。
用户端
首页：失物与招领分类入口、快捷发布、最新信息与 AI 助手入口集中呈现。
AI 智能助手：面向失物招领场景提问，会话按时间排序，回答流式返回。
认领：浏览可认领的招领信息，查看物品描述、发布者与地点，提交认领申请。
丢失：发布失物信息，填写物品名称、分类、时间、地点、特征、联系方式与图片。
认领历史：查看自己发起的认领申请与处理状态，跟踪从待处理到完成的过程。
个人中心：积分余额、我的收藏、我的发布、认领记录、积分商城与消息入口集中呈现。
管理端
招领信息：审核与管理用户发布的招领信息，支持检索、状态筛选与批量操作。
失物信息：管理失物信息与状态流转，记录发布时间、地点与审核结果。
认领记录：处理认领申请，审核通过后同步更新关联物品状态并处理同物品的其他申请。
线索记录：查看并标记物品线索为有效或无效，向发布者反馈处理结果。
数据分析：失物招领与积分运营看板，趋势、分布、分类对比与认领漏斗。
奖品管理：维护积分商城奖品、库存与所需积分，控制兑换入口。
兑换记录：查看并处理用户奖品兑换申请，记录联系人、电话与地址信息。
积分记录：查看积分发放与消费明细，跟踪用户积分变动与余额。
操作日志：记录发布、审核、处理认领等关键动作的操作人、类型、内容、时间与 IP。
其余功能：物品分类维护、公告管理、聊天与语音消息、登录日志（以文字清单收纳，如需更多截图可联系）。
六、这套系统适合谁
- 想做选题接地气的毕设：失物招领是校园真实场景，选题动机一句话讲得清；
- 想体现内容审核与状态流转能力的同学：信息从待审核到已发布/已驳回/已认领，每一步都有校验与日志；
- 想讲清安全核验思路的同学：证件识别 + 字段比对 + 相似度阈值，比只凭图片认领严谨得多；
- 想加AI 与实时能力的同学：DeepSeek 视觉识别与流式问答 + WebSocket 即时推送，和普通增删改查拉开差距；
- 想练积分与激励机制的同学：积分流水、奖品兑换、取消返还构成一套完整的激励账本；
- 需要数据可视化落点的场景：ECharts 趋势、分布、分类对比与认领漏斗，论文有图有数据。
七、说明
文档展示 16 张截图，需要了解更多，请联系我。
