校园失物招领系统设计与实现：Spring Boot+MyBatis全流程开发

毕业设计的题目和说明文档往往是两回事，尤其是这种“XX系统的设计与实现”，看着挺简单，真正做起来坑不少。这次拿到的课题是“基于Web的校园失物招领系统的设计与实现-计算机毕业设计源码45894”，核心就是一套面向高校场景的失物招领Web应用。结合开发这类系统时普遍会遇到的问题——需求边界模糊、功能模块怎么划分、图片上传怎么处理、失物怎么匹配、后台怎么管理——我把整条技术路线从需求分析到部署上线拆开讲一遍，顺便把答辩时容易踩的坑一起列出来。

这篇文章适合正在做类似毕业设计、或者想用一小段时间搭建一个实际可用Web系统的同学。不管你是选Java还是Python方向，骨架思路是通用的：先把业务说清楚，再谈技术选型，然后落到代码实现。

1. 项目概述与核心需求拆解

1.1 失物招领场景为什么需要一套系统

大学校园里丢东西是高频事件。我见过很多学校处理失物的方式停留在“朋友圈转发”“食堂窗口贴纸条”“在失物群吼一嗓子”，效率低且信息生命周期短。最典型的问题有三个：

• 招领信息发布渠道分散，没有统一的分类和检索入口；
• 学生捡到东西不知道往哪送，丢东西的人不知道去哪找；
• 管理员（比如保卫处、宿管、校学生会）无法统一审核和跟进失物状态。

所以，一个面向校园的失物招领系统的核心价值，不只是“发布信息”，而是把整个拾取、登记、审核、查询、认领、归档的闭环管理起来。这是系统设计的业务原点，所有功能模块都应该围绕这条主线展开。

1.2 需求分层：从用户故事到功能模块

动手敲代码前，先把“谁能用、用来干嘛、系统要给他什么反馈”理清楚。我习惯用用户故事来整理需求，比直接列功能清单更不容易漏细节。

以这套系统为例，核心用户故事包括：

• 作为学生（普通用户），我希望能够发布失物招领信息，录入物品名称、分类、丢失/拾取地点、描述和图片，这样别人可以快速看到。
• 作为学生，我希望能够按关键词、分类、时间、地点搜索，快速筛选出是否有我丢失的物品，减少刷屏式翻阅。
• 作为失主，我希望能够在看到招领信息后提交认领申请，并等待管理员或拾取者确认。
• 作为管理员，我希望能够审核所有发布的信息，屏蔽虚假和违规内容，并对认领流程做最终确认。
• 作为管理员，我希望能够看到系统运行的统计数据，比如每日新增失物、招领成功率、分类占比，为后续优化运营提供参考。

把这些用户故事翻译成功能模块，系统就分成了两大端：用户端和管理端。

用户端功能包括：注册登录、个人信息维护、失物发布、招领信息浏览、分类检索与关键词搜索、失物详情查看、提交认领申请、我的发布记录、我的认领记录。

管理端功能包括：用户管理、失物信息审核、认领申请审核、分类管理、公告管理、数据统计看板。

1.3 系统角色与权限边界

系统通常分三个角色：普通用户（学生）、管理员、超级管理员。权限设计不需要复杂到RBAC（基于角色的访问控制）模型，毕业设计阶段用一张角色字段加简单的拦截器判断就够了，但角色边界要提前想清楚。

我整理的权限矩阵如下：

这样一列，后端在写Controller的时候，接口是给哪个角色用的就很清晰，权限注解直接往上加即可。

2. 技术方案选型与开发环境搭建

2.1 技术栈选择的思考：Java还是Python

先回答一个被问烂但每次都有人纠结的问题：毕业设计到底用Spring Boot还是Django还是Flask？

我的建议很简单——你能把项目完整跑通、能讲清楚为什么这样选，就是好方案。但从校园失物招领系统的业务复杂度看，Spring Boot + MyBatis Plus + MySQL是当前最主流、参考案例最多、答辩老师最熟悉的组合。热词里出现了“mybatis源码”“idea2024版本创建web项目”“java web +jsp项目中前端使用js+jquery”等，说明Java方向的学习链路在Web开发中依旧非常稳固。

选择Spring Boot而不是传统的SSH（Struts+Spring+Hibernate）或SSM（Spring + Spring MVC + MyBatis）手动整合，核心原因是Spring Boot帮我省掉了大量XML配置。内嵌Tomcat让部署变成“一个jar包搞定”，这在做毕业设计时能节省至少一个星期的环境配置时间，而这部分工作本身对能力提升的作用非常有限。

如果你主攻Python，Django的Admin后台天然适合做管理端，Django REST Framework写接口也很方便，同样是合理选择。本文以Java技术栈展开，但业务模块设计思路完全通用。

2.2 前后端分离与单体架构的取舍

现在的Web系统，绕不开“前后端分离”这四个字。热词里“web前端开发”“ui和web前端开发哪个好学”都表明前端在整个Web体系中的权重在上升。那么失物招领系统要不要用Vue + Spring Boot搞成前后端分离？

我建议分两种情况：

• 如果你的目标是求稳交差：选 Thymeleaf（或JSP）+ Bootstrap + jQuery 的单体架构。后端返回页面，前端用jQuery做局部刷新，项目结构简单，答辩时逻辑链路清晰，且一个Idea工程搞定，部署简单。
• 如果你想在简历上多写一行“熟悉前后端分离开发”：选 Vue 3 + Element Plus + Spring Boot，用JSON交互，前端npm run build后把静态资源放到后端static目录，或用Nginx反向代理。

毕业设计这个时间点，我最推荐的是单体优先、预留分离扩展的思路。也就是说，后端Controller统一返回JSON格式（为分离做铺垫），但页面用Thymeleaf渲染，尽量减少前后端沟通成本。这个折中方案在答辩时也能解释成“我为后续扩展做了接口化处理”，既稳又有亮点。

2.3 开发环境与工具链配置实录

项目编号“45894”对应的这套系统，我用的是如下环境，供你参考：

• JDK：1.8 或 11（Spring Boot 2.x 建议1.8，不折腾）
• 开发工具：IntelliJ IDEA 2024.1（热词里“idea2024版本创建web项目”指的就是这里）
• 构建工具：Maven 3.8+
• 框架：Spring Boot 2.7.x + MyBatis Plus 3.5.x
• 数据库：MySQL 8.0
• 前端：Thymeleaf + Bootstrap 5 + jQuery 3.7 + LayUI（管理端）
• 图片存储：本地磁盘

创建项目时直接在IDEA里选Spring Initializr，Group填com.campus，Artifact填lostfound，依赖勾选Spring Web、Thymeleaf、MyBatis Framework、MySQL Driver、Lombok。这里有几个容易踩坑的点：

注意：Spring Boot 3.x 要求JDK 17，如果电脑装的是JDK 8，请务必选择Spring Boot 2.7.x版本，否则项目会编译不过，这个错误经常让新手误以为是代码问题。

另外，MyBatis Plus 的starter在Spring Boot 3.x下也有兼容性差异，稳妥做法是统一用2.x体系。

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

3.1 表结构总览

数据库是失物招领系统的地基。表设计得不好，写代码的时候会处处别扭；表设计清晰，后面CRUD全是体力活。我按照业务对象拆分，一共五张核心表：用户表、失物信息表、认领记录表、物品分类表、系统公告表。

整体关系如下表所示：

3.2 用户表设计

用户表要覆盖两类信息：一是登录认证信息，二是个人通讯信息（便于失物联系）。密码绝对不许明文存储，这是答辩必考项。

sql复制CREATE TABLE `user` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT,
  `username` varchar(50) NOT NULL COMMENT '用户名',
  `password` varchar(100) NOT NULL COMMENT '密码(MD5+盐或BCrypt)',
  `salt` varchar(20) DEFAULT NULL COMMENT '盐值',
  `nickname` varchar(50) DEFAULT NULL COMMENT '昵称',
  `phone` varchar(20) DEFAULT NULL COMMENT '联系电话',
  `email` varchar(100) DEFAULT NULL COMMENT '邮箱',
  `avatar` varchar(255) DEFAULT NULL COMMENT '头像路径',
  `role` tinyint(4) DEFAULT '0' COMMENT '角色:0-普通用户 1-管理员 2-超级管理员',
  `status` tinyint(4) DEFAULT '1' COMMENT '状态:1-正常 0-禁用',
  `create_time` datetime DEFAULT NULL,
  `update_time` datetime DEFAULT NULL,
  PRIMARY KEY (`id`),
  UNIQUE KEY `uk_username` (`username`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

密码加密推荐用Spring Security的BCryptPasswordEncoder，或者工具类加盐MD5。BCrypt的优点是同一密码每次加密结果都不一样，安全性更好，答辩时可以解释一句“有效防止彩虹表攻击”，很加分。

3.3 失物信息表设计

失物信息表是整个系统的核心，字段设计决定了检索和状态流转的灵活性。我拆分了“物品基本信息”和“状态信息”两类。

sql复制CREATE TABLE `item` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT,
  `type` tinyint(4) NOT NULL COMMENT '类型:0-寻物 1-招领',
  `title` varchar(100) NOT NULL COMMENT '物品标题',
  `category_id` bigint(20) DEFAULT NULL COMMENT '分类ID',
  `description` text COMMENT '详细描述',
  `place` varchar(100) DEFAULT NULL COMMENT '丢失/拾取地点',
  `lost_time` datetime DEFAULT NULL COMMENT '丢失/拾取时间',
  `contact_person` varchar(30) DEFAULT NULL COMMENT '联系人',
  `contact_phone` varchar(20) DEFAULT NULL COMMENT '联系电话',
  `images` varchar(1000) DEFAULT NULL COMMENT '图片路径,多图用逗号分隔',
  `status` tinyint(4) DEFAULT '0' COMMENT '状态:0-待审核 1-发布中 2-认领中 3-已找回 4-已关闭 5-审核驳回',
  `publish_user_id` bigint(20) DEFAULT NULL COMMENT '发布人ID',
  `claim_user_id` bigint(20) DEFAULT NULL COMMENT '认领人ID',
  `audit_remark` varchar(255) DEFAULT NULL COMMENT '审核意见',
  `create_time` datetime DEFAULT NULL,
  `update_time` datetime DEFAULT NULL,
  PRIMARY KEY (`id`),
  KEY `idx_status` (`status`),
  KEY `idx_type` (`type`),
  KEY `idx_category` (`category_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

这里有两个细节值得注意：

• images字段用逗号分隔存多个图片路径，是典型的“反规范化”设计，省一张子表，在图片数量少（3张以内）的场景下完全没有问题，还省了一次连表查询。这个思路在答辩时可以主动讲出来，说明你思考过表设计取舍。
• status状态字段用整型并非字符串，更省空间，条件查询也更快。配合状态机流转，后续在代码里维护一个状态数组即可。

3.4 认领记录与状态流转设计

认领记录的逻辑是：某个用户看到招领信息，提交认领申请，填写物品特征说明；管理员审核申请后，可标记认领成功或拒绝。这个环节是“闭环”的关键。

sql复制CREATE TABLE `claim_record` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT,
  `item_id` bigint(20) NOT NULL COMMENT '关联失物信息ID',
  `claim_user_id` bigint(20) NOT NULL COMMENT '申请人ID',
  `description` varchar(500) DEFAULT NULL COMMENT '认领说明/物品特征',
  `evidence` varchar(255) DEFAULT NULL COMMENT '凭证图片路径',
  `status` tinyint(4) DEFAULT '0' COMMENT '状态:0-待审核 1-通过 2-拒绝',
  `reply` varchar(255) DEFAULT NULL COMMENT '管理员回复',
  `create_time` datetime DEFAULT NULL,
  `update_time` datetime DEFAULT NULL,
  PRIMARY KEY (`id`),
  KEY `idx_item_id` (`item_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

配套的状态机流转表如下：

状态机用常量类去维护，不要散落在业务代码里。

4. 核心功能模块实现细节

4.1 发布与分类：从表单校验到图片上传

发布失物信息是用户使用频率最高的操作，也是最容易出Bug的模块。它包含：表单校验、图片上传、数据落库、通知触达四个环节。

先讲图片上传。图片上传失败是实际开发中高频问题，原因绝大多数出在路径处理上。

我在项目里用的方案是将图片保存到服务器本地，路径规则为：/upload/2024/06/15/uuid.jpg，数据库中保存这个相对路径。前端标签访问时，需要配置Spring Boot的静态资源映射：

java复制@Configuration
public class WebMvcConfig implements WebMvcConfigurer {
    @Override
    public void addResourceHandlers(ResourceHandlerRegistry registry) {
        String uploadPath = System.getProperty("user.dir") + File.separator + "upload" + File.separator;
        registry.addResourceHandler("/upload/**")
                .addResourceLocations("file:" + uploadPath);
    }
}

注意：Windows环境下的文件路径是反斜杠，但URL访问必须是正斜杠。用File.separator拼磁盘路径，用/拼URL映射，两者不要混，否则发布到Linux服务器上就会出现图片404。

图片上传的Controller方法大致如下：

java复制@PostMapping("/upload/image")
@ResponseBody
public Result uploadImage(@RequestParam("file") MultipartFile file) {
    if (file.isEmpty()) {
        return Result.error("上传文件为空");
    }
    // 校验文件大小和类型
    long maxSize = 5 * 1024 * 1024; // 5MB
    if (file.getSize() > maxSize) {
        return Result.error("图片大小不能超过5MB");
    }
    String originalFilename = file.getOriginalFilename();
    String ext = originalFilename.substring(originalFilename.lastIndexOf("."));
    List<String> allowExt = Arrays.asList(".jpg", ".jpeg", ".png", ".gif");
    if (!allowExt.contains(ext.toLowerCase())) {
        return Result.error("图片格式仅支持jpg/png/gif");
    }
    String fileName = UUID.randomUUID().toString().replace("-", "") + ext;
    String datePath = new SimpleDateFormat("yyyy/MM/dd").format(new Date());
    String dirPath = System.getProperty("user.dir") + "/upload/" + datePath;
    File dir = new File(dirPath);
    if (!dir.exists()) {
        dir.mkdirs();
    }
    try {
        file.transferTo(new File(dir, fileName));
    } catch (IOException e) {
        return Result.error("图片保存失败");
    }
    String url = "/upload/" + datePath + "/" + fileName;
    return Result.success(url);
}

这段代码把校验、路径、存储整合在一起，答辩时可以逐行解释，比你背一个完整项目更有说服力。

4.2 模糊匹配：关键词检索与分类过滤的实用方案

失物招领最重要的功能之一是“让失主快速发现自己丢的东西”。搜索场景分为两块：分类浏览和关键词搜索。

分类浏览比较简单，前端传分类ID，后端加个where条件。关键词搜索我用的方案是MySQL的LIKE模糊匹配，匹配字段包括标题、描述、地点三个字段。

xml复制<select id="searchItems" resultType="com.campus.lostfound.entity.Item">
    SELECT * FROM item
    <where>
        <if test="keyword != null and keyword != ''">
            AND (title LIKE CONCAT('%', #{keyword}, '%')
                 OR description LIKE CONCAT('%', #{keyword}, '%')
                 OR place LIKE CONCAT('%', #{keyword}, '%'))
        </if>
        <if test="categoryId != null">
            AND category_id = #{categoryId}
        </if>
        <if test="type != null">
            AND type = #{type}
        </if>
        AND status IN (1, 2)
    </where>
    ORDER BY create_time DESC
</select>

这里要强调一个细节：数据库模糊查询的%拼接，在MyBatis中推荐使用CONCAT('%', #{keyword}, '%')而不是'%${keyword}%'。前者是预编译参数，有效防止SQL注入；后者是字符串拼接，一旦keyword里含有单引号就报错，甚至有注入风险。这个点也是答辩老师很喜欢挖的“陷阱”。

从性能角度讲，LIKE '%keyword%'无法走索引，在数据量小（几千条）时完全没问题。答辩时可以主动补充一句“如果后续数据量增长，可以考虑引入Elasticsearch或全文索引，当前阶段MySQL足以满足校园场景”。能说出这个权衡，说明你真的思考过系统边界。

4.3 认领流程：状态机设计与流程控制

认领流程的逻辑不复杂，但分支多。我重点讲一下后端如何控制状态流转，避免出现“物品已经被认领了，其他人还能继续提交申请”这类问题。

首选方案是乐观锁。在item表增加version字段，更新状态时带上版本号：

java复制int count = itemMapper.updateStatusWithVersion(
        item.getId(), 
        oldStatus, 
        newStatus, 
        item.getVersion()
);
if (count == 0) {
    throw new ServiceException("物品状态已变化，请刷新后重试");
}

对应的SQL为：

sql复制UPDATE item 
SET status = #{newStatus}, version = version + 1, update_time = NOW()
WHERE id = #{id} AND status = #{oldStatus} AND version = #{version}

并发的可能性在校园场景不高，但毕业设计里写出这行代码，就能体现你对数据一致性的思考，属于性价比很高的设计。

认领流程的完整代码链路为：用户点击“申请认领” -> 后端校验当前状态为“发布中” -> 插入claim_record，状态为待审核 -> 更新item状态为“认领中” -> 推送站内信给发布人。

4.4 消息通知：站内信与邮件通知的结合

一个闭环的失物招领系统，如果用户不主动刷新页面，就不知道有人申请认领或自己的物品被认领了。所以消息通知模块必不可少。

我建议做轻量级的站内信 + 邮件两种方式。站内信就是一张通知表，用户登录后在导航栏显示红点未读数量；邮件用Spring Boot自带的JavaMailSender发送，配合线程池做异步，避免邮件阻塞主流程。

站内信表设计（简化版）：

sql复制CREATE TABLE `message` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT,
  `user_id` bigint(20) NOT NULL COMMENT '接收人ID',
  `title` varchar(100) NOT NULL,
  `content` varchar(500) DEFAULT NULL,
  `is_read` tinyint(4) DEFAULT '0' COMMENT '0-未读 1-已读',
  `create_time` datetime DEFAULT NULL,
  PRIMARY KEY (`id`),
  KEY `idx_user_id` (`user_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

触发时机包括：申请认领时通知发布者、审核通过或拒绝时通知申请者、物品被管理员下架时通知发布者。

5. 管理后台：审核、统计与权限设计

5.1 审核机制：防止虚假信息和隐私泄露的处理策略

失物招领公开的信息里包含联系电话、联系人姓名，如果审核不严，很容易被广告党利用。管理端的审核功能因此变得很关键。

我的做法是：新发布的失物信息默认状态为“待审核”，管理员可以在后台查看详情、图片、发布人信息，决定通过或驳回，驳回时必须填写审核意见。用户端只能看到“发布中”和“认领中”的信息，这样就把虚假信息挡在可见范围之外。

这里提一个优化细节：图片审核。校园系统不一定需要接第三方内容审核API，但可以做一个“图片预览放大”功能，让管理员在后台直接点击大图查看，减少主观误判。

5.2 数据统计：毕业设计中的差异化加分项

很多毕业设计管理端只做增删改查，千篇一律。加一个ECharts数据统计看板，能明显提升系统的完整度和答辩观感。

我实现的统计模块包括：

• 近30天每日新增物品数（折线图）
• 分类占比（饼图）
• 拾到vs寻物比例（柱状图）
• 各状态数量（数字卡片）

实现思路是用一条SQL做GROUP BY聚合查询：

java复制@Mapper
public interface StatsMapper {
    // 按分类统计物品数量
    @Select("SELECT c.name AS name, COUNT(i.id) AS value " +
            "FROM item i LEFT JOIN category c ON i.category_id = c.id " +
            "WHERE i.type = #{type} " +
            "GROUP BY c.id ORDER BY value DESC")
    List<Map<String, Object>> countByCategory(Integer type);
}

前端用ECharts的ajax请求拿到JSON后渲染。这里的体现的是“你不仅会写CRUD，还知道怎么把数据变成决策依据”，这比功能本身更能给人留下好印象。

5.3 后台权限控制

管理后台的权限控制，我采用Spring Boot拦截器 + HandlerInterceptor实现。

简单方案：定义AdminInterceptor，拦截/admin/**路径，从Session中取用户，判断角色是否大于等于管理员，不合格就重定向到登录页。再在WebMvcConfig里注册拦截器并排除登录接口。

java复制@Component
public class AdminInterceptor implements HandlerInterceptor {
    @Override
    public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {
        User user = (User) request.getSession().getAttribute("loginUser");
        if (user != null && user.getRole() >= 1) {
            return true;
        }
        response.sendRedirect("/admin/login");
        return false;
    }
}

再配合一个@RequirePermission(role = 2)自定义注解实现超管接口的二次校验，逻辑就完整了。这套方案不引入Spring Security，但对毕业设计的权限展示已经足够。

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

6.1 图片上传失败：3个隐藏原因

我做这个项目时，图片上传遇到的坑比预期多。整理一下，方便你遇到同类问题时快速定位。

这里额外提醒：默认Spring Boot上传大小限制是1MB，用户拍一张手机照片远超这个值。所以一定要在配置文件中调整：

yaml复制spring:
  servlet:
    multipart:
      max-file-size: 10MB
      max-request-size: 20MB

6.2 中文乱码：从数据库到页面一次排查

中文乱码是Web项目的新手高频问题，排查顺序是：数据库连接URL -> 数据库表字符集 -> 页面编码。

数据库连接URL里必须带useUnicode=true&characterEncoding=utf8。MySQL 8还建议加serverTimezone=Asia/Shanghai，避免时间差8小时。

yaml复制spring:
  datasource:
    url: jdbc:mysql://localhost:3306/lostfound?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai

数据库建表统一用utf8mb4，比utf8多支持Emoji等四字节字符，防止用户在描述里放个表情就直接报错。

页面方面，Thymeleaf默认UTF-8，只要在application.yml里设置spring.thymeleaf.encoding: UTF-8即可。

6.3 MyBatis Plus分页查询不生效

MyBatis Plus的分页需要单独配置分页插件，这个坑很经典。不配置插件时，Page对象能查出来记录但total始终为0，limit不生效。

解决方案是加一个配置类：

java复制@Configuration
public class MybatisPlusConfig {
    @Bean
    public MybatisPlusInterceptor mybatisPlusInterceptor() {
        MybatisPlusInterceptor interceptor = new MybatisPlusInterceptor();
        interceptor.addInnerInterceptor(new PaginationInnerInterceptor(DbType.MYSQL));
        return interceptor;
    }
}

不配置它，你在Service层写的page(Page, Wrapper)看起来没报错，但数据翻页逻辑完全失效。这类坑很浪费调试时间，记住一次后面就顺了。

6.4 会话失效与登录状态丢失

用户发布信息后，点击提交突然被踢回登录页，这个问题通常出在Session过期时间上。Spring Boot默认Session超时30分钟，如果你希望用户使用更友好，可以在配置里调长：

yaml复制server:
  servlet:
    session:
      timeout: 120m

但设太长也有安全风险，合理做法是前端在登录时记住用户、后端用Redis做会话共享，这是加分方向；毕业设计阶段用默认Session并设置合理过期时间即可，不用过度设计。

7. 部署上线与答辩准备建议

7.1 从本机到服务器的部署流程

本地开发跑得好好的，一上服务器就起不来，是毕设项目翻车重灾区。我的建议是提前按照“标准路径”完整走一遍部署，以下步骤亲测可行。

1. 打包：在项目根目录执行mvn clean package -DskipTests，在target目录得到jar包。
2. 上传：将jar包传到服务器，我习惯放在/app/lostfound/。
3. 初始化数据库：导入数据库SQL文件，检查MySQL8是否开启了远程访问（注意生产环境别开，用localhost）。
4. 启动：执行nohup java -jar lostfound.jar > app.log 2>&1 &。
5. 验证：通过curl http://localhost:8080/测试，再用Nginx反向代理到80端口。

注意：如果服务器装了多个JDK版本，务必在启动命令里指定JAVA_HOME或用/usr/local/jdk1.8/bin/java，否则java -jar可能用的是旧版本而直接启动失败。

Nginx配置示例（关键部分）：

nginx复制server {
    listen 80;
    server_name campus.example.com;
    
    location / {
        proxy_pass http://127.0.0.1:8080;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }

    location /upload/ {
        alias /app/lostfound/upload/;
    }
}

图片资源单独用alias指向磁盘目录，避免经过Spring Boot静态资源映射多绕一圈，性能更好。

7.2 答辩高频问题清单

答辩环节，老师看的不只是功能演示，更看重你对系统整体的理解和思维过程。我整理了几个大概率被问到的问题，建议提前演练回答：

1. 为什么选择这个选题？ 从校园实际痛点切入，强调系统的实用性和社会价值，避免说“因为好做”。
2. 系统架构和技术栈是怎么选型的？为什么不用XX框架？ 从开发效率、学习成本、生态成熟度三个角度回答，指出当前技术栈的合理性。
3. 数据库表为什么这样设计？有没有冗余？ 主动讲images字段的反规范化、索引设计、状态机思路，展示你有取舍思考。
4. 如何防止SQL注入和XSS攻击？ SQL注入用预编译（#{}），XSS在后端做输入过滤+前端做HTML转义。
5. 如果你的系统上线，会面对什么问题？如何优化？ 高并发下加缓存，搜索性能用Elasticsearch，图片上传用对象存储。即便没实现，说出方案思路也是加分项。
6. 项目最大的难点是什么，怎么解决的？ 建议说“图片上传路径映射和状态流转并发问题”，这两个点都有完整的分析和解决方案。

最后再分享一个小技巧，答辩时演示不要只点正常路径，可以故意先演示一个错误提示，比如“提交一个没有标题的失物信息”，然后在大家面前说出系统如何校验、如何提示、如何防止脏数据入库。这一整套动作下来，给答辩老师的印象绝对比干巴巴讲功能要深得多。