“计算机毕业设计Spring Boot重庆旅游景点管理系统”——这个题目放在毕业设计选题池里,属于一眼就能看出“能过”的题目业务场景具体、用户群体清晰、技术栈主流、演示效果还自带“网红城市”的视觉吸引力。很多同学看到“重庆旅游”“景点信息管理”就默认这是个简单的CRUD项目实际上想拿高分得把它做成“有数据关系的业务系统”而不是“单表增删改查的练习册”。这篇就按我自己的实践经验把这个题目的完整设计思路、核心功能拆解、数据库设计、关键代码实现、答辩亮点和踩坑记录一次性讲透。适合选题阶段拿不定主意的也适合已经开题、正卡在某个模块不知道怎么下手的朋友。1. 项目整体设计与功能拆解1.1 先想清楚这到底是个“管理系统”还是“服务平台”标题里同时出现了“信息管理系统”和“综合服务平台”两种描述很多人不以为意直接开写结果做着做着发现要么功能太少撑不起工作量要么功能堆得乱七八糟没有主线。我的建议是用“双端思维”来做这个项目也就是把系统拆成面向游客的前端展示与服务端和面向运营人员的后台管理端。游客端前台门户景点列表、景点详情、搜索筛选、在线评论、收藏、门票预约/购票下单、个人中心。管理端后台景点信息发布与维护、景点类别管理、订单审核、评论管理、用户管理、数据统计看板。为什么要这样做因为毕业设计的评分逻辑里“功能完整性”和“业务逻辑闭环”是两块大头。如果你只做了一个景点信息的增删改查那评委只需要问三个问题就会把你问住用户从哪里进来数据怎么产生管理动作落在哪里双端设计天然能回答这些问题游客产生行为数据管理端对数据进行管理和审核系统形成一个完整的业务闭环。1.2 功能模块怎么分才能既不冗余又不漏项我推荐把整个系统拆成六大核心模块每个模块都能对应到数据库表这种“一模块一表”的方式也方便后期写文档和画ER图模块核心功能对应数据表用户模块注册、登录、个人信息修改t_user景点模块景点发布、分类、详情展示、搜索t_spot, t_category评论模块游客评论、回复、后台审核t_comment收藏模块景点收藏/取消收藏t_favorite预约/订单模块门票预约、订单生成、状态流转t_order统计模块访问量统计、订单量统计、热门景点排行定时统计或SQL聚合关于权限不要一上来就想着做复杂的RBAC权限模型。毕业设计阶段用户角色分为管理员和普通用户两类就足够了管理员直接通过role字段区分。Spring Boot的拦截器或Spring Security按角色放行接口简单直接还方便答辩时口头说明。1.3 为什么“景点标签”和“路线推荐”值得做这是我要重点强调的差异化设计。重庆的旅游景点有一个很典型的特点——地域集中性渝中区的洪崖洞、解放碑、长江索道往往被游客安排在同一天游览而武隆、大足石刻又属于远郊线路。如果只是把景点列表平铺展示系统跟“电话黄页”没有区别。给景点加上tags字段比如“网红打卡”“夜景”“红色旅游”“自然风光”“亲子游”然后在前台做一个“热门路线推荐”功能按区域分组、按标签聚类甚至实现一个简单的“根据用户收藏的景点类型推荐相似景点”。这个功能不需要多复杂的算法基于标签的简单匹配就能做出来但它的存在让整个项目的“信息管理”上升到了“信息应用”的层面答辩时特别好讲。2. 核心技术实现与方案选型2.1 Spring Boot项目分层别在Controller里写业务这个题目用的是Spring Boot那项目的包结构就得符合Spring Boot的开发规范。我自己习惯的分层是controller / service / mapper / entity / common / config其中entity里放数据库实体类字段命名与表字段驼峰对应mapper层用MyBatis-Plus的话继承BaseMapperT就能获得CRUD能力service层写业务逻辑事务注解Transactional加在需要保证原子性的方法上controller层只负责接收参数、调用服务、返回统一结果。有个高频错误需要特别注意很多同学在写查询景点列表时直接把分页查询的逻辑写在Controller里参数校验、业务判断也全部堆在里面一个Controller类几百行起步。这不是代码能不能跑的问题而是答辩时老师看了代码就会皱眉的问题。分层清晰的项目功能改动时只需要替换对应的Service实现这种“可维护性”是毕业设计评分里的隐性加分项。2.2 认证和权限建议用JWT 拦截器而不是Session重庆旅游景点系统的用户端是典型的“前后端分离”场景如果还沿用HttpSession那套跨域配置和会话共享都是麻烦事。我实践下来最顺的方案是用户登录成功后服务端生成JWT返回给前端前端存储在localStorage里后续请求在HTTP头里带上token后端写一个拦截器实现HandlerInterceptor接口在preHandle里校验token解析出用户ID存入ThreadLocal或request属性中对管理员接口做额外的角色判断。选JWT要注意密钥配置在application.yml里不要写死在代码中设置合理的过期时间比如24小时不要忘记让“记住我”功能的用户重新登录。另外建议引入jjwt库0.9.1版本和0.11.5版本的API差别较大按自己的JDK版本选择即可我用的是io.jsonwebtoken:jjwt-api、jjwt-impl、jjwt-jackson三件套。2.3 Redis缓存把热点景点数据从数据库里“解放”出来景点的详情页通常是访问量最大的接口如果每次请求都去查询数据库在高并发场景下数据库连接池会被瞬时打满。使用Redis做缓存是一个特别好讲且特别能加分的技术点。具体做法是在查询景点详情的Service方法中先查Redis缓存使用景点ID作为key如果缓存命中直接返回结果如果未命中查询数据库并写入缓存同时设置过期时间比如30分钟后台管理端更新景点信息时主动删除对应ID的缓存保证数据一致性。实际开发中注意缓存穿透的问题比如查询一个不存在的景点ID每次都查数据库。解决方案是在缓存中设置空值过期时间短一些或者使用布隆过滤器——毕业设计讲清楚“缓存空值”就够了。2.4 图片上传与展示本地存储比云OSS更容易通过答辩景点的一大核心内容是图片但很多同学容易在这上面踩坑选了阿里云OSS、腾讯云COS结果需要配置密钥、需要实名认证、还可能因为欠费导致图片不可访问。我的建议是本地存储就够了。在Spring Boot配置类中设置资源映射将/upload/**路径映射到本机的src/main/resources/static/upload/目录后台管理端上传的图片文件保存到本地返回可访问的URL路径存到数据库。注意控制图片大小通过MultipartFile接口获取文件使用UUID重命名避免文件名冲突。如果要展示重庆夜景、洪崖洞这类景点图片本地存储不影响演示效果同时免去了外部服务的依赖答辩时环境搭建也更稳定。3. 实操过程与关键环节实现3.1 项目初始化从Spring Initializr到跑通第一个接口创建一个Spring Boot项目时建议直接访问Spring Initializrstart.spring.io选择依赖Spring Web、MyBatis-Plus、MySQL Driver、Redis可选、Lombok、Validation。如果是用IDEA直接在New Project里选择Spring Initializr也完全一样。需要注意Spring Boot 2.x和3.x的区别3.x版本要求JDK 17且javax包名改成了jakarta。毕业设计环境建议使用Spring Boot 2.7.x JDK 1.8/11的组合网上资料多、遇到问题好搜、兼容性好。生成项目后先做两个验证编写一个TestController启动项目访问/test接口确认Web环境正常配置application.yml中的数据源编写一个测试查询确认MyBatis-Plus能连上MySQL。很多同学在这一步就卡住了报错往往集中在Maven依赖下载失败、数据库连接失败、端口被占用三种情况。先说Maven依赖下载失败检查IDEA的Maven设置确认使用的是阿里云镜像仓库数据库连接失败检查MySQL服务是否启动、用户名密码是否正确、是否创建了数据库端口被占用修改server.port为其他端口。3.2 数据库设计8张表把业务串起来重庆旅游景点系统的数据库设计我给出一个经过验证的8张表方案-- 用户表 CREATE TABLE t_user ( id INT PRIMARY KEY AUTO_INCREMENT, username VARCHAR(50) NOT NULL UNIQUE, password VARCHAR(100) NOT NULL, nickname VARCHAR(50), avatar VARCHAR(255), phone VARCHAR(20), email VARCHAR(50), role TINYINT DEFAULT 0, -- 0普通用户 1管理员 status TINYINT DEFAULT 1, create_time DATETIME ); -- 景点分类表 CREATE TABLE t_category ( id INT PRIMARY KEY AUTO_INCREMENT, name VARCHAR(50) NOT NULL, sort INT DEFAULT 0, create_time DATETIME ); -- 景点信息表 CREATE TABLE t_spot ( id INT PRIMARY KEY AUTO_INCREMENT, category_id INT, name VARCHAR(100) NOT NULL, cover VARCHAR(255), images TEXT, description TEXT, address VARCHAR(255), area VARCHAR(50), -- 所属区域如渝中区、武隆区 tags VARCHAR(100), -- 景点标签 price DECIMAL(10,2), open_time VARCHAR(100), traffic_info TEXT, view_count INT DEFAULT 0, status TINYINT DEFAULT 1, create_time DATETIME ); -- 评论表 CREATE TABLE t_comment ( id INT PRIMARY KEY AUTO_INCREMENT, user_id INT, spot_id INT, content TEXT, reply_content TEXT, create_time DATETIME, status TINYINT DEFAULT 1 -- 默认为1显示管理员可设为0隐藏 );新增加的三张表——收藏表、订单表、信息统计表——就与业务闭环紧密相关-- 收藏表 CREATE TABLE t_favorite ( id INT PRIMARY KEY AUTO_INCREMENT, user_id INT NOT NULL, spot_id INT NOT NULL, create_time DATETIME, UNIQUE KEY uk_user_spot (user_id, spot_id) ); -- 预约/订单表 CREATE TABLE t_order ( id INT PRIMARY KEY AUTO_INCREMENT, order_no VARCHAR(32) NOT NULL, user_id INT NOT NULL, spot_id INT NOT NULL, visit_date DATE, ticket_count INT DEFAULT 1, total_price DECIMAL(10,2), status TINYINT DEFAULT 0, -- 0待确认 1已确认 2已取消 create_time DATETIME );表之间建立外键关系不是必须的但业务查询时要通过JOIN关联用户表获得用户昵称、关联景点表获得景点名称。3.3 核心业务代码景点列表与搜索接口的实现景点列表是前台的核心接口我直接贴一段实际的Service代码思路Override public PageResultSpotVO getSpotPage(SpotQuery query) { PageSpot page new Page(query.getPageNum(), query.getPageSize()); LambdaQueryWrapperSpot wrapper new LambdaQueryWrapper(); // 关键词搜索模糊匹配景点名称或描述 if (StringUtils.hasText(query.getKeyword())) { wrapper.like(Spot::getName, query.getKeyword()) .or().like(Spot::getDescription, query.getKeyword()); } // 按分类筛选 if (query.getCategoryId() ! null) { wrapper.eq(Spot::getCategoryId, query.getCategoryId()); } // 按区域筛选 if (StringUtils.hasText(query.getArea())) { wrapper.eq(Spot::getArea, query.getArea()); } // 按状态筛选只查询上架景点 wrapper.eq(Spot::getStatus, 1); wrapper.orderByDesc(Spot::getViewCount); PageSpot result spotMapper.selectPage(page, wrapper); // 组装VO补充分类名称、收藏状态等字段 PageResultSpotVO pageResult new PageResult(); pageResult.setTotal(result.getTotal()); pageResult.setRecords(convertToVO(result.getRecords())); return pageResult; }这里有一个容易翻车的细节用like加or()条件时要注意QueryWrapper的条件组合问题如果后面还有其他eq条件建议用and(condition)包裹模糊查询条件避免SQL条件优先级错乱。景点详情的缓存实现可以这样public SpotVO getSpotDetail(Integer id) { // 1. 先取缓存 String cacheKey spot:detail: id; String cacheValue redisTemplate.opsForValue().get(cacheKey); if (cacheValue ! null) { return JSON.parseObject(cacheValue, SpotVO.class); } // 2. 缓存未命中查询数据库 Spot spot spotMapper.selectById(id); if (spot null) { // 3. 缓存空值防止穿透 redisTemplate.opsForValue().set(cacheKey, , 5, TimeUnit.MINUTES); return null; } // 更新浏览量 spotMapper.updateViewCount(id); SpotVO vo convertToVO(spot); // 4. 写入缓存过期时间30分钟 redisTemplate.opsForValue().set( cacheKey, JSON.toJSONString(vo), 30, TimeUnit.MINUTES ); return vo; }这段代码虽然不长但包含缓存命中、缓存空值防穿透、浏览量异步更新三个技术细节每个细节都能在答辩时展开讲。3.4 前端页面怎么搭Bootstrap Thymeleaf还是Vue分离两种方案都可行但我强烈建议结合自身前端基础来选择。方案一后端渲染使用Thymeleaf模板引擎 Bootstrap jQuery。这种方案的优点是开发速度快不需要考虑跨域问题一个Spring Boot工程搞定前后端。缺点是页面交互体验相对单一但这对于毕业设计来说已经足够了。方案二前后端分离前端使用Vue 3 Element Plus。如果你之前学过Vue或者想通过毕业设计锻炼前后端分离的能力这个方案更好。前后端分离的难点不在Vue本身而在跨域配置、token传递、接口联调前期搭建成本比方案一高。我的看法毕业设计的核心是展示你对业务和技术的理解而不是前端动画多酷炫。如果时间不够或前端基础薄弱选择方案一把精力放在后端业务逻辑和数据设计上性价比最高。如果你已经具备一定的Vue基础选择方案二会让项目整体“技术含量”更上一层楼——特别是JWT认证机制在前后端分离场景下更自然。前端页面至少需要游客端首页景点瀑布流、景点详情页、登录注册页、个人中心我的收藏、我的订单后台管理端页面仪表盘统计卡片趋势图、景点管理表格、分类管理、评论审核、订单管理。图表可以用ECharts折线图和柱状图各做一个统计模块瞬间就立体了。3.5 别忘了界面设计也可以“讲重庆故事”重庆旅游景点的系统界面配色和元素可以做得很讨巧。深红色和橙色是重庆的城市底色——火锅、洪崖洞夜景、山城光影——用在导航栏和按钮主色上页脚放一个重庆经典地标的水印或插画景点卡片上显示所在区县的小角标。这些细节不增加技术复杂度但能让系统“一眼就能看出是做重庆旅游的”这在项目展示环节很加分。另外建议在后台管理端增加“景点审核”功能景点不是后台直接提交发布而是需要管理员二次确认后才在前台展示。这个流程虽然简单但是否有“审核”概念直接决定评委对你的系统定位是“个人博客”还是“企业级业务系统”。4. 常见问题与避坑指南4.1 数据库设计阶段最容易犯的错我帮人看过很多份毕设代码发现数据库设计问题主要集中在没有设计逻辑删除字段前台删除景点时真的把数据从表里物理删除了导致关联的订单和评论直接失去外键目标。正确做法是每个表都加deleted字段使用MyBatis-Plus的逻辑删除配置。时间和金额类型乱用时间都用DATETIME而不用TIMESTAMPTIMESTAMP只能表示到2038年虽然离现在远但答辩老师可能会问金额一律DECIMAL(10,2)禁止用FLOAT和DOUBLE。不设索引t_comment表的spot_id、t_favorite表的user_id、t_order表的外键字段都应该加普通索引。数据量大了之后没有索引的查询就是全表扫描这个细节在答辩时假如老师问“你能说说怎么优化查询性能吗”有没有索引就是分水岭。4.2 接口开发阶段的典型问题接口开发时我遇到过不少坑整理成几个高频问题供自查日期格式化问题后端返回的DATETIME字段默认是2025-01-01T12:00:00这种格式。在application.yml中配置spring.jackson.date-formatyyyy-MM-dd HH:mm:ss和time-zoneGMT8即可解决。跨域问题前后端分离场景写一个WebMvcConfigurer实现addCorsMappings或者用CrossOrigin注解在Controller上。注意如果使用了JWT拦截器跨域预检请求OPTIONS需要直接放行否则前端浏览器会报跨域错误这是初学者最容易忽略的问题。空指针异常查询用户信息、景点信息时先判断是否为null再继续操作或者用Optional优雅处理。事务失效同类中方法的自调用不会触发事务代理确保Transactional加在Service的public方法上。4.3 答辩的时候怎么“讲出亮点”很多同学做完项目却不知道怎么讲站在台上只会演示页面。我有一个建议准备3个“技术故事”每个故事由“遇到的问题 我的方案 效果/收获”三部分组成。比如第一个故事系统在做景点详情页时发现高访问量导致数据库压力大于是引入Redis缓存热点数据并解决了缓存穿透问题接口响应时间从300ms降到50ms以内。这个故事要在答辩时主动讲出来不要等老师问。第二个故事系统设计时将用户角色分为普通用户和管理员通过JWT实现无状态认证保证了前后端分离架构下接口的安全性。第三个故事在景点推荐功能中通过标签匹配实现了基于内容的推荐逻辑比如收藏了“洪崖洞”的用户会收到“夜景类”景点的推荐为后续引入协同过滤算法预留了扩展空间。把这三个故事讲清楚你的毕业设计就不仅仅是“做了一个系统”而是“用技术手段解决了一个业务场景中的实际问题”。4.4 毕设时间规划与常见注意事项速查表阶段周期建议产出物需求分析与文档3~5天开题报告、需求规格说明数据库设计2~3天数据库设计文档、SQL脚本后端核心功能10~15天可运行的接口、测试前端页面开发7~10天页面原型、前后端联调测试与演示准备5~7天测试报告、演示PPT、项目部署包每天保持至少2小时的编码时间不要试图最后两周冲刺尤其是遇到环境问题、依赖冲突、以及各种“明明照着视频写为什么报错”的问题解决起来非常耗时。4.5 我想单独拿出来说的几个“过来人”经验第一写代码前一定要先把数据库表设计出来表设计决定了整个项目的天花板。很多同学边写边改表改到后面表之间关系乱成一锅粥Service层全是拼接SQL的补丁代码。这个项目的业务逻辑不复杂花半天时间认真设计表结构后面所有接口都会很顺畅。第二推荐使用MyBatis-Plus而非原生MyBatis。原生MyBatis需要手写大量XML映射文件对很多同学来说既枯燥又容易出错。MyBatis-Plus的BaseMapper自动提供增删改查分页用Page对象条件构造用LambdaQueryWrapper开发效率高一个档次。第三版本锁定要特别小心JDK、Spring Boot、MyBatis-Plus、MySQL驱动之间的版本兼容性问题。比如Spring Boot 3.x必须搭配MyBatis-Plus 3.5.3版本否则启动直接报错。建议一上来就锁定一个经过验证的版本组合JDK 11 Spring Boot 2.7.18 MyBatis-Plus 3.5.3.2 MySQL 8.0。第四在“首页接入地图展示”这个功能上尽量用高德地图JavaScript API或百度地图的普通标注功能定位到重庆的主要景点坐标做成初始化标注点即可。地图API本身免费、不用企业认证演示效果却非常突出——毕竟景点都是真实存在的物理位置看到地图上散布的景点标记“综合服务平台”这个定位一下子就立住了。第五给自己的Git仓库做“小而频繁”的提交每次修改一个功能就commits一次。这不仅是为了防代码丢失更重要的是答辩前如果需要整理开发过程Git历史记录就是你最真实的开发日志。这个项目做完Spring Boot的核心机制、MyBatis-Plus的常见用法、Redis的实际应用、甚至前后端交互的一些细节基本就都能串起来了。我见过很多选题看着唬人的项目最后做成一堆散装代码也见过这个题目被认认真真做出平台感的作品。差别不在于题目本身而在于有没有把“数据结构、业务逻辑、技术方案”想清楚再动手。按照这篇文章的思路走你拿到的就不只是一个能运行的毕设demo而是一套真正能讲出设计逻辑的完整系统。
Spring Boot重庆旅游景点管理系统毕业设计：双端架构与核心实现
“计算机毕业设计Spring Boot重庆旅游景点管理系统”——这个题目放在毕业设计选题池里,属于一眼就能看出“能过”的题目业务场景具体、用户群体清晰、技术栈主流、演示效果还自带“网红城市”的视觉吸引力。很多同学看到“重庆旅游”“景点信息管理”就默认这是个简单的CRUD项目实际上想拿高分得把它做成“有数据关系的业务系统”而不是“单表增删改查的练习册”。这篇就按我自己的实践经验把这个题目的完整设计思路、核心功能拆解、数据库设计、关键代码实现、答辩亮点和踩坑记录一次性讲透。适合选题阶段拿不定主意的也适合已经开题、正卡在某个模块不知道怎么下手的朋友。1. 项目整体设计与功能拆解1.1 先想清楚这到底是个“管理系统”还是“服务平台”标题里同时出现了“信息管理系统”和“综合服务平台”两种描述很多人不以为意直接开写结果做着做着发现要么功能太少撑不起工作量要么功能堆得乱七八糟没有主线。我的建议是用“双端思维”来做这个项目也就是把系统拆成面向游客的前端展示与服务端和面向运营人员的后台管理端。游客端前台门户景点列表、景点详情、搜索筛选、在线评论、收藏、门票预约/购票下单、个人中心。管理端后台景点信息发布与维护、景点类别管理、订单审核、评论管理、用户管理、数据统计看板。为什么要这样做因为毕业设计的评分逻辑里“功能完整性”和“业务逻辑闭环”是两块大头。如果你只做了一个景点信息的增删改查那评委只需要问三个问题就会把你问住用户从哪里进来数据怎么产生管理动作落在哪里双端设计天然能回答这些问题游客产生行为数据管理端对数据进行管理和审核系统形成一个完整的业务闭环。1.2 功能模块怎么分才能既不冗余又不漏项我推荐把整个系统拆成六大核心模块每个模块都能对应到数据库表这种“一模块一表”的方式也方便后期写文档和画ER图模块核心功能对应数据表用户模块注册、登录、个人信息修改t_user景点模块景点发布、分类、详情展示、搜索t_spot, t_category评论模块游客评论、回复、后台审核t_comment收藏模块景点收藏/取消收藏t_favorite预约/订单模块门票预约、订单生成、状态流转t_order统计模块访问量统计、订单量统计、热门景点排行定时统计或SQL聚合关于权限不要一上来就想着做复杂的RBAC权限模型。毕业设计阶段用户角色分为管理员和普通用户两类就足够了管理员直接通过role字段区分。Spring Boot的拦截器或Spring Security按角色放行接口简单直接还方便答辩时口头说明。1.3 为什么“景点标签”和“路线推荐”值得做这是我要重点强调的差异化设计。重庆的旅游景点有一个很典型的特点——地域集中性渝中区的洪崖洞、解放碑、长江索道往往被游客安排在同一天游览而武隆、大足石刻又属于远郊线路。如果只是把景点列表平铺展示系统跟“电话黄页”没有区别。给景点加上tags字段比如“网红打卡”“夜景”“红色旅游”“自然风光”“亲子游”然后在前台做一个“热门路线推荐”功能按区域分组、按标签聚类甚至实现一个简单的“根据用户收藏的景点类型推荐相似景点”。这个功能不需要多复杂的算法基于标签的简单匹配就能做出来但它的存在让整个项目的“信息管理”上升到了“信息应用”的层面答辩时特别好讲。2. 核心技术实现与方案选型2.1 Spring Boot项目分层别在Controller里写业务这个题目用的是Spring Boot那项目的包结构就得符合Spring Boot的开发规范。我自己习惯的分层是controller / service / mapper / entity / common / config其中entity里放数据库实体类字段命名与表字段驼峰对应mapper层用MyBatis-Plus的话继承BaseMapperT就能获得CRUD能力service层写业务逻辑事务注解Transactional加在需要保证原子性的方法上controller层只负责接收参数、调用服务、返回统一结果。有个高频错误需要特别注意很多同学在写查询景点列表时直接把分页查询的逻辑写在Controller里参数校验、业务判断也全部堆在里面一个Controller类几百行起步。这不是代码能不能跑的问题而是答辩时老师看了代码就会皱眉的问题。分层清晰的项目功能改动时只需要替换对应的Service实现这种“可维护性”是毕业设计评分里的隐性加分项。2.2 认证和权限建议用JWT 拦截器而不是Session重庆旅游景点系统的用户端是典型的“前后端分离”场景如果还沿用HttpSession那套跨域配置和会话共享都是麻烦事。我实践下来最顺的方案是用户登录成功后服务端生成JWT返回给前端前端存储在localStorage里后续请求在HTTP头里带上token后端写一个拦截器实现HandlerInterceptor接口在preHandle里校验token解析出用户ID存入ThreadLocal或request属性中对管理员接口做额外的角色判断。选JWT要注意密钥配置在application.yml里不要写死在代码中设置合理的过期时间比如24小时不要忘记让“记住我”功能的用户重新登录。另外建议引入jjwt库0.9.1版本和0.11.5版本的API差别较大按自己的JDK版本选择即可我用的是io.jsonwebtoken:jjwt-api、jjwt-impl、jjwt-jackson三件套。2.3 Redis缓存把热点景点数据从数据库里“解放”出来景点的详情页通常是访问量最大的接口如果每次请求都去查询数据库在高并发场景下数据库连接池会被瞬时打满。使用Redis做缓存是一个特别好讲且特别能加分的技术点。具体做法是在查询景点详情的Service方法中先查Redis缓存使用景点ID作为key如果缓存命中直接返回结果如果未命中查询数据库并写入缓存同时设置过期时间比如30分钟后台管理端更新景点信息时主动删除对应ID的缓存保证数据一致性。实际开发中注意缓存穿透的问题比如查询一个不存在的景点ID每次都查数据库。解决方案是在缓存中设置空值过期时间短一些或者使用布隆过滤器——毕业设计讲清楚“缓存空值”就够了。2.4 图片上传与展示本地存储比云OSS更容易通过答辩景点的一大核心内容是图片但很多同学容易在这上面踩坑选了阿里云OSS、腾讯云COS结果需要配置密钥、需要实名认证、还可能因为欠费导致图片不可访问。我的建议是本地存储就够了。在Spring Boot配置类中设置资源映射将/upload/**路径映射到本机的src/main/resources/static/upload/目录后台管理端上传的图片文件保存到本地返回可访问的URL路径存到数据库。注意控制图片大小通过MultipartFile接口获取文件使用UUID重命名避免文件名冲突。如果要展示重庆夜景、洪崖洞这类景点图片本地存储不影响演示效果同时免去了外部服务的依赖答辩时环境搭建也更稳定。3. 实操过程与关键环节实现3.1 项目初始化从Spring Initializr到跑通第一个接口创建一个Spring Boot项目时建议直接访问Spring Initializrstart.spring.io选择依赖Spring Web、MyBatis-Plus、MySQL Driver、Redis可选、Lombok、Validation。如果是用IDEA直接在New Project里选择Spring Initializr也完全一样。需要注意Spring Boot 2.x和3.x的区别3.x版本要求JDK 17且javax包名改成了jakarta。毕业设计环境建议使用Spring Boot 2.7.x JDK 1.8/11的组合网上资料多、遇到问题好搜、兼容性好。生成项目后先做两个验证编写一个TestController启动项目访问/test接口确认Web环境正常配置application.yml中的数据源编写一个测试查询确认MyBatis-Plus能连上MySQL。很多同学在这一步就卡住了报错往往集中在Maven依赖下载失败、数据库连接失败、端口被占用三种情况。先说Maven依赖下载失败检查IDEA的Maven设置确认使用的是阿里云镜像仓库数据库连接失败检查MySQL服务是否启动、用户名密码是否正确、是否创建了数据库端口被占用修改server.port为其他端口。3.2 数据库设计8张表把业务串起来重庆旅游景点系统的数据库设计我给出一个经过验证的8张表方案-- 用户表 CREATE TABLE t_user ( id INT PRIMARY KEY AUTO_INCREMENT, username VARCHAR(50) NOT NULL UNIQUE, password VARCHAR(100) NOT NULL, nickname VARCHAR(50), avatar VARCHAR(255), phone VARCHAR(20), email VARCHAR(50), role TINYINT DEFAULT 0, -- 0普通用户 1管理员 status TINYINT DEFAULT 1, create_time DATETIME ); -- 景点分类表 CREATE TABLE t_category ( id INT PRIMARY KEY AUTO_INCREMENT, name VARCHAR(50) NOT NULL, sort INT DEFAULT 0, create_time DATETIME ); -- 景点信息表 CREATE TABLE t_spot ( id INT PRIMARY KEY AUTO_INCREMENT, category_id INT, name VARCHAR(100) NOT NULL, cover VARCHAR(255), images TEXT, description TEXT, address VARCHAR(255), area VARCHAR(50), -- 所属区域如渝中区、武隆区 tags VARCHAR(100), -- 景点标签 price DECIMAL(10,2), open_time VARCHAR(100), traffic_info TEXT, view_count INT DEFAULT 0, status TINYINT DEFAULT 1, create_time DATETIME ); -- 评论表 CREATE TABLE t_comment ( id INT PRIMARY KEY AUTO_INCREMENT, user_id INT, spot_id INT, content TEXT, reply_content TEXT, create_time DATETIME, status TINYINT DEFAULT 1 -- 默认为1显示管理员可设为0隐藏 );新增加的三张表——收藏表、订单表、信息统计表——就与业务闭环紧密相关-- 收藏表 CREATE TABLE t_favorite ( id INT PRIMARY KEY AUTO_INCREMENT, user_id INT NOT NULL, spot_id INT NOT NULL, create_time DATETIME, UNIQUE KEY uk_user_spot (user_id, spot_id) ); -- 预约/订单表 CREATE TABLE t_order ( id INT PRIMARY KEY AUTO_INCREMENT, order_no VARCHAR(32) NOT NULL, user_id INT NOT NULL, spot_id INT NOT NULL, visit_date DATE, ticket_count INT DEFAULT 1, total_price DECIMAL(10,2), status TINYINT DEFAULT 0, -- 0待确认 1已确认 2已取消 create_time DATETIME );表之间建立外键关系不是必须的但业务查询时要通过JOIN关联用户表获得用户昵称、关联景点表获得景点名称。3.3 核心业务代码景点列表与搜索接口的实现景点列表是前台的核心接口我直接贴一段实际的Service代码思路Override public PageResultSpotVO getSpotPage(SpotQuery query) { PageSpot page new Page(query.getPageNum(), query.getPageSize()); LambdaQueryWrapperSpot wrapper new LambdaQueryWrapper(); // 关键词搜索模糊匹配景点名称或描述 if (StringUtils.hasText(query.getKeyword())) { wrapper.like(Spot::getName, query.getKeyword()) .or().like(Spot::getDescription, query.getKeyword()); } // 按分类筛选 if (query.getCategoryId() ! null) { wrapper.eq(Spot::getCategoryId, query.getCategoryId()); } // 按区域筛选 if (StringUtils.hasText(query.getArea())) { wrapper.eq(Spot::getArea, query.getArea()); } // 按状态筛选只查询上架景点 wrapper.eq(Spot::getStatus, 1); wrapper.orderByDesc(Spot::getViewCount); PageSpot result spotMapper.selectPage(page, wrapper); // 组装VO补充分类名称、收藏状态等字段 PageResultSpotVO pageResult new PageResult(); pageResult.setTotal(result.getTotal()); pageResult.setRecords(convertToVO(result.getRecords())); return pageResult; }这里有一个容易翻车的细节用like加or()条件时要注意QueryWrapper的条件组合问题如果后面还有其他eq条件建议用and(condition)包裹模糊查询条件避免SQL条件优先级错乱。景点详情的缓存实现可以这样public SpotVO getSpotDetail(Integer id) { // 1. 先取缓存 String cacheKey spot:detail: id; String cacheValue redisTemplate.opsForValue().get(cacheKey); if (cacheValue ! null) { return JSON.parseObject(cacheValue, SpotVO.class); } // 2. 缓存未命中查询数据库 Spot spot spotMapper.selectById(id); if (spot null) { // 3. 缓存空值防止穿透 redisTemplate.opsForValue().set(cacheKey, , 5, TimeUnit.MINUTES); return null; } // 更新浏览量 spotMapper.updateViewCount(id); SpotVO vo convertToVO(spot); // 4. 写入缓存过期时间30分钟 redisTemplate.opsForValue().set( cacheKey, JSON.toJSONString(vo), 30, TimeUnit.MINUTES ); return vo; }这段代码虽然不长但包含缓存命中、缓存空值防穿透、浏览量异步更新三个技术细节每个细节都能在答辩时展开讲。3.4 前端页面怎么搭Bootstrap Thymeleaf还是Vue分离两种方案都可行但我强烈建议结合自身前端基础来选择。方案一后端渲染使用Thymeleaf模板引擎 Bootstrap jQuery。这种方案的优点是开发速度快不需要考虑跨域问题一个Spring Boot工程搞定前后端。缺点是页面交互体验相对单一但这对于毕业设计来说已经足够了。方案二前后端分离前端使用Vue 3 Element Plus。如果你之前学过Vue或者想通过毕业设计锻炼前后端分离的能力这个方案更好。前后端分离的难点不在Vue本身而在跨域配置、token传递、接口联调前期搭建成本比方案一高。我的看法毕业设计的核心是展示你对业务和技术的理解而不是前端动画多酷炫。如果时间不够或前端基础薄弱选择方案一把精力放在后端业务逻辑和数据设计上性价比最高。如果你已经具备一定的Vue基础选择方案二会让项目整体“技术含量”更上一层楼——特别是JWT认证机制在前后端分离场景下更自然。前端页面至少需要游客端首页景点瀑布流、景点详情页、登录注册页、个人中心我的收藏、我的订单后台管理端页面仪表盘统计卡片趋势图、景点管理表格、分类管理、评论审核、订单管理。图表可以用ECharts折线图和柱状图各做一个统计模块瞬间就立体了。3.5 别忘了界面设计也可以“讲重庆故事”重庆旅游景点的系统界面配色和元素可以做得很讨巧。深红色和橙色是重庆的城市底色——火锅、洪崖洞夜景、山城光影——用在导航栏和按钮主色上页脚放一个重庆经典地标的水印或插画景点卡片上显示所在区县的小角标。这些细节不增加技术复杂度但能让系统“一眼就能看出是做重庆旅游的”这在项目展示环节很加分。另外建议在后台管理端增加“景点审核”功能景点不是后台直接提交发布而是需要管理员二次确认后才在前台展示。这个流程虽然简单但是否有“审核”概念直接决定评委对你的系统定位是“个人博客”还是“企业级业务系统”。4. 常见问题与避坑指南4.1 数据库设计阶段最容易犯的错我帮人看过很多份毕设代码发现数据库设计问题主要集中在没有设计逻辑删除字段前台删除景点时真的把数据从表里物理删除了导致关联的订单和评论直接失去外键目标。正确做法是每个表都加deleted字段使用MyBatis-Plus的逻辑删除配置。时间和金额类型乱用时间都用DATETIME而不用TIMESTAMPTIMESTAMP只能表示到2038年虽然离现在远但答辩老师可能会问金额一律DECIMAL(10,2)禁止用FLOAT和DOUBLE。不设索引t_comment表的spot_id、t_favorite表的user_id、t_order表的外键字段都应该加普通索引。数据量大了之后没有索引的查询就是全表扫描这个细节在答辩时假如老师问“你能说说怎么优化查询性能吗”有没有索引就是分水岭。4.2 接口开发阶段的典型问题接口开发时我遇到过不少坑整理成几个高频问题供自查日期格式化问题后端返回的DATETIME字段默认是2025-01-01T12:00:00这种格式。在application.yml中配置spring.jackson.date-formatyyyy-MM-dd HH:mm:ss和time-zoneGMT8即可解决。跨域问题前后端分离场景写一个WebMvcConfigurer实现addCorsMappings或者用CrossOrigin注解在Controller上。注意如果使用了JWT拦截器跨域预检请求OPTIONS需要直接放行否则前端浏览器会报跨域错误这是初学者最容易忽略的问题。空指针异常查询用户信息、景点信息时先判断是否为null再继续操作或者用Optional优雅处理。事务失效同类中方法的自调用不会触发事务代理确保Transactional加在Service的public方法上。4.3 答辩的时候怎么“讲出亮点”很多同学做完项目却不知道怎么讲站在台上只会演示页面。我有一个建议准备3个“技术故事”每个故事由“遇到的问题 我的方案 效果/收获”三部分组成。比如第一个故事系统在做景点详情页时发现高访问量导致数据库压力大于是引入Redis缓存热点数据并解决了缓存穿透问题接口响应时间从300ms降到50ms以内。这个故事要在答辩时主动讲出来不要等老师问。第二个故事系统设计时将用户角色分为普通用户和管理员通过JWT实现无状态认证保证了前后端分离架构下接口的安全性。第三个故事在景点推荐功能中通过标签匹配实现了基于内容的推荐逻辑比如收藏了“洪崖洞”的用户会收到“夜景类”景点的推荐为后续引入协同过滤算法预留了扩展空间。把这三个故事讲清楚你的毕业设计就不仅仅是“做了一个系统”而是“用技术手段解决了一个业务场景中的实际问题”。4.4 毕设时间规划与常见注意事项速查表阶段周期建议产出物需求分析与文档3~5天开题报告、需求规格说明数据库设计2~3天数据库设计文档、SQL脚本后端核心功能10~15天可运行的接口、测试前端页面开发7~10天页面原型、前后端联调测试与演示准备5~7天测试报告、演示PPT、项目部署包每天保持至少2小时的编码时间不要试图最后两周冲刺尤其是遇到环境问题、依赖冲突、以及各种“明明照着视频写为什么报错”的问题解决起来非常耗时。4.5 我想单独拿出来说的几个“过来人”经验第一写代码前一定要先把数据库表设计出来表设计决定了整个项目的天花板。很多同学边写边改表改到后面表之间关系乱成一锅粥Service层全是拼接SQL的补丁代码。这个项目的业务逻辑不复杂花半天时间认真设计表结构后面所有接口都会很顺畅。第二推荐使用MyBatis-Plus而非原生MyBatis。原生MyBatis需要手写大量XML映射文件对很多同学来说既枯燥又容易出错。MyBatis-Plus的BaseMapper自动提供增删改查分页用Page对象条件构造用LambdaQueryWrapper开发效率高一个档次。第三版本锁定要特别小心JDK、Spring Boot、MyBatis-Plus、MySQL驱动之间的版本兼容性问题。比如Spring Boot 3.x必须搭配MyBatis-Plus 3.5.3版本否则启动直接报错。建议一上来就锁定一个经过验证的版本组合JDK 11 Spring Boot 2.7.18 MyBatis-Plus 3.5.3.2 MySQL 8.0。第四在“首页接入地图展示”这个功能上尽量用高德地图JavaScript API或百度地图的普通标注功能定位到重庆的主要景点坐标做成初始化标注点即可。地图API本身免费、不用企业认证演示效果却非常突出——毕竟景点都是真实存在的物理位置看到地图上散布的景点标记“综合服务平台”这个定位一下子就立住了。第五给自己的Git仓库做“小而频繁”的提交每次修改一个功能就commits一次。这不仅是为了防代码丢失更重要的是答辩前如果需要整理开发过程Git历史记录就是你最真实的开发日志。这个项目做完Spring Boot的核心机制、MyBatis-Plus的常见用法、Redis的实际应用、甚至前后端交互的一些细节基本就都能串起来了。我见过很多选题看着唬人的项目最后做成一堆散装代码也见过这个题目被认认真真做出平台感的作品。差别不在于题目本身而在于有没有把“数据结构、业务逻辑、技术方案”想清楚再动手。按照这篇文章的思路走你拿到的就不只是一个能运行的毕设demo而是一套真正能讲出设计逻辑的完整系统。
