企业官网建设流程全解析

做毕业设计最怕的就是选了一个“听上去高级，做起来抽象”的题目。今天说的这个校园失物招领系统，用的就是 SpringBoot + Vue + MySQL，三个词组合起来在毕业设计选题名单里属于“常青树”，但它能写多深、能挖多少细节，完全取决于你怎么去拆需求、设计表和做前后端联调。这个系统解决的核心问题其实很简单——学校里每天都有丢校园卡、丢保温杯、捡到钥匙但找不到失主的人，线下通知栏和群聊消息太分散，于是需要一个集中发布、搜索、认领、管理一体的线上平台。

这套系统既能作为课程设计，也能直接当毕业设计，适合有一定 Java 和前端基础、但还没有完整做过一个前后端分离项目的同学。如果你正在准备开题报告，或者已经拿到源码但看不懂整体结构，这篇内容会从需求拆解、数据库设计、接口实现、前端页面到服务器部署，带你完整过一遍项目里最容易被追问的细节和最容易踩坑的地方。

1. 项目拆解：校园失物招领系统的核心需求与设计思路

1.1 这个毕业设计到底要做什么

失物招领平台本质上是一个“信息撮合系统”。丢东西的人发一条寻物启事，捡到东西的人发一条拾物启事，管理员审核之后公开展示，其他用户看到信息后可以通过平台留下的联系方式进行认领或归还。

听起来很简单，但是作为毕业设计你要把它拆成明确的功能闭环：

• 用户端：注册登录、发布寻物信息、发布拾物信息、查看物品列表、搜索物品、查看物品详情、申请认领、个人中心管理自己的发布。
• 管理端：审核发布信息、管理用户、管理分类、处理认领申请、下架违规信息、数据统计。

这里有一个设计关键：用户发布信息之后，不应该直接显示在首页，而是要有一个“待审核”状态。审核这一步虽然增加了工作量，但却是论文里业务完整性和功能亮点的重要来源。很多同学为了省事去掉审核，结果答辩的时候被问“如果有人发了违法内容怎么办”就答不上来，所以不要让系统看起来太简陋。

核心业务闭环建议这样设计：发布 -> 审核 -> 展示 -> 用户认领 -> 管理员确认 -> 完成状态。认领环节不要做成“用户点一下认领就算结束”，要保留“待确认 / 已确认”状态，否则数据库里无法记录完整生命周期，论文里的流程图和时序图也会显得单薄。

1.2 为什么选 SpringBoot + Vue + MySQL 这个组合

这个组合在毕业设计里几乎是“安全牌”，原因很现实：

• SpringBoot 省掉了大量 XML 配置，内嵌 Tomcat，后端程序写完之后直接java -jar就能跑，部署成本低，对不会配服务器的同学非常友好。
• Vue 的组件化开发让前端页面结构清晰，单个页面拆成组件后，代码量看似增加了，但实际上维护和修改都更方便，而且 Vue 的生态资料多，遇到报错基本都能搜到答案。
• MySQL 的社区资料最全，InnoDB 引擎支持事务，表结构设计、索引优化、SQL 写法，几乎所有面试问题都能和课程知识对应上，答辩时不缺内容可讲。

还要顺带说明一个常见选择：很多人纠结用 MyBatis 还是 MyBatis-Plus。如果只想快速出成果，优先选 MyBatis-Plus，它自带 BaseMapper，分页查询也只需要加一个配置类，单表操作几乎不用手写 SQL。稍微讲究一点的同学可以在“多表关联查询”的部分手写 XML，这样论文里既能体现“框架提高开发效率”，又能体现“复杂查询仍可自定义 SQL”，两边都有话说。

为什么不建议在这个项目里引入 Redis、RabbitMQ、ES 这类重量级组件？不是它们不好，而是失物招领系统的并发量很低，用户可能集中在某个食堂丢东西，同一时间在线人数不会太多，引入多余组件反而会增加答辩风险，比如“缓存和数据库不一致怎么办”这种问题，没有必要给自己挖坑。如果一定要体现技术选型深度，可以提到“考虑到数据量和并发量不大，因此不引入 Redis，降低维护成本”，这也是合理的说法。

1.3 需求边界：不要一开始就想着“大而全”

很多同学开题时恨不得把论坛、商城、社交全塞进去，结果中期检查时项目还跑不起来。明确画一个需求边界，反而能让论文更好写。

第一阶段（必做）：

• 用户注册、登录、退出。
• 发布寻物启事、拾物启事。
• 物品分类（证件、电子产品、生活用品、其他）。
• 图片上传。
• 关键字搜索 + 按分类筛选。
• 认领申请流程。
• 管理员后台审核。

第二阶段（选做，视时间而定）：

• 用户信用/点赞评价。
• 数据统计页面（按分类、按时间展示发布数量）。
• 导出 Excel 报表。
• 相似物品模糊匹配。

我建议核心精力放在第一阶段。失物招领的本质是“信息的发布与匹配”，只要把信息流的稳定性、搜索的准确率、认领流程的严谨性做扎实，就可以拿到一个不错的分数。反而是花大量时间做花哨页面，最后发现后端接口一塌糊涂，答辩时只能空谈样式，非常可惜。

2. 数据库设计：从表结构到字段设计的实战细节

2.1 核心表设计：用户、物品、认领记录、分类、留言

数据库是整个系统的地基，表设计直接决定后端代码复杂度和论文的数据流图清晰程度。按这个项目的最小闭环，我建议拆五张表。

用户表user，用来存登录账号和个人信息：

CREATE TABLE `user` ( `id` bigint NOT NULL AUTO_INCREMENT, `username` varchar(50) NOT NULL COMMENT '登录账号', `password` varchar(100) NOT NULL COMMENT '加密后密码', `real_name` 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 NOT NULL DEFAULT 0 COMMENT '0普通用户 1管理员', `status` tinyint NOT NULL DEFAULT 1 COMMENT '1正常 0禁用', `create_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, `update_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (`id`), UNIQUE KEY `uk_username` (`username`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='用户表';

物品表item是最核心的表，要同时承载“寻物”和“拾物”两类信息，用一个type字段区分。这样可以少拆一张表，查询时一条 SQL 就能根据类型做列表页。

CREATE TABLE `item` ( `id` bigint NOT NULL AUTO_INCREMENT, `user_id` bigint NOT NULL COMMENT '发布人id', `title` varchar(100) NOT NULL COMMENT '物品名称', `description` text COMMENT '详细描述', `category_id` bigint DEFAULT NULL COMMENT '分类id', `type` tinyint NOT NULL COMMENT '0寻物 1拾物', `status` tinyint NOT NULL DEFAULT 0 COMMENT '0待审核 1已发布 2已认领 3已完成', `location` varchar(100) DEFAULT NULL COMMENT '丢失/拾到地点', `image_url` varchar(255) DEFAULT NULL COMMENT '物品图片', `contact` varchar(100) DEFAULT NULL COMMENT '发布人联系方式', `views` 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_create_time` (`create_time`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='物品信息表';

认领记录表claim，用来管理“某人对某物品提出了认领申请”：

CREATE TABLE `claim` ( `id` bigint NOT NULL AUTO_INCREMENT, `item_id` bigint NOT NULL COMMENT '物品id', `user_id` bigint NOT NULL COMMENT '申请人id', `content` varchar(255) DEFAULT NULL COMMENT '认领说明', `contact` varchar(100) DEFAULT NULL COMMENT '申请人联系方式', `status` tinyint NOT NULL DEFAULT 0 COMMENT '0待审核 1已通过 2已拒绝', `create_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`), KEY `idx_item_id` (`item_id`), KEY `idx_user_id` (`user_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='认领记录表';

分类表category、留言表message就不详写了，分类表就是 id、name、sort；留言表是关联 user 和 item，用于站点留言或物品评论，非核心但能让功能丰富一点。

一个很容易忽略的点：contact字段为什么要存在认领表里而不是直接查用户表？因为在真实场景中，申请人不一定是注册用户，也可能是看到页面后通过平台留言的游客。放在表里可以让“认领线索”作为独立数据留存，管理员审核时才能看到完整人联系方式。这种设计细节，论文里可以写一条业务分析，很加分。

2.2 表关系与索引设计：为什么要这样建

表关系上，我建议只保留逻辑外键，不在数据库里物理建外键约束。原因很简单：物理外键在删除或更新时会触发一致性检查，在高并发下容易造成锁竞争，而毕设项目又是单人开发，物理外键反而容易在测试时因为删除顺序报错。保持 mysql 内部简洁，代码里通过 Service 保证数据关联，是目前的主流做法。

索引方面要注意几个点：

• item表里的type + status联合索引是列表页查询的关键，首页默认要展示“已发布”的拾物信息，如果类型和状态两列都参与查询条件，联合索引能避免全表扫描。
• create_time单独加普通索引，方便按时间排序。title字段不要直接建普通索引，因为模糊查询LIKE '%关键词%'用不到普通索引，如果以后数据量大，可以改上全文索引，但毕业设计阶段不需要过度优化。

字符集要用utf8mb4而不是utf8，因为utf8在 MySQL 里实际上是 3 字节实现，很多特殊字符和对应表情包存不进去。用utf8mb4之后，配合utf8mb4_general_ci排序规则，基本不会出现乱码和索引长度问题。

2.3 数据库初始化与演示数据：别忽略这步

很多同学拿到源码后直接跑后端，发现列表页空荡荡，第一反应是系统坏了。其实只是没有初始化数据。在项目里提供一个init.sql是最基本的交付物。

初始化数据要包含：

• 一个管理员账号，密码必须是加密后的哈希值。
• 四个默认分类：证件卡片、电子产品、生活用品、其他。
• 几条演示物品数据，比如“蓝色保温杯丢失在图书馆三楼”“校园卡拾到于第二食堂”“黑色双肩包遗忘在操场看台”，这些贴近校园生活的数据能让前端页面看起来真实，也能方便你录演示视频。

这里要提醒一个容易出错的地方：如果你用 Spring Security 或 Sa-Token 之类的认证框架，管理员账号的密码千万不要写成明文。如果用了 BCrypt 加密，到 [BCrypt 在线生成哈希值] 的页面生成一串，填到 init.sql 里，登录时再通过密码比较器验证。我见过太多次初始化 SQL 里放明文密码，结果每次登录都以为自己代码写错了。

3. 后端实现：SpringBoot 分层架构与核心接口

3.1 项目初始化与依赖管理：版本别乱搭

后端建议用 SpringBoot 2.7.x，对应 JDK 8。如果你电脑已经装了 JDK 17，也可以选 SpringBoot 3.0 以上，但 MyBatis-Plus、JWT 等通用依赖的版本适配会麻烦一点，而且很多旧教程是基于 2.7 写的，跟着操作时更容易踩兼容坑。没有特别理由的话，老老实实用 2.7.x。

pom.xml 里必要的依赖大致是这些：

<dependencies> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> <dependency> <groupId>com.baomidou</groupId> <artifactId>mybatis-plus-boot-starter</artifactId> <version>3.5.2</version> </dependency> <dependency> <groupId>com.mysql</groupId> <artifactId>mysql-connector-j</artifactId> <scope>runtime</scope> </dependency> <dependency> <groupId>org.projectlombok</groupId> <artifactId>lombok</artifactId> <optional>true</optional> </dependency> <dependency> <groupId>io.jsonwebtoken</groupId> <artifactId>jjwt-api</artifactId> <version>0.11.5</version> </dependency> <dependency> <groupId>io.jsonwebtoken</groupId> <artifactId>jjwt-impl</artifactId> <version>0.11.5</version> <scope>runtime</scope> </dependency> </dependencies>

包结构建议按 controller/service/mapper/entity/dto/vo/config/common 来分。很多人觉得麻烦，但这套分层如果不在项目初期搭好，后面写认证拦截器、统一异常处理时会到处找不到文件。刚开始代码少不觉得，等写到 30 个接口，各层文件一团乱，你自己都会崩溃。

application.yml 里把你常用的 MySQL 连接信息填好，注意加上时区参数：

server: port: 8080 spring: datasource: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://localhost:3306/lost_found?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai&useSSL=false username: root password: 你的密码 servlet: multipart: max-file-size: 10MB max-request-size: 20MB mybatis-plus: configuration: log-impl: org.apache.ibatis.logging.stdout.StdOutImpl global-config: db-config: id-type: auto

3.2 安全认证：JWT 登录与权限控制，别只做“能登录就行”

前后端分离项目里，Session 不太方便，因为跨域、跨端口时 Cookie 的处理比较麻烦，所以选 JWT 几乎是标准答案。逻辑不复杂：用户登录成功后，后端根据 userId 和 role 生成一个 token 返回给前端，前端存到 localStorage，之后每次请求在请求头里带Authorization: Bearer <token>，后端用拦截器验证 token 是否有效，然后从 token 里取出当前用户信息放到请求上下文里。

关键代码可以这样做，先写一个拦截器：

@Component public class AuthInterceptor implements HandlerInterceptor { @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { String token = request.getHeader("Authorization"); if (token == null || !token.startsWith("Bearer ")) { response.setStatus(401); return false; } // 调用 JwtUtil 解析 token LoginUser user = JwtUtil.parseToken(token.replace("Bearer ", "")); if (user == null) { response.setStatus(401); return false; } request.setAttribute("userId", user.getUserId()); request.setAttribute("role", user.getRole()); return true; } }

配置拦截器白名单时要注意：登录、注册、图片访问、首页列表查询这些接口必须放行。管理端接口可以单独再判断一次 role，或者用注解方式标记@RequireAdmin，这样语义更清晰。白名单漏配置是新手最容易犯的问题，经常会“登录之后所有接口都通”，实际上是因为你根本没加拦截器，只是写在配置类里没生效。

JWT 还有一个细节：过期时间不要设太长。我通常设置 24 小时过期，过期之后要求前端重新登录。有些项目为了演示方便直接设置 7 天，结果答辩现场开着前一天的项目，token 有效没混过去，这种细节不扣分但也不加分。做一个“记住我”功能也可以，但没必要，别把系统搞复杂了。

3.3 核心业务接口：发布、查询、认领流程的注意点

后端接口设计要尽量“语义化，方便前端调用”。我列几个核心接口：

• POST /api/addItem发布信息。
• GET /api/public/items?page=1&pageSize=10&type=1&status=1分页查询已审核通过的物品。
• GET /api/public/items/{id}物品详情，单次访问浏览量加 1。
• POST /api/claim提交认领申请。
• PUT /api/admin/auditItem/{id}?status=1管理员审核发布。
• PUT /api/admin/auditClaim/{id}?status=1管理员审核认领申请。

以发布物品为例，Controller 接收参数后，要在 Service 里补充几个字段：当前登录用户 ID 自动填充，状态初始化为“待审核”。发布人是不能直接传userId的，否则用户可以通过抓包伪造发布身份，虽然毕设不要求高安全，但这个细节在答辩时很容易被问：“你怎么保证发布人是本人？”你回答“userId 从 token 获取，不信任前端传参”，这一句话就能拉好感。

发布、认领申请这类写操作，需要在 Service 层加上事务注解：

@Transactional(rollbackFor = Exception.class) public void auditClaim(Long claimId, Integer status, Long adminId) { // 更新 claim 状态 // 如果 status 为 1(通过)，同步修改 item 的状态为已认领 }

事务不是用来炫技的，而是为了保证两条 SQL 要么全成功要么全失败。认领通过时，如果只更新了 claim 表，没有同步把 item 状态改成“已认领”，那么列表里还会继续展示这条物品，别人还能继续申请认领，业务就混乱了。把这两步放到同一个事务里，是最基础的数据一致性保障。

再提一个容易被忽略的接口：浏览量。在详情接口里直接views += 1是最简单的，但如果你每次都执行 update，刷新一次就加一次，完全没有防刷控制。毕设通常不需要做防刷。不过可以设计成同一个 IP 在五分钟内不算重复浏览量，这就有点自己的小优化思路了，答辩时可以和缓存、性能优化挂上关系。

4. 前端实现：Vue 组件化开发与交互优化

4.1 Vue 项目结构与路由设计：别把所有代码塞到一个文件里

前端我用的是 Vue 2 + Element UI，因为市面上参考资料最多，基本属于“不会就问，一搜一堆答案”的稳定组合。如果你熟悉 Vue 3 + Element Plus，也没有问题，但为了保证旧资料可用性，我更推荐前者。

先规划目录结构，不要一上来就npm create生成一个空白项目然后直接改 App.vue。规范的拆分是这样的：

src/ api/ # 按模块封装接口 request.js user.js item.js claim.js upload.js assets/ components/ # 公共组件 UploadImage.vue EmptyState.vue Pagination.vue layout/ HomeLayout.vue router/ index.js store/ index.js utils/ auth.js views/ Home.vue ItemDetail.vue PublishItem.vue UserCenter.vue Admin/ AuditItem.vue AuditClaim.vue CategoryManage.vue

路由配置里，尽量用懒加载：

const routes = [ { path: '/', component: () => import('@/layout/HomeLayout.vue'), children: [ { path: '', component: () => import('@/views/Home.vue') }, { path: 'detail/:id', component: () => import('@/views/ItemDetail.vue') } ] }, { path: '/publish', component: () => import('@/views/PublishItem.vue'), meta: { requiresAuth: true } } ]

路由守卫也要加上，否则后端接口校验再严格，前端也能看到一片需要登录才能操作的按钮，体验很割裂。

在router/index.js里加一个全局前置守卫：

router.beforeEach((to, from, next) => { const token = localStorage.getItem('token') if (to.meta.requiresAuth && !token) { next('/login') } else { next() } })

4.2 请求封装与 API 管理：统一处理 token 和错误码

如果前端每个页面都直接调用axios.get，代码会非常难维护。适合的做法是封装一个request.js：

import axios from 'axios' const request = axios.create({ baseURL: '/api', timeout: 15000 }) 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) { if (res.code === 401) { localStorage.removeItem('token') window.location.href = '/login' } return Promise.reject(new Error(res.message || 'Error')) } return res }, error => { return Promise.reject(error) } ) export default request

然后每个 api 模块就是一个导出函数：

// api/item.js import request from './request' export function getPublicItems(params) { return request({ url: '/public/items', method: 'get', params }) }

注意这里的 baseURL 我写的是/api，不是完整后端地址。这样本地开发时配合 Vite 的 proxy，线上部署配合 Nginx 的 location 转发，都不需要改前端代码。这个习惯很重要，否则前端开发环境用localhost:8080，线上用服务器 IP，每次部署都要把请求地址全部改一遍，非常痛苦。

4.3 核心页面拆解：发布表单、列表卡片、详情弹窗

首页分三块内容：顶部搜索栏、分类筛选标签、物品列表。列表不用表格，用卡片式更符合失物招领的浏览场景。卡片里展示图片、物品标题、类型标签（寻物/拾物）、发布时间，点击进入详情。

发布页面是最容易写砸的地方，因为它涉及表单校验、图片上传、动态类型切换。用 el-form 绑定 rules，注意字段名和后端 DTO 保持一致。图片上传可以用 el-upload，但 action 地址一定要配置正确：

<el-upload :action="uploadUrl" :headers="uploadHeaders" :on-success="handleUploadSuccess" :limit="1" accept="image/*" > <el-button>上传图片</el-button> </el-upload>

这里的uploadUrl如果你直接写死成http://localhost:8080/api/upload，前端会在本地开发时跨域。要么在开发环境走代理，要么在 el-upload 的 action 里写/api/upload，确保通过 Nginx 或其它服务转发到后端，这一点在配置环境变量时要想清楚。

提交按钮时注意用一个submitting状态配合 disabled 防止重复提交。表单校验在 user 提交前触发。图片上传成功后，后端返回图片 URL，和其它表单参数一起提交到发布接口，不要提交 FormData，否则后端接收逻辑会更繁琐。

详情页的认领按钮要判断用户是否登录。如果未登录，弹出登录提示。认领表单字段包含“认领说明”“联系方式”，这样管理员审核时能看到有效线索。认领成功后，给发布人一个消息通知，这里可以简单用站内信表或者邮件发送，但不要做太复杂，直接在数据库里加一张message表就够了。

5. 部署流程：从本地到服务器的完整步骤

5.1 环境准备：JDK、MySQL、Node、Nginx

很多人的项目只能在本地跑，答辩前拷贝同学电脑或教室讲台上台跑一遍，镜头一转就是“环境有问题”，体验极差。我建议有条件就部署到云服务器上，整个流程其实不难。

服务器端需要安装的东西：

• JDK 1.8：后端 jar 运行环境。
• MySQL 5.7 或 8.0：建议 8.0，和本地方便保持一致。
• Node.js 14 及以上：只需要构建前端时用，服务器上也可以不装，前端构建好 dist 再上传。
• Nginx：静态文件服务 + 接口转发。

安装过程中注意版本一致。如果你本地用的 MySQL 8，服务器也是 8.0，那 init.sql 导入基本没问题。如果本地是 8.0，服务器是 5.7，遇见 utf8mb4 字符集和一些语法兼容问题会很浪费时间。建议干脆统一用 MySQL 8.0。

使用 Linux 系统时，MySQL 安装完成后要执行mysql_secure_installation或者手动设置 root 密码，并创建一个业务数据库和账号。为了安全，不要在application.yml里写死 root 密码，可以通过外部配置覆盖：

nohup java -jar lostfound.jar --spring.config.location=/usr/local/lostfound/application-prod.yml > server.log 2>&1 &

这里的--spring.config.location可以指定外部配置文件路径，即使 jar 包里内置了开发环境配置，也能被外部文件覆盖，非常适合服务器部署。

5.2 从源码构建到产物：npm build 和 maven package

后端构建之前，先检查application-prod.yml里的数据库地址和密码。然后执行：

mvn clean package -DskipTests

打包好的 jar 在target目录下，文件名叫lostfound-0.0.1-SNAPSHOT.jar。

前端构建前，先确认request.js里的 baseURL 是否用的是/api，如果已经统一使用相对路径，直接执行：

npm install npm run build

构建完成后，dist目录就是纯静态资源，直接把这个目录传到服务器的/usr/local/lostfound/dist下即可。

这段流程里有两个常见问题：

• npm install下载慢：可以把镜像切换到某开源镜像源，但注意不要在文档里提“代理”相关词，直接说“换成镜像源”就行。
• 后端 jar 启动失败：直接java -jar前台运行看日志，把报错信息贴到搜索引擎或工具里排查。最常见的是数据库密码错误或数据库没有初始化。

5.3 Nginx 配置：把前端页面和后端接口连接起来

Nginx 配置需要两个核心 block，一个是处理前端静态资源，另一个是把/api的请求转发给后端服务。一个最小可用的配置类似这样：

server { listen 80; server_name your_domain_or_ip; root /usr/local/lostfound/dist; index index.html; location / { try_files $uri $uri/ /index.html; } location /api/ { proxy_pass http://127.0.0.1:8080/api/; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } }

解释一下这几个配置的作用：

• try_files解决 Vue 路由切换时刷新页面 404 的问题。比如说你访问/detail/12，刷新时如果 Nginx 找不到对应文件，就会尝试回退到/index.html，由前端路由接管，这个配置不做会出现“页面刷新空白”。
• proxy_pass把 API 请求转发到后端的 Java 服务。注意转发路径不要写错，否则接口全 404。

配置完之后执行：

nginx -t nginx -s reload

如果服务器有安全组或防火墙，记得放行 80 端口和后端端口。后端服务不应直接暴露给公网，只让 Nginx 访问即可，这也算一个小的安全加固点。

6. 论文撰写与文档整理经验

6.1 论文结构怎么搭：五章到六章足够了

毕业设计的论文不是越厚越好，而是要结构清晰、逻辑完整。我个人建议控制在六章：

• 第一章 绪论：研究背景与意义、国内外现状、主要工作。
• 第二章 相关技术介绍：SpringBoot、Vue、MyBatis-Plus、MySQL、JWT，每节 500 字左右，不要大段贴官网介绍，要结合项目写“为什么选它”。
• 第三章 需求分析：业务流程分析、功能性需求、非功能性需求、用例图。
• 第四章 系统设计：总体架构、功能模块设计、数据库设计、接口设计。
• 第五章 系统实现：核心功能界面截图 + 关键代码 + 实现思路。
• 第六章 系统测试：测试环境、测试用例、功能测试、兼容性测试。

这个结构不可能拿满分，但也不会出错。答辩老师最关心的是你“有没有认真想清楚为什么这么做”，所以需求分析和系统设计两章要重点写，不要只堆截图。

画图方面，不建议用 Mermaid 插入论文正文，论文里要用正式的图片格式，可以用 Visio、ProcessOn 这类工具画架构图和流程图。如果能画得规范一点，整个论文的观感会立刻提升不少。

6.2 如何把代码转换成论文语言：避免“项目说明书”味

很多同学论文里会写“本项目使用 Vue 的 el-table 组件展示用户列表，使用 axios 发送请求”。这样太像操作手册了。更好的写法是描述“开发思路”和“实现效果”。

举个例子，同样是说搜索功能：

用户搜索是失物招领系统使用频次较高的操作。为了提高检索效率，前端在搜索栏输入关键字后，通过防抖机制延迟发送请求，后端接收参数后对物品名称和描述字段进行模糊匹配，并按发布时间倒序返回结果。

这样的描述把技术方案、业务场景、用户体验串在了一起，论文看起来更有条理。核心就是：不是贴代码，而是说清你为了解决什么问题做了什么设计。

另外，论文附录里可以放主要数据库表和接口清单，正文里要留测试结果截图。测试表格是查重比例再高也能明显抬高分数的内容，尽量做一张“编号、测试项、测试步骤、预期结果、实际结果、是否通过”的完整表格，这种内容答辩老师会很认可。

7. 常见问题与避坑指南

7.1 数据库连接失败、时区问题排查

“Access denied for user”这类错误，往往不是代码问题，而是密码或权限问题。先检查application.yml中的数据库账号密码是否和 MySQL 里一致，再检查连接 URL 是否写对了库名。如果你在本机能连上但部署到服务器就连不上，要确认服务器 MySQL 的bind-address是否限制了只能本地连接，以及防火墙有没有放行 3306 端口。

时区问题也经常会遇到，插入一条记录后发现数据库里的create_time比当前时间慢了 8 小时。解决方法就是在连接串上加上serverTimezone=Asia/Shanghai，同时保证服务器或本机系统时区是东八区。这个问题不解决，列表页的时间显示就会跟真实时间对不上。

7.2 跨域与端口冲突：前端 9527、后端 8080 怎么配合

开发环境最常见的是 Vue 的 dev server 默认在 9527 端口，后端在 8080，前端请求时如果不加任何处理，必然跨域。解决方式有两个：

• 开发环境：在vue.config.js或 Vite 配置文件里设置 proxy，把/api请求转发到http://localhost:8080。
• 生产环境：用 Nginx 转发，这也是上面部署方案里做的事。

如果在后端用@CrossOrigin注解或者全局 CORS 配置，也可以在开发阶段省事，但生产环境会有安全隐患，不建议长期依赖。最理想的是开发环境用代理，生产环境用 Nginx，项目全程都不需要后端开启跨域。

端口冲突的话，Windows 上用：

netstat -ano | findstr 8080

找到占用 8080 的进程 PID，然后去任务管理器结束进程，或者启动后端时指定其他端口：

java -jar lostfound.jar --server.port=8081

7.3 分页查询与搜索不生效：配置和参数容易忽略

MyBatis-Plus 分了页但返回的 total 永远是 0，大概率是分页插件没有配置。需要新建一个 MybatisPlusConfig 类，加入PaginationInnerInterceptor：

@Configuration @MapperScan("com.example.lostfound.mapper") public class MybatisPlusConfig { @Bean public MybatisPlusInterceptor mybatisPlusInterceptor() { MybatisPlusInterceptor interceptor = new MybatisPlusInterceptor(); interceptor.addInnerInterceptor(new PaginationInnerInterceptor(DbType.MYSQL)); return interceptor; } }

搜索不生效，常见原因是LIKE查询时关键字拼错了。通过 QueryWrapper 调用like方法，MyBatis-Plus 会自动拼接%符号，不要自己在参数里再加%，否则会变成%%关键词%%，查不出来。还有 if 判断时要注意，参数为空的跳过该条件，避免搜索列表被条件卡住。

7.4 答辩常见提问整理：提前准备几个“掉分题”

答辩老师最常问的问题，不外乎下面几个：

• “你这个系统的创新点是什么？”不要只说用了 SpringBoot，可以说“设计了完整的状态流转机制、图片展示增强可信度、支持管理员审核、提供分类检索与分析统计”。
• “如果用户伪造他人身份怎么办？”回答思路：后端不信任前端传参，userId 从 token 获取；敏感操作需要再次确认密码或手机验证。
• “数据库表没有外键，如何保证数据一致性？”回答思路：逻辑外键 + Service 层事务控制，减少物理外键带来的性能开销。
• “这个项目和简单发帖论坛有什么区别？”回答思路：失物招领有发布审核、认领确认、状态闭环，不是简单信息发布。

很多同学对项目本身很熟，但一到“你觉得系统有什么不足”就卡住。这里的回答建议用“可扩展性”角度说：目前没有做消息实时通知，后续可以接入 WebSocket；搜索还是关键词匹配，后续可以引入词向量匹配；没有做移动端适配，后续可以做微信小程序。这既不是否定项目，又能展示自己思考过后续优化空间。

我个人在这次项目里的最大体会是：毕业设计最值钱的不是代码本身，而是“你能不能把一个完整业务的每一个环节讲清楚”。如果你只是把开源代码跑通，数据库结构、接口逻辑、部署流程说不明白，答辩时照样容易露馅。反过来，只要把需求拆透、表设计做扎实、核心业务状态流理清楚，哪怕代码比想象中朴素，整场答辩也会很稳。最后再分享一个小技巧：提前把演示环境部署好，录制一份备用演示视频，答辩现场无论是网络还是设备出问题，你都能从容切换过去，这比临时抱佛脚靠谱得多。