校园失物招领系统毕设全栈实战：SpringBoot+Vue+MySQL完整实现

1. 为什么失物招领是毕设选题里的"性价比之王"

每年毕设选题季，我都要劝退一批准备做电商系统、博客系统、会议管理系统的同学——不是说这些题目不行，而是答辩老师一年要看几十个同款，疲惫感写在脸上。如果你正盯着"校园失物招领系统管理平台"这个方向犹豫，我直接给你结论：这个题目业务链路完整、角色清晰、技术点覆盖全面，工作量又不会失控，属于典型的"看起来简单、做起来有货"选题。

失物招领这个场景为什么适合做Web项目？因为它天然包含一套完整的状态流转：拾主发布招领启事、失主发布寻物启事、失主发起认领申请、拾主/管理员审核、线下交付、状态完结。这条链路上的每个节点都有明确的数据变化和页面反馈，做出来的系统不是"数据在表单里进进出出"，而是有一条能被讲明白的业务故事线。这在答辩演示时非常占便宜——你可以像讲故事一样把系统完整走一遍，而不是对着增删改查页面干巴巴地念。

这套项目的主流技术方案就是 SpringBoot + Vue + MySQL——标题里已经写得很明确。SpringBoot 负责后端接口和业务逻辑，Vue 负责前端页面和交互，MySQL 存数据。这套组合为什么是"主流中的主流"，我会在下面展开讲。本文面向三类人：准备拿它做毕设或课设的学生、想通过完整项目练手全栈开发的初学者、以及拿到源码但不知道怎么改怎么部署的"伸手党"。我会从需求拆解、数据模型、后端接口、前端交互、部署演示五个维度完整捋一遍，重点放在那些"不跑到最后一步根本发现不了"的坑上。

2. 想清楚业务再动手：需求拆解与角色边界

2.1 失物招领的本质不是发帖，是"匹配与确认"

很多同学拿到题目第一反应是：这不就是个信息发布平台吗？前台发帖、后台删帖，完了。如果你真这么理解，做出来的东西答辩时一问就倒——"两个人都申请认领同一件物品怎么办？""失主怎么证明东西是自己的？""物品已经被领走了还挂在首页怎么办？"

真实的校园失物招领闭环比"发帖"复杂一层。它本质上解决的是信息不对称：拾到东西的人不知道失主是谁，丢失东西的人不知道物品在哪。平台的价值是让两边信息碰头，然后通过认领申请 + 特征描述 + 人工审核这个机制来确认归属权。站在用户角度，核心诉求是"快速找到自己的东西"；站在管理员角度，核心诉求是"保证认领过程不出纠纷"。

我把完整流程梳理成下面这条链，你们照着这条链去设计功能就不会跑偏：

• 拾主发布招领启事，填标题、分类、地点、时间、图片、特征描述；
• 失主发布寻物启事，同样填详细信息；
• 失主在招领大厅搜索、筛选，看到疑似自己的物品后发起认领申请，写清楚自己的特征描述和联系方式；
• 拾主或管理员查看申请，比对特征描述，通过或驳回；
• 通过后双方线下交付，系统里物品状态置为"已完结"；
• 管理员对整个流程有监督权，可以下架违规或长期未处理的启事。

2.2 角色与功能清单：先画表格再写代码

我强烈建议你不要一上来就建表。先花半小时把角色和功能列清楚，后面能避免大量返工。一套标准的校园失物招领系统，功能边界长这样：

这里有个经验：功能范围一定要克制。毕设不是越复杂越好，而是"够用且完整"。站内私信、消息实时推送、多级审批这些，除非你基础很好且确实能驾驭，否则别碰。把上面表格这条主链路做得扎实、做得闭环，就已经超过大半数的同期项目了。我见过太多人一上来就想做"高并发秒杀""分布式缓存"，结果论文写不明白、答辩讲不清楚，最后反而不如老老实实把CRUD做透的同学。

2.3 SpringBoot + Vue + MySQL 这套选型好在哪

这年头毕设技术栈五花八门，有人用 Python，有人用 Go，还有人用 Node.js。那为什么 SpringBoot + Vue + MySQL 依然是绝大多数人的首选？核心原因是每一项技术都有清晰的落点，而且全是企业级主流：

• SpringBoot：相比早年的 SSM（Spring + SpringMVC + MyBatis），它通过自动装配和起步依赖把配置成本压到极低。内嵌 Tomcat、开箱即用的 Starter，让刚接触企业级开发的人可以把精力放在业务代码上，而不是跟 XML 配置文件搏斗。配合 MyBatis-Plus，单表增删改查几乎不用写 SQL。
• Vue：前端选 Vue 是因为它组件化思路清晰，单文件组件天然适合把页面拆成"列表页、详情页、表单页、后台布局"。Vue 3 + Element Plus 的组合，UI 组件开箱即用，页面观感能做出成熟后台的样子，这直接影响答辩时的印象分。
• MySQL：失物招领的数据是强关系型的——用户、启事、认领申请、分类之间全有外键逻辑，用关系型数据库最自然。MySQL 5.7 以上版本即可，不需要装任何复杂组件。

这套组合的另一个隐形好处是社区资源极其丰富。这意味着你卡在任何环节，搜索引擎一搜就是大把解决方案，不用自己在角落里debug到天亮。对时间紧张的毕业生来说，这本身就是最大的优势。

3. 数据模型是成败关键：建表、状态机与字段避坑

3.1 核心表结构：五张表撑起一条主链路

数据库设计是我在这类项目里最看重的一环。很多人表建得随意，后面写代码时反复 ALTER TABLE，改到心态崩溃。失物招领系统核心就五张表，一张都不能省，字段设计直接关系后续所有代码的写法。

用户表（user）：账号密码、昵称、电话、角色。角色字段区分学生和管理员，是权限控制的基础：

sql复制CREATE TABLE `user` (
  `id` BIGINT NOT NULL AUTO_INCREMENT COMMENT '主键',
  `username` VARCHAR(50) NOT NULL COMMENT '学号/账号',
  `password` VARCHAR(100) NOT NULL COMMENT 'BCrypt加密后的密码',
  `nickname` VARCHAR(50) DEFAULT '' COMMENT '昵称',
  `phone` VARCHAR(20) DEFAULT '' COMMENT '联系电话',
  `role` TINYINT NOT NULL DEFAULT 0 COMMENT '0-学生 1-管理员',
  `create_time` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP,
  PRIMARY KEY (`id`),
  UNIQUE KEY `uk_username` (`username`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

物品表（item）：这是整张系统的核心表，字段最多、最容易踩坑。类型区分招领/寻物，状态是整张系统最关键的字段：

sql复制CREATE TABLE `item` (
  `id` BIGINT NOT NULL AUTO_INCREMENT,
  `user_id` BIGINT NOT NULL COMMENT '发布人ID',
  `type` TINYINT NOT NULL COMMENT '1-招领 2-寻物',
  `category_id` INT DEFAULT NULL COMMENT '分类ID',
  `title` VARCHAR(100) NOT NULL COMMENT '标题',
  `description` TEXT COMMENT '详细描述，含特征信息',
  `image_url` VARCHAR(255) DEFAULT '' COMMENT '图片路径',
  `location` VARCHAR(100) DEFAULT '' COMMENT '拾获/丢失地点',
  `happen_time` DATETIME DEFAULT NULL COMMENT '发生时间',
  `status` TINYINT NOT NULL DEFAULT 0 COMMENT '0-待认领/待寻找 1-认领中 2-已完结 3-已下架',
  `view_count` INT NOT NULL DEFAULT 0 COMMENT '浏览量',
  `create_time` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP,
  `update_time` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
  PRIMARY KEY (`id`),
  KEY `idx_type_status` (`type`, `status`),
  KEY `idx_user_id` (`user_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

认领申请表（claim）：认领流程的核心载体。一个物品可能对应多条认领申请，所以必须单独建表：

sql复制CREATE TABLE `claim` (
  `id` BIGINT NOT NULL AUTO_INCREMENT,
  `item_id` BIGINT NOT NULL COMMENT '物品ID',
  `user_id` BIGINT NOT NULL COMMENT '认领人ID',
  `description` VARCHAR(500) DEFAULT '' COMMENT '认领说明，描述物品特征',
  `contact` VARCHAR(50) DEFAULT '' COMMENT '联系方式',
  `status` TINYINT NOT NULL DEFAULT 0 COMMENT '0-待审核 1-已通过 2-已驳回 3-已撤销',
  `create_time` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP,
  `update_time` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
  PRIMARY KEY (`id`),
  KEY `idx_item_id` (`item_id`),
  KEY `idx_user_id` (`user_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

辅助表还有两张：分类表（category） 存物品分类（电子设备、证件卡类、书本资料、其他等），系统配置表可以视需求决定要不要。分类表用 INSERT INTO 预置几条数据即可，不需要单独做管理页面。

这里有一个设计决策值得重点说：为什么物品和认领要拆成两张表，而不是在 item 表上加一个"认领人ID"字段？ 因为一个物品可能对应多个认领申请——三个同学都来认领同一件失物，这是完全正常的业务场景。如果你把认领人写在 item 表上，第三个同学申请时只能覆盖前一个，数据直接就乱了。一对多关系必须拆表，这是关系型数据库设计的基本功，也是答辩时极大概率被问到的问题。

3.2 状态机设计：四态物品 + 四态申请，联动规则必须闭环

后端最核心的逻辑，就是物品状态和认领申请状态怎么联动。建议在写任何业务代码之前，先在纸上把状态机和流转规则画出来，画不清楚就写代码，后面一定会返工。

物品表的状态（item.status）四个值：

• 0 待认领/待寻找：刚发布，还没被认领流程介入。招领物在等待失主来认领，寻物启事在等待拾主联系；
• 1 认领中：已存在至少一条"待审核"或"已通过"的认领申请。这个状态的作用是告诉浏览者"这件物品已经有人联系了，但还没完成交付"，避免其他人重复申请；
• 2 已完结：认领申请通过并完成线下交付，发布人或管理员手动关闭流程；
• 3 已下架：管理员审核发现问题，或者发布人主动撤回。

认领申请的状态（claim.status）四个值：

• 0 待审核：刚提交，等待拾主/管理员确认；
• 1 已通过：特征匹配，进入线下交付环节；
• 2 已驳回：特征不匹配，申请被拒绝；
• 3 已撤销：认领人自己取消了申请。

两个状态必须联动，规则我建议这样定：

1. 第一条认领申请提交时，如果物品处于"待认领"，自动变为"认领中"；物品已是"认领中"或"已完结"时，前端拦截"不能再发申请"；
2. 认领申请被驳回时，检查该物品是否还有别的"待审核"申请，如果没有，物品状态回落为"待认领"；
3. 认领申请通过时，物品保持"认领中"，线下交付完成后由发布人或管理员手动置为"已完结"；
4. 物品置为"已完结"时，所有"待审核"状态的认领申请自动驳回。

这套规则听起来细，实现上就是几个 if 判断，难点在于必须在写接口前把规则想透。好多项目翻车就翻在这里——一件物品被 A 申请后，B 还能继续申请，通过之后状态还是乱的。数据一旦乱了，演示时展示出来的系统就是"能跑但是逻辑明显不对"，答辩老师一眼看穿。

3.3 字段设计里最容易遗漏的四个细节

我见过大量第一版建表，后面反复改来改去，基本都是下面这些地方没注意：

• create_time / update_time 必须都有。update_time 用 ON UPDATE CURRENT_TIMESTAMP，改数据时自动更新，代码里不用手动维护。没有这个字段，后面做"按更新时间排序"就只能拿 create_time 凑合，效果差很多。
• 图片存路径，不是存 base64。把图片 base64 直接塞进数据库，库会迅速膨胀，查询变慢，备份体积感人。正确的做法是存图片的相对路径（如 /upload/20260601_xxx.jpg），文件本身放服务器磁盘目录。
• 字符集用 utf8mb4 而不是 utf8。utf8 在 MySQL 里存不了 emoji 和生僻字，测试数据里放个表情符号直接报错，答辩现场非常尴尬。建表时 DEFAULT CHARSET=utf8mb4 一步到位。
• 索引不要乱加，但要加在刀刃上。idx_type_status 支撑首页的"类型+状态"列表查询，idx_user_id 支撑"我的发布"查询，这两个是最高频的查询路径。其他地方先不加，等真的慢再加索引，避免写入性能被没必要的索引拖累。

4. SpringBoot后端实现：三条核心链路的代码细节

4.1 工程结构：分层清晰是答辩加分项

后端我建议用经典的分层结构，命名规范到让答辩老师一眼看出"这个人写过正经代码"。包结构长这样：

code复制com.campus.lost
├── controller        # 接口层，只做参数接收和结果返回
├── service           # 业务层，核心逻辑都在这
│   └── impl
├── mapper            # MyBatis-Plus Mapper接口
├── entity            # 数据库实体类
├── dto               # 请求/响应对象
├── config            # 配置类（CORS、静态资源映射等）
├── common            # 统一返回结果、全局异常处理、工具类
└── LostApplication.java

核心原则一句话：Controller 要薄，Service 要厚。Controller 里不应该出现超过十行的业务逻辑，像"判断物品状态、创建认领申请、更新物品状态"这些都应该收敛在 Service 方法里。这样做的直接好处是事务控制容易——Service 方法上直接加 @Transactional，就能保证多个数据库操作要么全部成功、要么全部回滚。如果业务逻辑散落在 Controller 里，事务就很难圈住边界。

4.2 登录认证：为什么推荐 JWT

毕设级别的前后端分离项目，我推荐用 JWT（JSON Web Token）做登录认证，而不是传统的 Session。理由有二：第一，JWT 无状态，不依赖服务端 Session 存储，天然适合前后端分离架构；第二，"为什么用 JWT 不用 Session"几乎是答辩必问题，你能把"token 无状态、适合分布式部署、减轻服务端存储压力"这几个点讲清楚，就是实打实的加分项。

核心流程三步：

1. 登录接口校验账号密码（密码用 BCrypt 加密存储，绝不存明文），校验通过后用 jjwt 库生成 token，把 userId 和 role 写进 token 的 payload；
2. 写一个拦截器，拦截需要登录的接口，从请求头 Authorization 字段解析 token，解析失败返回 401；
3. 解析出的 userId 放入 ThreadLocal 或 request attribute，供后续业务代码直接取用。

一个容易踩的坑是：跨域请求时自定义请求头被浏览器拦截。前端 axios 设置了 Authorization 请求头，如果后端 CORS 配置里没有显式允许这个头，浏览器会认为这是非法请求直接拦掉。CORS 配置里 allowedHeaders("*") 必须有。这个我放到联调章节细讲。

4.3 图片上传：本地存储的一套完整方案

毕设项目不需要上对象存储（除非你想拿"云存储集成"当创新点），本地磁盘存储完全够用。但"本地存储"四个字背后有非常多细节，我一个个说：

第一步：配置静态资源映射。 SpringBoot 默认只处理 classpath 下的 /static、/public 目录，我们通常把上传文件放项目外的独立目录，再用配置映射成 URL：

yaml复制# application.yml
spring:
  servlet:
    multipart:
      max-file-size: 5MB
      max-request-size: 10MB

app:
  upload-dir: /var/www/lost/images   # 自定义配置项

java复制@Configuration
public class WebConfig implements WebMvcConfigurer {

    @Value("${app.upload-dir}")
    private String uploadDir;

    @Override
    public void addResourceHandlers(ResourceHandlerRegistry registry) {
        // 将 /upload/** 映射到本地磁盘目录
        registry.addResourceHandler("/upload/**")
                .addResourceLocations("file:" + uploadDir + "/");
    }
}

注意 addResourceLocations 里的路径必须以 file: 开头，且结尾必须带 /，否则映射不生效。这个细节我从踩坑到记住花了不少时间。

第二步：写上传接口。 代码本身不复杂，但有几个安全习惯必须养成：

java复制@PostMapping("/api/file/upload")
public Result<String> upload(@RequestParam("file") MultipartFile file) {
    if (file.isEmpty()) {
        return Result.error("文件不能为空");
    }

    // 1. 后缀白名单校验，防止上传可执行文件
    String originalFilename = file.getOriginalFilename();
    String ext = StringUtils.getFilenameExtension(originalFilename);
    Set<String> allowExt = new HashSet<>(Arrays.asList("jpg", "jpeg", "png", "gif", "webp"));
    if (!allowExt.contains(ext.toLowerCase())) {
        return Result.error("不支持的文件类型");
    }

    // 2. 重命名文件，避免中文名乱码、重名覆盖
    String newName = System.currentTimeMillis() + "_" 
                     + UUID.randomUUID().toString().replace("-", "") + "." + ext;

    // 3. 保存到磁盘
    File dest = new File(uploadDir + "/" + newName);
    file.transferTo(dest);

    // 4. 返回可访问的相对路径
    return Result.success("/upload/" + newName);
}

三个关键点：文件名必须重命名（中文名可能乱码、重名直接覆盖前一张图）、后缀必须白名单校验（这是基础的安全意识）、返回相对路径而不是绝对路径（这样换服务器部署时前端不用改代码）。

4.4 发布与认领接口：事务、重复提交与状态联动

发布启事比较简单——一个 insert 加浏览量归零。认领申请接口才是重点，因为这里涉及事务边界和重复提交两个问题。用 MyBatis-Plus 写认领接口的核心逻辑：

java复制@Transactional(rollbackFor = Exception.class)
@Override
public Result<Void> createClaim(Long itemId, ClaimDTO dto) {
    Long userId = CurrentUserHolder.getUserId();

    // 1. 物品必须存在
    Item item = itemMapper.selectById(itemId);
    if (item == null) {
        return Result.error("物品不存在");
    }

    // 2. 不能认领自己发布的启事
    if (item.getUserId().equals(userId)) {
        return Result.error("不能认领自己发布的启事");
    }

    // 3. 物品状态校验：只有"待认领"或"认领中"可申请
    if (item.getStatus() == 2 || item.getStatus() == 3) {
        return Result.error("该启事已完结或已下架");
    }

    // 4. 防止重复申请
    Long count = claimMapper.selectCount(
        new LambdaQueryWrapper<Claim>()
            .eq(Claim::getItemId, itemId)
            .eq(Claim::getUserId, userId)
            .ne(Claim::getStatus, 3)   // 已撤销的不算
    );
    if (count > 0) {
        return Result.error("你已经申请过这个物品");
    }

    // 5. 插入认领申请
    Claim claim = new Claim();
    claim.setItemId(itemId);
    claim.setUserId(userId);
    claim.setDescription(dto.getDescription());
    claim.setContact(dto.getContact());
    claim.setStatus(0);
    claimMapper.insert(claim);

    // 6. 物品状态联动：待认领 -> 认领中
    if (item.getStatus() == 0) {
        Item update = new Item();
        update.setId(itemId);
        update.setStatus(1);
        itemMapper.updateById(update);
    }

    return Result.success();
}

@Transactional 保证第 5、6 步任何一步失败都整体回滚，数据库不会出现"申请建了但物品状态没变"的半截数据。关于并发问题——严格来说，同一时刻两个请求都查到 count=0 然后都插入成功的理论风险是存在的，但毕设的数据量根本触发不了。答辩时你可以主动说一句："如果考虑到高并发重复提交，可以在 item 表加乐观锁版本号，或者对 claim 表加联合唯一约束作为兜底。"主动说出改进方案，远比被动被老师追问要从容。

4.5 审核接口：驳回后状态回落的联动逻辑

管理员的审核接口，核心就是把状态机里的第 2 条规则落地——驳回申请后检查是否还有别的待审核申请，没有就让物品状态回落为"待认领"：

java复制@Transactional(rollbackFor = Exception.class)
@Override
public Result<Void> auditClaim(Long claimId, Integer status) {
    Claim claim = claimMapper.selectById(claimId);
    if (claim == null) {
        return Result.error("申请不存在");
    }
    if (claim.getStatus() != 0) {
        return Result.error("该申请已审核过");
    }

    Item item = itemMapper.selectById(claim.getItemId());

    if (status == 1) { // 通过
        claim.setStatus(1);
        claimMapper.updateById(claim);
    } else if (status == 2) { // 驳回
        claim.setStatus(2);
        claimMapper.updateById(claim);

        // 关键联动：没有其他待审核申请时，物品状态回落
        Long pendingCount = claimMapper.selectCount(
            new LambdaQueryWrapper<Claim>()
                .eq(Claim::getItemId, item.getId())
                .eq(Claim::getStatus, 0)
        );
        if (pendingCount == 0 && item.getStatus() == 1) {
            Item update = new Item();
            update.setId(item.getId());
            update.setStatus(0);
            itemMapper.updateById(update);
        }
    }
    return Result.success();
}

这段逻辑写起来不难，但必须闭环。我见过一个项目，驳回申请后物品一直停在"认领中"，首页物品状态显示"有人联系"，实际根本没人认领了——这就是状态联动漏了，答辩演示时一操作就露馅。

5. Vue前端落地：用户大厅与管理后台的交互实现

5.1 工程初始化和目录规划

前端我用 Vue 3 + Vite + Element Plus。Vite 相比 Vue CLI 启动速度快很多，组合式 API 写业务逻辑也更顺手。目录规划：

code复制src/
├── api/            # 接口请求封装
├── router/         # 路由配置
├── store/          # Pinia 状态管理（登录态）
├── views/          # 页面
│   ├── home/       # 招领大厅、寻物大厅
│   ├── item/       # 启事详情、发布页
│   ├── claim/      # 认领申请相关
│   ├── user/       # 个人中心
│   └── admin/      # 管理后台
├── components/     # 公共组件
├── utils/          # 工具函数
└── App.vue

5.2 路由守卫：前端控制只是体验优化，真正的权限在后端

路由要区分"游客可访问""登录后可访问""仅管理员可访问"三类。Vue Router 全局前置守卫是标准做法：

javascript复制// router/index.js
router.beforeEach((to, from, next) => {
  const token = localStorage.getItem('token');
  const role = Number(localStorage.getItem('role'));

  if (to.meta.requiresAuth && !token) {
    next({ path: '/login', query: { redirect: to.fullPath } });
    return;
  }

  if (to.meta.requiresAdmin && role !== 1) {
    next({ path: '/' });
    return;
  }

  next();
});

这里有一个答辩时一定会被追问的点，你必须能说清楚：前端路由守卫只是体验优化，不是安全边界。用户手动改路由、改 localStorage 都能绕过前端的阻挡，真正的权限控制必须依赖后端接口拦截——没有 token 后端直接拒绝返回 401，没有管理员角色后端拒绝返回 403。前端挡住的是"正常用户乱点乱逛"，后端挡住的是"恶意请求和越权操作"。这句话讲明白了，权限设计这个考点就过关了。

5.3 Axios 封装：统一鉴权、统一报错、统一返回

我习惯把 axios 实例单独封装，所有请求统一走它。好处是整个项目的请求逻辑收敛在一个文件里，改一处全局生效：

javascript复制// api/request.js
import axios from 'axios';
import { ElMessage } from 'element-plus';
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 = token;
  }
  return config;
});

// 响应拦截器：统一处理业务码和 HTTP 错误
request.interceptors.response.use(
  (response) => {
    const res = response.data;
    if (res.code !== 200) {
      ElMessage.error(res.msg || '请求失败');
      return Promise.reject(new Error(res.msg));
    }
    return res.data;
  },
  (error) => {
    if (error.response?.status === 401) {
      ElMessage.error('登录已过期，请重新登录');
      localStorage.removeItem('token');
      router.push('/login');
    } else {
      ElMessage.error(error.message || '网络错误');
    }
    return Promise.reject(error);
  }
);

两个细节值得注意：响应拦截器里把 res.data 直接返回，业务代码里就不用写 .then(res => res.data.data) 这种套娃了；401 统一跳登录，token 失效时不会在页面里冒出一个个乱糟糟的报错弹窗。

5.4 发布页：el-upload 必须手动带请求头

发布页是用户端最核心的交互页面。Element Plus 的 el-upload 配后端图片上传接口，整个表单流程很顺，但有一个坑必须提醒：

vue复制<template>
  <el-form ref="itemFormRef" :model="form" :rules="rules" label-width="90px">
    <el-form-item label="类型" prop="type">
      <el-radio-group v-model="form.type">
        <el-radio :value="1">招领启事</el-radio>
        <el-radio :value="2">寻物启事</el-radio>
      </el-radio-group>
    </el-form-item>

    <el-form-item label="标题" prop="title">
      <el-input v-model="form.title" placeholder="例如：蓝色钱包，校园卡夹层" />
    </el-form-item>

    <el-form-item label="分类" prop="categoryId">
      <el-select v-model="form.categoryId" placeholder="请选择分类">
        <el-option label="电子设备" :value="1" />
        <el-option label="证件卡类" :value="2" />
        <el-option label="书本资料" :value="3" />
        <el-option label="其他" :value="4" />
      </el-select>
    </el-form-item>

    <el-form-item label="地点" prop="location">
      <el-input v-model="form.location" placeholder="例如：图书馆三楼" />
    </el-form-item>

    <el-form-item label="详细描述" prop="description">
      <el-input v-model="form.description" type="textarea" :rows="4"
                placeholder="请描述物品特征，便于匹配认领" />
    </el-form-item>

    <el-form-item label="图片">
      <el-upload
        action="/api/file/upload"
        :headers="{ Authorization: token }"
        :on-success="handleUploadSuccess"
        :limit="1"
      >
        <el-button>上传图片</el-button>
      </el-upload>
    </el-form-item>

    <el-form-item>
      <el-button type="primary" @click="submitForm">发布</el-button>
    </el-form-item>
  </el-form>
</template>

这里最容易被忽略的，就是 el-upload 的 :headers 属性。上传组件发的是独立请求，不会自动经过 axios 实例的拦截器，所以不会自动携带 Authorization 请求头。如果你不手动在 :headers 里带上 token，后端拦截器会把上传请求当作未登录直接拒绝，表现就是"其他接口都正常，就图片上传一直 401"。这个坑我至少见到三个同学踩过，务必牢记。

6. 联调、部署与答辩现场：最后一步才暴露的坑

6.1 跨域：开发环境用代理，一劳永逸

本地开发时前端跑 5173 端口（Vite 默认），后端跑 8080，端口不同必然触发跨域。最快的解决方案是 Vite 代理，开发环境完全不需要后端配 CORS：

javascript复制// vite.config.js
export default defineConfig({
  server: {
    port: 5173,
    proxy: {
      '/api': {
        target: 'http://localhost:8080',
        changeOrigin: true,
      },
    },
  },
});

前端请求 /api/xxx 会被代理转发到后端 8080，浏览器看到的是同源请求，跨域问题消失。但注意：el-upload 组件里的 action 属性如果你写成绝对地址 http://localhost:8080/api/file/upload，就会绕过代理直接请求后端，跨域问题又回来了。所以统一用相对路径 /api/file/upload，让代理统一处理。

如果你不想用代理（比如后端已经部署到服务器了，前端要直连），那就在后端配 CORS：

java复制@Configuration
public class CorsConfig implements WebMvcConfigurer {
    @Override
    public void addCorsMappings(CorsRegistry registry) {
        registry.addMapping("/**")
                .allowedOriginPatterns("*")
                .allowedMethods("GET", "POST", "PUT", "DELETE", "OPTIONS")
                .allowedHeaders("*")
                .allowCredentials(true)
                .maxAge(3600);
    }
}

allowedHeaders("*") 必须保留，否则 Authorization 自定义请求头会被浏览器拦掉。allowCredentials(true) 和 allowedOriginPatterns("*") 要配合使用，如果你写 allowedOrigins("*") 加 allowCredentials(true)，部分浏览器会直接报错拒绝。

6.2 部署三板斧：打包、初始化、连接配置

前端打包。 npm run build 生成 dist 目录。如果你希望一个 jar 包搞定全部（前端页面和后端接口都在一个服务里），把 dist 里的内容拷到 src/main/resources/static 目录下，再重新打 jar。这样访问后端地址就能直接看到页面，部署最简单，适合答辩演示。缺点是每次改前端都要重新打包，但对毕设来说完全不是问题。

数据库初始化。 强烈建议准备一个 init.sql，把建表语句和测试数据都放进去。这样无论换了电脑、清了数据库，执行一遍就能恢复。这里多说一句：测试数据一定要用心准备——20 条左右的启事、覆盖不同分类、不同状态、包含几条已完结的，页面一打开信息量饱满，观感立刻不一样。空表页面会让人质疑系统的完整度。

MySQL 连接配置。 三个参数一个都不能省：

yaml复制spring:
  datasource:
    url: jdbc:mysql://localhost:3306/lost_find?useSSL=false&serverTimezone=Asia/Shanghai&characterEncoding=utf8mb4
    username: root
    password: 你的数据库密码

serverTimezone=Asia/Shanghai 必须配，否则新版 MySQL 驱动会因为时区问题直接报错；characterEncoding=utf8mb4 保证中文不乱码；如果密码里有 @、#、& 这类特殊字符，记得做 URL 编码，否则连不上库还半天找不到原因。

6.3 答辩演示的翻车黑名单

这些年见过的、自己踩过的演示事故，整理成表给你对照排查：

6.4 源码二次开发与答辩"创新点"的三个方向

如果你拿到的是一套基础源码，想让它更有竞争力，我建议从下面三个方向里挑一个做深：

第一，失物匹配推荐。 根据用户发布的寻物启事，自动匹配标题、分类、描述里关键词相近的招领启事，在用户端首页展示"猜你想找"。实现方案可以很务实：后端用 MySQL 的 LIKE 模糊查询或者简单的关键词分词做相似度计算，前端在首页加一个"智能匹配"区块。这个功能业务上非常合理——失物招领的核心价值就是"匹配"，比做一堆花哨页面实在得多。

第二，数据可视化看板。 管理员后台加统计页面，用 ECharts 展示失物分类占比、各地点丢失数量排行、每日发布趋势、完结率等指标。数据来源就是业务表的基础聚合查询，工作量和难度都可控，但演示效果和论文篇幅都能显著加分。

第三，通知机制。 认领申请通过后给申请人和发布人发提醒。如果不想接短信服务，可以在站内做"我的消息"或者邮件通知（用 Spring Boot 的 JavaMailSender）。这个功能补全了"线下交付"前后的信息传递闭环，逻辑上也更完整。

这三个方向都有同一个特点：从业务痛点出发，而不是从技术炫技出发。答辩时讲"为什么要做这个功能"比讲"我用了什么技术"更能打动老师。

最后说点个人体会。失物招领这个选题，最大的好处是它的业务闭环完整——从发布到认领再到完结，每一步都有明确的数据变化和界面反馈，特别适合在几分钟的演示里讲出完整故事。但它也最容易做成"半吊子"：要么只做了发布和展示，认领流程一笔带过；要么状态逻辑东拼西凑，一问就露馅。这篇文章里写的表结构、状态机、接口逻辑、前端交互和部署步骤，都是围绕"让这套系统真正能跑起来，并且能被你讲清楚"来组织的。

如果你正在改一套别人的源码，我的建议是：先别急着动手改代码，把那套状态流转规则在脑子里过一遍——物品和申请的状态各自怎么变、谁触发谁、异常情况怎么兜底——然后在源码里对照着找：发布接口在哪、认领接口在哪、审核接口在哪，状态是怎么变的。搞清楚了再动手，你会发现改起来顺非常多。如果你卡在部署或者联调环节，大概率是 6.3 表里那些坑，逐个排查基本都能解决。祝答辩顺利。