每年到了毕业设计季总有一批同学在“做什么题目”上卡住。想选个热门的方向怕撞车选小众的又怕做不出来。如果你正在纠结又恰好对文化、艺术、展览这类场景有点兴趣那 Spring Boot 艺术展览导览系统会是一个非常值得考虑的选题。它看起来是“内容展示 用户交互”这一类经典毕设项目但当你把“导览”这两个字拆开想清楚之后会发现里面可以做的深度远超预期。这篇文章我准备从一个真正带过大量毕设项目的角度把这个系统从需求设计、技术选型、数据库设计、核心功能实现到答辩加分项完整过一遍。不只是告诉你代码怎么写更重要的是告诉你为什么这样设计、哪些地方最容易踩坑、怎么才能从“能跑”变成“高分”。适合计算机专业准备毕设的学生也适合那些想通过一个完整项目把 Spring Boot 技术栈串起来练手的人哪怕你之前只是零零散散写过增删改查看完这篇也有足够的信息量去动手。1. 先把业务理顺艺术展览导览系统到底要解决什么问题很多人拿到这个题目第一反应就是“无非是做个展览列表点进去看展品详情后台再加个管理功能”于是直接开工建表写接口。这样做出来的东西不是不能用但答辩时老师只要问一句“你的系统解决了什么实际问题”你就很容易卡住。所以哪怕再急着写代码也得先想清楚业务背景。1.1 一个真实的观展场景设想一下你周末去一个美术馆看当代艺术展。现场大概率会遇到这么几个痛点入口处只有一张纸质导览图你根本分不清哪个展厅在哪个方向进到展馆里每件展品旁边只贴着一小段介绍文字看多了很容易走马观花如果碰上某些冷门展品既没有现场讲解员也没有语音导览设备基本等于白看。艺术展览导览系统解决的就是这些问题它把展览信息、展品信息、展厅位置、参观路线这些内容数字化用户可以在手机或电脑上提前了解展览内容、规划参观路线也可以到现场后扫码查看展品详细介绍。站在毕设角度去理解就是让这些信息在“平台管理员、注册用户、普通游客”三类角色之间有序流动。1.2 用户角色与核心功能梳理角色核心诉求对应功能游客未登录快速浏览展览和展品了解展览概况展览列表、展品列表、展品详情、展览检索注册用户收藏感兴趣的展品、参与互动、获得个性化导览记录登录注册、收藏展品、发表评论、扫码导览、个人中心管理员维护展览和展品数据掌握平台使用情况登录后台、展览管理、展品管理、展厅管理、用户管理、数据统计这里有一个容易被忽略的点为什么游客不登录也能看展品因为导览系统的核心是信息的“普惠触达”强制登录会大幅降低用户体验。但收藏、评论这类会产生用户数据的操作就必须要求登录。也就是说系统的权限设计应该遵循“浏览放宽、操作收紧”的原则这也是论文里写需求分析时可以展开讲的亮点。1.3 功能优先级排序做毕设最忌讳的就是功能铺得太开最后每个功能都做得稀碎。我给这个系统的功能排一个优先级P0 核心功能主干登录注册、展览信息展示、展品信息展示、后台管理。P1 重要功能丰富度收藏、评论、展品分类检索、分页查询。P2 加分功能亮点扫码导览、参观路线推荐、热门展品排行、数据可视化。如果你时间紧张优先保证 P0 和 P1如果你想拿高分P2 里至少挑一个做扎实。导览系统真正的亮点往往不在增删改查而在“扫码导览”和“路线推荐”这两个环节。2. 技术栈定盘Spring Boot 做底座ORM、前端框架和数据库到底怎么选这个系统核心后端就是 Spring Boot所以技术栈选择的核心矛盾主要集中在Spring Boot 用哪个版本、ORM 用 MyBatis-Plus 还是 JPA、前端是前后端分离还是用模板引擎、鉴权用 JWT 还是 Session。2.1 Spring Boot 版本别盲目追新先说一个大多数人都会踩的坑——版本选择。看到 Spring Boot 3.x 已经发布就顺手用了最新版结果发现 JDK8 用不了因为 Spring Boot 3.x 强制要求 JDK17。如果你本地装的是 JDK8又不想为了毕设折腾环境建议直接用 Spring Boot 2.7.x这也是现在国内绝大多数项目、教程和面试题还在使用的版本梯队。用 2.7.x 有几个实打实的优势资料多网上随便一搜就是完整配置和 MyBatis-Plus、Shiro、JWT 这些毕设常用库的兼容性经过充分验证你换一台电脑、换一个环境重新部署时踩坑概率低。版本落后一点在答辩里根本不是问题老师更关心你能不能讲清楚技术选型的理由。2.2 ORM 选型MyBatis-Plus 是最优解ORM 框架我建议直接用 MyBatis-Plus理由非常务实单表 CRUD 几乎不用写 SQLBaseMapper 直接给你提供现成方法开发效率高。分页查询、条件构造器、逻辑删除都是内置能力这几个功能在毕设里高频使用。国内使用人数多遇到问题搜解决方案特别容易。Spring Data JPA 也不是不行它的 Repository 接口设计确实很优雅但一旦涉及多表关联查询或者复杂动态条件JPQL 写起来并不比 SQL 直观。对于艺术展览导览系统这种“列表查询条件多、展品和展览关联复杂”的场景MyBatis-Plus 更顺手。2.3 前端形态从“能做完”的角度做选择前端有两种主流做法一是 Vue3 Element Plus 做前后端分离二是 Thymeleaf 模板引擎直接渲染服务端页面。我的建议是如果你对 Vue 已经有一定基础选前后端分离因为前端工程化和接口调用方式更接近真实企业项目论文里可写的内容也多比如跨域处理、Axios 请求封装、Vue Router 权限控制。如果你前端基础薄弱时间又紧就用 Thymeleaf在 Spring Boot 里写页面模板配合 BootStrap 也能做出够用的界面。这里我不劝你硬上前后端分离因为后端的核心知识点在 Spring Boot 这一侧前端只要保证界面整洁、交互清晰答辩就能过关。2.4 项目初始化与包结构新建项目时用 IDEA 自带的 Spring Initializr或者到 start.spring.io 生成都可以。关键是要把包结构提前规划好我常用的分包方式是这样com.exhibition ├── controller # 接口层 ├── service # 业务逻辑层 │ └── impl ├── mapper # MyBatis-Plus Mapper 接口 ├── entity # 数据表实体类 ├── dto # 前端入参对象 ├── vo # 接口返回对象 ├── config # 配置类拦截器、跨域等 ├── common # 公共类统一返回、异常处理、工具类 └── utils # JWT 工具、二维码工具等这种分层的好处是每一层职责单一代码可读性强答辩时画出“表示层-业务层-数据层”的架构图比只贴几个接口方法显得专业得多。哪怕你的业务逻辑很简单也要维持这个骨架后面加功能会轻松很多。核心依赖方面pom.xml 里至少要有这些dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency dependency groupIdcom.baomidou/groupId artifactIdmybatis-plus-boot-starter/artifactId version3.5.3/version /dependency dependency groupIdmysql/groupId artifactIdmysql-connector-j/artifactId scoperuntime/scope /dependency dependency groupIdorg.projectlombok/groupId artifactIdlombok/artifactId optionaltrue/optional /dependency dependency groupIdcom.auth0/groupId artifactIdjava-jwt/artifactId version3.19.2/version /dependency不要为了追求新版本把所有依赖全部拉到最新版本稳定比版本新重要得多。上面这一组是经过很多项目验证的搭配直接用基本不会出兼容性问题。3. 数据库设计展品、展览、展厅、导览记录是怎么串成一张网业务需求理清楚之后数据库设计就是整个项目的地基。很多同学在这里容易翻车要么表建得太少、字段缺失要么表建得太多、关系混乱。我从这个系统最核心的几类数据跟你逐一说清楚。3.1 核心表结构这个系统至少需要这些数据表user 用户表id、username、password、nickname、avatar、role管理员/普通用户、create_time。exhibition 展览表id、title、description、cover_image、start_date、end_date、location、status未开始/进行中/已结束。hall 展厅表id、name、location、description。exhibit 展品表id、exhibition_id、hall_id、name、author、era、material、size、description、image_url、audio_url、qr_code_url、sort_order。favorite 收藏表id、user_id、exhibit_id、create_time。comment 评论表id、user_id、exhibit_id、content、create_time。tour_record 导览记录表id、user_id、exhibit_id、scan_time。光看表名你可能觉得没什么特别但字段设计的细节才是关键我挑几个重点讲。3.2 极易踩坑的字段设计细节第一个关键点展品到底挂在展览下还是展厅下正确答案是“都要挂”。art exhibition 这个场景里展品既属于某一场展览决定它在展出生命周期中的逻辑归属又位于某一个展厅决定它的物理位置和导览路线。查询时用户可能是“看某场展览里有哪些展品”也可能是“看某个展厅里有哪些展品”。如果你只保留一个外键另一个查询就会变得非常痛苦。第二个关键点展品的展厅和展览之间的关系不要理解为一对多。一场大型展览会覆盖很多展厅所以你要设计 exhibition_hall 中间表把“展览-展厅”的多对多关系存起来。这个表很小但逻辑上非常关键没有它你很难做“按展厅导览”的功能。第三个关键点展品的位置信息怎么存。如果要实现路线推荐只存一个 hall_id 是不够的我建议加两个字段position_x 和 position_y用于表示展品在该展厅内的二维坐标。这听起来有点“地图系统”的味道但实现成本极低后续做路线规划时直接用这两个坐标参与计算。第四个关键点二维码存到数据库还是实时生成建议在新增展品时用 ZXing 工具生成二维码图片存储二维码图片路径到 exhibit 表同时把二维码内容设计为导览系统前端页面的 URL例如 http://localhost:8080/exhibit/detail/{exhibitId}。这样扫码打开页面时后端能根据展品 ID 直接返回详情并顺手写入一条 tour_record 记录。3.3 建表 SQL 示例我直接给你一段核心表的建表 SQL你可以在此基础上扩展CREATE TABLE exhibit ( id bigint(20) NOT NULL AUTO_INCREMENT, exhibition_id bigint(20) NOT NULL COMMENT 所属展览ID, hall_id bigint(20) DEFAULT NULL COMMENT 所属展厅ID, name varchar(100) NOT NULL COMMENT 展品名称, author varchar(50) DEFAULT NULL COMMENT 作者, era varchar(50) DEFAULT NULL COMMENT 年代, material varchar(100) DEFAULT NULL COMMENT 材质, size varchar(50) DEFAULT NULL COMMENT 尺寸, description text COMMENT 展品介绍, image_url varchar(255) DEFAULT NULL COMMENT 展品图片, audio_url varchar(255) DEFAULT NULL COMMENT 语音导览地址, qr_code_url varchar(255) DEFAULT NULL COMMENT 二维码地址, position_x decimal(10,2) DEFAULT NULL COMMENT 展厅内坐标X, position_y decimal(10,2) DEFAULT NULL COMMENT 展厅内坐标Y, sort_order int(11) DEFAULT 0 COMMENT 排序, create_time datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), KEY idx_exhibition_id (exhibition_id), KEY idx_hall_id (hall_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT展品表;CREATE TABLE tour_record ( id bigint(20) NOT NULL AUTO_INCREMENT, user_id bigint(20) NOT NULL COMMENT 用户ID, exhibit_id bigint(20) NOT NULL COMMENT 展品ID, scan_time datetime DEFAULT CURRENT_TIMESTAMP COMMENT 扫码时间, PRIMARY KEY (id), KEY idx_user_id (user_id), KEY idx_exhibit_id (exhibit_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT导览记录表;注意tour_record 表非常重要它是整个系统里最有“数据价值”的表。管理员可以通过统计 scan_time 的分布和 exhibit_id 的频次得出“今天哪个展品最受欢迎”“哪个时间段扫码人数最多”这些结论这也是论文里写数据分析和系统亮点的重要素材。3.4 表间关系一句话总结user 和 exhibit 通过 favorite、comment、tour_record 产生多对多联系exhibition 和 hall 通过 exhibition_hall 中间表关联exhibit 同时挂 exhibition 和 hall相当于把展览的“内容组织”和“空间组织”两个维度都覆盖了。数据库设计做到这个程度足够支撑你上面列出的所有功能。4. 核心实现从接口设计到路线推荐的落地代码技术栈和数据结构定了接下来就是最核心的部分功能怎么实现。这个系统里有一部分是常规 CRUD我不打算逐行贴代码重点讲几个值得展开的实现环节登录鉴权、分页查询、扫码导览和路线推荐。4.1 登录鉴权用 JWT 还是 Session毕设项目里我强烈推荐用 JWT 做登录鉴权。原因有两个一是 JWT 无状态服务端不需要存 Session天然适合前后端分离和移动端扫码场景二是论文里可以写“基于 Token 的无状态认证机制”这个技术名词在答辩时很加分。具体实现思路用户登录成功后使用 jjwt 或 java-jwt 生成一个 Token里面可以放 userId、username、role 这些关键信息。后端写一个拦截器HandlerInterceptor在 preHandle 方法里从请求头中读取 Authorization 字段解析并校验 Token。校验通过就把用户信息放到 ThreadLocal 或者 Request attribute 里方便 Controller 直接获取当前用户。对“游客可访问”的接口放行只拦截“需要登录”的接口比如收藏、评论、扫码记录。可能有人会问JWT 被截获怎么办实际上在毕设项目里不需要过度设计只要你把 Token 过期时间和签名密钥设置好基本安全已经足够。你甚至可以在密钥上做一个简单处理比如服务端配置一个自定义密钥字符串防止默认密钥轻易被破解。4.2 展品列表的接口设计展品列表是整个系统访问量最高的接口你要支持按展览筛选、按展厅筛选、按名称关键词搜索、按年代筛选还要分页返回。如果用 MyBatis-Plus代码会非常简洁GetMapping(/list) public ResultIPageExhibitVO list(ExhibitQueryDTO query) { PageExhibit page new Page(query.getPageNum(), query.getPageSize()); LambdaQueryWrapperExhibit wrapper new LambdaQueryWrapper(); wrapper.eq(query.getExhibitionId() ! null, Exhibit::getExhibitionId, query.getExhibitionId()) .eq(query.getHallId() ! null, Exhibit::getHallId, query.getHallId()) .like(StringUtils.hasText(query.getKeyword()), Exhibit::getName, query.getKeyword()) .orderByAsc(Exhibit::getSortOrder); IPageExhibit pageResult exhibitMapper.selectPage(page, wrapper); // 组装 VO包括展品图片、展览名称、展厅名称等 return Result.success(pageResult); }注意不要把 Excel 或 PDF 直接传给前端去渲染。接口返回的是一个 VOView Object里面除了展品本身字段还应该包含 exhibitionTitle、hallName 这类冗余展示字段。这个动作叫“组装 VO”是为了前端展示方便也能避免把不必要的字段直接暴露出去。4.3 扫码导览功能怎么落地扫码导览的技术链路是管理员上传展品时后端生成二维码 → 二维码内容是一个带展品ID的跳转地址 → 游客用手机扫码打开页面 → 后端返回展品详情并记录导览行为。二维码生成用 ZXing 即可核心逻辑public String generateQrCode(String url, String filePath) { int width 300; int height 300; String format png; MapEncodeHintType, Object hints new HashMap(); hints.put(EncodeHintType.CHARACTER_SET, UTF-8); try { BitMatrix bitMatrix new MultiFormatWriter().encode(url, BarcodeFormat.QR_CODE, width, height, hints); Path path Paths.get(filePath); if (!Files.exists(path.getParent())) { Files.createDirectories(path.getParent()); } MatrixToImageWriter.writeToPath(bitMatrix, format, path); return filePath; } catch (Exception e) { throw new RuntimeException(二维码生成失败, e); } }生成二维码时URL 里的 IP 地址或域名要写成局域网可访问的地址不然手机扫码打不开接口。这是实操中很容易忽略的一个点你在电脑上 localhost 访问没问题但手机扫码时访问 localhost 指向的是手机自己。记录导览行为的时机我建议在扫码打开详情页时做异步写入。比如点击详情页后调用 /tour/record 接口后端插入一条 tour_record。不要在前端渲染详情页本身里去同步写数据库因为这样会拖慢页面加载而且一旦失败会影响主流程。低成本做法是启动一个异步执行方法或者直接用 Spring 的 Async。4.4 路线推荐从“展厅挨个看”到“最短路径”路线推荐是艺术展览导览系统里最拿得出手的亮点功能哪怕你只用最朴素的算法实现也比纯展示功能高一档。最简单的实现方式把每个展厅看作一个节点展厅之间如果相邻就在图上连一条边展品坐标就是节点内部的点。然后根据用户要参观的展品集合先按展厅分组展厅层面用广度优先搜索BFS算出从一个展厅到另一个展厅的最短路径展厅内部再按 position_x 和 position_y 计算从入口到各个展品的顺序按“从左往右、从上往下”的 S 形路线走最终拼出一条完整导览路线。用文字描述就是用户选择若干想看的展品。按展厅分组得到展厅访问顺序。对每个展厅计算内部展品的访问顺序。拼装成一条带“大厅-展品A-展品B-展厅2-展品C…”的路线前端用地段导览页展示。如果你还想更炫一点可以引入 Dijkstra 算法计算最短路径。但说实话毕设里能讲清楚“为什么用图建模、为什么选择 BFS/Dijkstra”就已经很好了不一定非要实现一个复杂的路径规划引擎。答辩时老师更在意的往往是你有没有想清楚这个问题的建模方式。5. 安全与性能XSS 过滤、分页、版本冲突这些最容易翻车的细节做毕设时大家普遍会忽略安全性和性能优化但这恰恰是答辩老师最爱追问的区域。这里只挑三个高频问题展开每一个都是我见过真实翻车的点。5.1 全局过滤器处理上传 PDF 时的 XSS 攻击先说为什么会有这个需求。在导览系统里用户和管理员都可能上传内容比如评论文字、展品介绍甚至管理员上传包含 HTML 片段的 PDF 文件。如果后端接收到参数后没有做任何过滤直接存储再渲染到页面上就会形成存储型 XSS 漏洞。攻击者可以构造一段带有 script 标签的内容让其他用户打开页面时执行恶意脚本。过滤方案的核心是写一个 HttpServletRequestWrapper重写 getParameter、getParameterValues 和 getHeader 方法把敏感字符替换成转义字符public class XssFilterWrapper extends HttpServletRequestWrapper { public XssFilterWrapper(HttpServletRequest request) { super(request); } Override public String getParameter(String name) { String value super.getParameter(name); return cleanXss(value); } Override public String[] getParameterValues(String parameter) { String[] values super.getParameterValues(parameter); if (values null) { return null; } int count values.length; String[] encodedValues new String[count]; for (int i 0; i count; i) { encodedValues[i] cleanXss(values[i]); } return encodedValues; } private String cleanXss(String value) { // 过滤 等危险字符 if (value null || .equals(value)) { return value; } return value.replaceAll(, lt;).replaceAll(, gt;); } }然后在 WebMvcConfigurer 里注册这个过滤器注意过滤范围。这里最容易踩坑的是你如果对 multipart/form-data 这类文件上传请求也做参数重写会干扰文件内容解析。建议在过滤器里先判断请求 Content-Type如果是文件上传就直接放行只处理普通表单和 JSON 请求。5.2 分页插件配置与分页失效问题分页查询是毕设里跑不掉的场景。MyBatis-Plus 的分页不是天然生效的你必须显式配置分页插件这是最常见的坑。Configuration public class MybatisPlusConfig { Bean public MybatisPlusInterceptor mybatisPlusInterceptor() { MybatisPlusInterceptor interceptor new MybatisPlusInterceptor(); interceptor.addInnerInterceptor(new PaginationInnerInterceptor(DbType.MYSQL)); return interceptor; } }配置好之后使用 Page 对象作为第一个参数SQL 会自动追加 LIMIT。我见过很多同学忘了加这个配置导致查询结果被全部返回、接口响应几百条数据前台分页看起来像“假分页”。如果你在接口返回里看到了 total 字段和 records 字段但是发现永远查全量数据基本可以判断是分页插件配置缺失。5.3 Spring Boot 版本引发的连锁问题前文提过版本问题这里再补充几个具体的错误场景。第一个是“Cannot determine embedded database driver class for database type NONE”。出现这个错误通常是因为你引入了 spring-boot-starter-data-jpa但是没有配置数据源或者在启动类上加了不合适的注解。解决方案就是检查 application.yml 数据源配置是否完整。第二个是 Lua 脚本或 SQL 语法不兼容的报错通常是因为 MySQL 驱动版本和 Spring Boot 版本不匹配。Spring Boot 2.7.x 建议使用 mysql-connector-j 8.0.x 以上版本不要使用 5.x 老驱动否则容易出现连接超时或时区问题。第三个是 Lombok 报错提示“java: package lombok does not exist”或者构造函数找不到。大多数情况是 IDEA 的 Lombok 插件没装或者注解处理没有开启。新版本 IDEA 默认带 Lombok 插件但依赖版本也要对得上尽量选择 pom.xml 中明确的版本号。这些坑每一个单看都很小但叠加起来会消磨大量时间。我的建议是直接把整个项目导出一份“环境准备说明”文档把 JDK 版本、IDEA 版本、MySQL 版本、依赖版本全部固定下来避免换了一台电脑之后就崩。5.4 图片和二维码的静态资源映射还有一个非常容易被卡住的点展品图片、二维码图片上传后前端怎么访问默认 Spring Boot 只映射 classpath:/static、classpath:/public 这些目录。如果你把图片上传到了本地磁盘的 /data/uploads 目录直接访问是 404。解决方式是在配置类里加一个资源映射Configuration public class WebConfig implements WebMvcConfigurer { Value(${upload.path}) private String uploadPath; Override public void addResourceHandlers(ResourceHandlerRegistry registry) { registry.addResourceHandler(/upload/**) .addResourceLocations(file: uploadPath /); } }这个方法虽然只是几行代码但直接影响系统可用性。很多毕设项目图片显示不出来就是因为没加这个映射。6. 从“能跑”到“拿高分”论文结构、答辩提问和加分扩展代码写完了项目跑通了但这还不是终点。毕设的最终得分由系统和论文、答辩共同决定。很多同学功能做得挺全最后却因为论文没写好或者答辩表现一般被扣分非常可惜。6.1 论文结构怎么组织建议按下面这个框架写逻辑非常顺绪论写清楚文化艺术数字化趋势、传统导览方式的问题、系统开发意义。相关技术介绍Spring Boot、MyBatis-Plus、JWT、Vue、MySQL、二维码技术。需求分析用例图、功能需求、非功能需求安全性、易用性、性能。系统设计架构设计、功能模块划分、数据库设计E-R 图 表结构。系统实现把登录注册、展览管理、展品管理、导览路线、扫码导览等关键功能贴核心代码和截图。系统测试功能测试用例表、测试结果、问题及修复。论文最重要的不是字数多而是“逻辑闭环”你提出的每一个设计决策在系统实现里都要有对应你做的每一个功能在测试环节里都要有对应。建议在写论文前先画好数据库 ER 图和系统架构图这两张图基本决定了论文的骨架质量。6.2 答辩时老师喜欢问哪些问题我梳理了这份题目下高概率会被问到的几个问题你可以提前准备好答案“为什么选择 Spring Boot 而不是传统的 SSM 框架”——回答方向Spring Boot 简化了配置内嵌 Tomcat起步依赖管理方便更符合现代 Java 开发习惯。同时你项目的核心知识点仍是 Spring MVC Spring MyBatis底层并没有丢。“MyBatis-Plus 和 MyBatis 有什么区别”——回答方向MP 在 MyBatis 基础上提供了 BaseMapper 泛型 CRUD 方法、条件构造器、分页插件开发效率更高底层还是 MyBatis 的 SQL 映射机制。“如果你的系统并发量大了怎么办”——回答方向先从数据库层面加索引、优化 SQL再到应用层加 Redis 缓存热点数据再到把静态资源存 CDN 或对象存储。不要一上来就说加微服务那反而暴露你对微服务理解不深。“二维码可以被伪造吗你怎么控制”——回答方向二维码内容本身是一个带 ID 的 URL如果有人恶意扫描大量二维码会在导览记录表产生垃圾数据。可以采取两个手段一是二维码内容里加入签名参数服务端校验签名合法性二是对导览记录写入做简单的接口频率限制。“路线推荐算法是怎么设计的”——回答方向把展厅建模成图展品建模成节点内部对象用 BFS 或 Dijkstra 求最短展厅路径展厅内部用坐标排序规划参观顺序。时间复杂度取决于展厅数和展品数完全在可控范围内。6.3 加分扩展三个方向让项目真正“亮”起来如果你的时间还充裕想在答辩时拿出几个超出预期的点我推荐做以下三个方向中的任意一个第一给热门展品做 Redis 缓存。在展品接口上先用缓存查询命不中再查数据库并把热点数据回填到 Redis。这个操作非常简单但体现了“性能优化”意识。第二用 ECharts 做一个管理端数据可视化大屏统计每日扫码人数、热门展品 Top10、各展厅访问量。管理员看到这种界面会印象很好论文里的“数据分析和决策支持”章节也有了素材。第三把导览记录做得再细一点比如记录用户扫码后的停留时长。后端可以在展品详情页埋点进入时记时间离开时再上报一次。这样能分析用户对哪些展品更感兴趣导出报表后就是一个小型“用户行为分析”系统。6.4 交付前的检查清单在提交和答辩之前一定要按下面的清单逐项检查我发现太多人到最后关头才发现低级问题application.yml 里的数据库密码是否硬编码了如果演示时换电脑能不能一键改配置。项目是否可以从 GitHub 或 Gitee 仓库完整 clone 后启动缺不缺 SQL 初始化脚本所有测试账号是不是都能正常登录演示时网络不好本地跑能不能撑住。上传的图片和二维码是否能在另一台电脑上正常访问图片路径是否写死了绝对路径导出 SQL 脚本时有没有包含建库语句数据库编码是不是 utf8mb4前端页面在手机浏览器上布局是否正常扫码导览的场景通常是手机端。把这些都检查完你答辩时才能自信地说“这个系统是可交付的”。最后说点我个人的体会。每次帮人看毕业设计我都会强调一句话毕设不是把功能堆出来就完事真正的价值在于你能把这个系统从头到尾讲明白。数据库为什么要这么建、JWT 为什么比 Session 适合、XSS 过滤器是在哪个环节生效、路线推荐为什么这样建模——这些问题如果能通顺地回答出来你这段经历才真正成了你的东西。分享一个特别实用的技巧从项目开启动手的那一刻就建一个“开发日志”文档每天记录遇到的坑和解决方案。答辩时老师一问“你遇到的最大困难是什么”你直接把日志里最有价值的那个坑讲出来说自己怎么定位、怎么解决、为什么这样解决这种真实细节比你复制任何“项目难点”模板都有说服力。祝你的毕设项目既能顺利通过也能让你真正把 Spring Boot 这条技术栈彻底吃透。