每年到毕业设计开题季，我最常看到的问题就是“SpringBoot能做什么选题”“有没有不容易撞车、又能讲出东西的系统”。说实话，SpringBoot加各种管理系统的组合已经被写得太多了，图书管理、考勤管理、商品管理，不是不能做，而是答辩时评委一听题目就开始放空，很难问出有营养的问题，分数自然也就平平。
“人文南京旅游网站”“金陵文化智慧旅游服务平台”这种题目反而更容易做出区分度。它有明确的内容导向和文化主题，技术上也完全撑得起来。真正的问题在于：很多同学把这个题目做成了“景点列表加后台增删改查”，白白浪费了好选题。这篇文章我就从实际经验出发，把题目拆开讲透，从选题理解到技术选型，从数据库设计到核心功能落地，再到打包部署和答辩准备，一次性说清楚。
1. 先把这个毕设题目拆开看：三个关键词决定了系统的深度
题目在毕设系统里显示出来往往是一长串：“计算机毕业设计springboot人文南京旅游网站 金陵文化智慧旅游服务平台 基于SpringBoot的南京历史文化在线导览系统”。名字长，其实是好事，因为不同场景需要的名字本来就不同。开题报告里强调的是第一个叫法——技术栈加内容域；系统登录页和首页大标题可以用第二个——强调平台属性；真正介绍系统功能的时候，第三个描述最准确——在线导览系统。
很多人不重视这个拆解，直接把题目原封不动贴到系统首页，看起来反而没有重点。你要先想清楚，评委会从这三个关键词里问出什么问题。
1.1 “人文南京”不是宣传语，是内容体系的起点
如果一个旅游网站只有景点名称、门票价格、开放时间，那它和任何通用旅游网站没有任何区别。既然题目里专门写了“人文南京”和“金陵文化”，内容层就必须有自己的体系。
我在项目里一般这样规划内容：除了常规的景点基础信息，还需要有一个“文化专题库”，用来存放非遗项目、民俗活动、传统美食、历史建筑、名人足迹、诗词典故等条目。比如游客来到南京夫子庙，系统不只告诉他“秦淮河畔有夫子庙”，还要告诉他这里有哪些老字号、哪些民俗表演、哪些历史故事，甚至关联到秦淮灯会这样的非遗项目。
这部分内容的价值在于：第一，让系统有信息增量，区别于普通景点列表；第二，为搜索、推荐、路线规划提供算法素材——没有内容标签，所谓的“智慧推荐”就是空壳；第三，答辩的时候你有故事可讲，可以从内容设计、采集来源、展示逻辑几个角度展开，比讲一百遍增删改查更有说服力。
1.2 “智慧旅游服务平台”：从展示到服务的层级跳跃
很多同学看到“平台”两个字就发怵，觉得一定要做成多角色、多机构、多端的那种大系统。实际上，本科毕设里的“平台”并不需要膨胀到这种程度，关键在于服务链条要完整。
普通旅游网站的功能链条是“看信息”，用户浏览完就结束了。智慧旅游服务平台则要把链条串起来：游客来之前可以在线浏览和检索，来的时候可以用路线导览跟着逛，逛的过程中可以发表评价、留下足迹，逛完之后系统可以根据兴趣推荐其他景点。后台管理员负责维护景点、文化专题、路线，还可以审核评价。
也就是说，这个系统至少要有游客端和管理员端两套视角，再加上收藏、点评、足迹、推荐、路线规划这些形成闭环的功能模块。功能闭环是“智慧”两个字最直观的体现。你不需要做得像携程那样庞大，但要让评委看到你考虑过“一个完整的游览流程”而不是“一个静态展示页面”。
1.3 “在线导览系统”：串联起所有功能的主线
“在线导览”是这个题目里最有发挥空间的部分。导览不等于导游词朗读，而是要把景区按文化主题组织成可运行的路线。
我的建议是做一个双层的路线体系。第一层是后台管理员配置的固定主题路线，比如“民国建筑一日游”“非遗美食半日游”“博物馆主题游”，每条路线关联若干个景点并标注先后顺序和停留时间。第二层是前台根据用户的兴趣标签和可用时长自动生成的临时路线，这一步能体现出“系统”在办事。
导览功能把搜索、景点详情、路线推荐、地图展示这些模块全部串起来，是整个系统的叙事主线。答辩介绍时，你就沿着“游客要找什么—系统怎么推荐—路线怎么生成—游览后如何反馈”这条线讲，逻辑会非常清楚。
2. 技术选型与版本决策：这些热搜词哪些该听，哪些该绕开
技术选型是动手前的第一道关卡。很多同学会在网上搜“springboot整合flink”“springboot集成金仓v8”“若依框架springboot集成tdengine”之类的关键词，看到什么新鲜就想加进系统里。我劝你冷静一点，毕业设计的核心是“你能讲清楚”，而不是“你堆了多少技术”。
2.1 SpringBoot版本：2.7还是3.x，先看你的JDK
选版本是第一个容易踩坑的地方。现在网上很多教程都是Spring Boot 2.x时代的，而Spring Boot 3.x默认要求JDK 17及以上，而且原来的javax包全部改成了jakarta，很多第三方组件的兼容版本都不一样。
我的建议很实际：如果你在学校的电脑或者老师的验收环境还是JDK 8，就直接用Spring Boot 2.7.x，这是2.x时代最后一个稳定的维护版本，兼容性好，网上资料最多，MyBatis-Plus、JWT、Redis这些配套都能直接对上。如果你的机器愿意装JDK 17，并且老师要求技术新一点，那再上Spring Boot 3.x，但一定要把配套依赖的版本提前确认好，尤其是MyBatis-Plus要选对应的spring-boot3 starter。
另外一个细节：新建项目的时候把版本号和依赖锁死。有些同学喜欢用start.spring.io默认生成的最新版，结果第二天有依赖版本冲突，排查半天。Maven项目里把parent版本、MySQL驱动版本、MyBatis-Plus版本都固定下来，能省很多麻烦。
2.2 核心依赖清单：够用就好，别贪多
一个旅游网站类的毕设，最核心的依赖其实就这几样：
- spring-boot-starter-web：Web基础
- mybatis-plus-boot-starter：操作MySQL
- mysql-connector-java：MySQL驱动
- lombok：简化实体类代码
- spring-boot-starter-validation：参数校验
- jjwt：用户登录后签发令牌
- hutool：工具库，处理字符串、日期等杂事
如果后续要加Redis缓存、HanLP分词，再按需引入。至于“springboot整合flink”“springboot集成tdengine”这种，除非你有真实的高并发场景或海量时序数据要处理，否则对毕设是纯负担。评委问你“为什么要用flink”，你只能回答“网上说它很厉害”，这就非常被动了。
顺便说一下若依框架。网上经常有人吹若依，确实方便，代码生成器一点就是一套后台。但正因为太方便，很多同学答辩时根本说不清代码逻辑，被问两句就卡壳。我见过太多“代码能跑但完全讲不清楚”的案例。如果你想快速搭后台，借鉴若依的思路可以，但别直接把整个框架二开提交上去。
2.3 前端和后台的集成方式要早定
这个题目涉及前端页面，建议采用Vue 3加Element Plus。不要自己手写复杂CSS，毕设重点在业务逻辑，前端框架负责把页面撑起来。
这里有一个很多人到后期才遇到的问题：开发时前端跑Vite开发服务器，后端跑8080端口，前后端分离没问题；到了要演示或者给老师打包的时候，总不能现场开两个终端吧。所以我在项目里一般从一开始就规划好：开发环境走Vite代理，生产环境把vue打包后的静态文件交给SpringBoot托管，最终只运行一个jar包。这种方式演示最稳，也正好回应了那个热门搜索“vue打包放进springboot中”，后面第六章我会专门讲具体做法。
3. 数据库设计：金陵文脉怎么落成表和字段
数据库是整个系统最见功底的部分。很多人的表结构只有用户表、景点表、评论表三张表，太单薄，也撑不起“人文”“智慧”这两个关键词。你要把文化内容、路线、用户行为全部纳入，才算是完整设计。
3.1 从内容出发的核心实体
我按功能域把表分成几组：
第一组是基础资源：景点表、文化专题表。景点表就是常规的景区信息，文化专题表用来存非遗、民俗、建筑、美食、人物、诗词这类人文条目。
第二组是组织关联：标签表、景点标签关联表、路线表、路线景点关联表。标签是在搜索和推荐时发挥作用的，路线则对应在线导览。
第三组是用户行为：用户表、收藏表、足迹表、评价表。这四张表是“智慧服务”的数据来源，没有用户行为，推荐算法就没有输入。
分开设计的好处是职责清晰。比如收藏表，你要收藏的既可能是景点也可能是文化专题，那么一张表里通过item_type字段区分就行，不用拆成两张。路线和景点是多对多关系，所以需要一张关联表来记录顺序和停留时长。
3.2 一张能直接开工的建表草案
以下是我在实际项目中习惯使用的核心建表结构，你可以直接参考着改。
CREATE TABLE `scenic_spot` ( `id` BIGINT NOT NULL AUTO_INCREMENT, `name` VARCHAR(100) NOT NULL COMMENT '景点名称', `alias` VARCHAR(100) DEFAULT NULL COMMENT '别名', `category_id` BIGINT DEFAULT NULL COMMENT '一级分类', `dynasty` VARCHAR(50) DEFAULT NULL COMMENT '关联时代/时期', `address` VARCHAR(200) DEFAULT NULL, `longitude` DECIMAL(10,6) DEFAULT NULL, `latitude` DECIMAL(10,6) DEFAULT NULL, `intro` TEXT COMMENT '简介', `history_story` TEXT COMMENT '人文典故', `open_time` VARCHAR(100) COMMENT '开放时间描述', `ticket_info` VARCHAR(100) COMMENT '门票信息', `visit_duration` INT DEFAULT 60 COMMENT '建议游玩分钟', `cover_url` VARCHAR(255) DEFAULT NULL, `status` TINYINT DEFAULT 1, `create_time` DATETIME DEFAULT CURRENT_TIMESTAMP, `update_time` DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='景点表';文化专题表核心字段类似：title（标题）、type（非遗/民俗/美食/建筑/人物/诗词等）、dynasty、content（正文）、relate_spot_id（关联景点）、cover_url、status。
路线表的核心字段是route_name、theme、description、duration（总时长）、cover_url、status。路线景点关联表的核心字段是route_id、spot_id、sort_order、stay_minutes（建议停留时长）。
用户行为表通用结构则是：user_id、target_type、target_id、create_time，收藏和足迹都可以用这种结构，评价表则多一个content和rating字段。
3.3 通用字段和枚举状态的设计习惯
设计表的时候有几个习惯建议从一开始就培养。第一，每张业务表都带上create_time和update_time，以后排查数据问题会非常方便。第二，用status做软删除和上下架，不要直接DELETE物理删除，这样数据统计、审核流程都好处理。第三，所有金额、时间、经纬度字段的类型提前定好：经纬度用DECIMAL(10,6)，坐标精度足够导航级别的使用了；时间类字段用DATETIME。
状态值统一用TINYINT，并且约定好含义：0表示禁用或删除，1表示正常。如果有审核流程，再定义2表示待审核。这套约定在前后端都要一致，注释写清楚。
4. 核心功能落地细节：在线导览为什么不是普通CRUD
数据库设计完成之后，真正拉开差距的就是功能模块的落地方式。我挑搜索、路线推荐、个人中心三个部分展开讲，因为这些地方最容易体现“智慧”。
4.1 搜索模块：从LIKE到HanLP分词的升级路线
初级做法是SQL模糊查询：根据用户输入的关键词，用LIKE去匹配景点名称和简介。优点是实现简单，缺点是搜索“中山陵在哪个区”这种自然语言时结果非常差。
我的建议是做一个两阶段的搜索方案。第一阶段是基础检索，用MySQL的LIKE加索引实现，保证最基本的搜索能用。第二阶段是加分项，引入HanLP分词库，把用户输入切分成词条，再拿词条去匹配景点标签和文化专题。
HanLP在SpringBoot项目里集成并不复杂，Maven引入依赖，然后在Service里调用分词接口就行。为了提升效果，可以准备一个自定义词典，把“夫子庙”“中山陵”“老门东”“金陵”“秦淮”这些专有名词加进去，避免被错误切分。
实际操作的时候我会这样做：
- 用户搜索“南京有哪些民国建筑值得逛”
- HanLP分词为“南京/民国/建筑/值得/逛”
- 系统过滤掉“值得”“逛”这类的噪声词
- 拿“南京”“民国”“建筑”去匹配文化标签和景点名称
- 按匹配度返回结果
这个方案实现量不大，但答辩效果极好。评委想听的正是“你怎么处理自然语言搜索”，哪怕只是分词加匹配，也足够证明你考虑过真实问题。
4.2 路线规划：让“智慧”落到算法上
固定路线的实现很简单，后台管理员配置一条路线包含哪些景点，前台按顺序展示。真正有含量的是动态路线推荐。我给一个本科阶段完全够用的方案：
用户选定感兴趣的标签和游玩时长（比如“半日游”“一日游”），系统先筛选出符合标签且当前开放的所有景点，再根据每个景点的建议游玩时长、景点间的地理距离，计算一个尽可能在限定时间内游览更多景点的顺序。
地理距离可以调用Haversine公式，用两个景点的经纬度算出直线距离，再按当地平均交通速度折算成路程时间。确定候选景点集合后，用贪心算法依次加入“路程加上游玩时间总成本最小”的景点，直到超出用户给的游玩时长为止。
代码逻辑框架大致是这样的：
// 1. 根据标签筛选候选景点 List<ScenicSpot> candidates = spotService.findByTags(tags); // 2. 计算两两景点间的交通时间 Map<Long, Map<Long, Double>> travelTime = calcTravelTime(candidates); // 3. 从起点出发，贪心选下一个成本最小的景点 // 4. 累计时间超过用户时长就停止这个算法不复杂，但“为什么用贪心”这个问题很好回答：因为它速度快、可解释性强，适合景点数量几十个量级的场景。你甚至可以在答辩时现场演示一组对比，说明贪心虽然不能保证全局最优，但在实际使用中已经足够合理。这比空谈“使用动态规划求最优解”要实在得多，因为动态规划的状态设计在旅行场景下很容易被追问到答不上来。
4.3 个人中心闭环：收藏、足迹、评价怎么联动
个人中心不要做成一个空壳，要体现数据流动。用户点收藏时，系统记录收藏行为；用户查看景点详情时，系统自动记录足迹；用户游玩后可以发表评价，评价需要管理员审核后展示。收藏数据、足迹数据又可以反过来作为个性化推荐的输入。
比如“猜你喜欢”这个模块，我的实现思路是利用用户收藏或足迹关联的景点标签，统计出现频次最高的几个标签，再去景点库中寻找拥有同样标签的未访问景点，按热度排序推荐。这个属于基于内容的推荐，比协同过滤在数据量少的时候更稳，也更好解释。
实际开发中注意一点：收藏和足迹的字段尽量统一，都设计成“用户ID+目标类型+目标ID”的格式。这样写推荐逻辑的时候，一次查询就能拿到数据，不用来回join。
4.4 后台管理功能边界
后台管理模块不要只做景点管理。我建议加一个“文化专题管理”和“评价审核”功能。文化专题管理对应前面说的人文内容体系；评价审核则对应管理员角色，后台可以配置审核状态。这两项功能可以让你的系统在介绍时层次更丰富：用户端、管理员端完全分开，权限控制是真实存在的。
5. vue打包放进springboot的正确姿势，以及部署演示的坑
这一章回应那个高频热搜词“vue打包放进springboot中”。我见过太多同学开发环境一切正常，一到给老师演示就崩，原因就是前后端联调方式没规划好。
5.1 为什么要打成单一jar演示
最稳定的演示方式就是只启动一个SpringBoot应用，打开一个端口，页面和接口都在同一个服务里。Vue项目打包后会产生一个dist目录，里面是纯静态文件，SpringBoot天然可以托管静态资源，把dist内容放到src/main/resources/static目录下，启动后访问根路径就能看到页面。
这种方式的优势很明显：不用现场装Node.js、不用开两个进程、不会因为Vite开发服务器的端口被占而翻车。只要有JDK环境，java -jar就能跑。
5.2 打包步骤和路由模式选择
具体操作流程是：
- 在Vue项目的环境配置文件里，把生产环境的base设置为相对路径'./'，避免部署后资源路径找不到。
- 执行npm run build，得到dist目录。
- 把dist目录下的全部内容复制到SpringBoot项目的src/main/resources/static。
- 执行mvn clean package打成jar。
- 启动jar，浏览器访问localhost:8080，如果首页正常显示就说明集成成功。
这里有一个最隐蔽的坑：Vue路由如果使用history模式，直接访问某个子路径比如“/detail/1”时，SpringBoot会在静态资源里找这个路径，找不到就返回404。解决方案有两种：
第一种最省事，路由改用hash模式，URL会多一个#号，刷新页面不会丢失路由。
第二种是保持history模式，在后端写一个转发规则：所有非/api开头的路径都转发到index.html，让Vue自己处理路由。我倾向于第二种，页面URL更干净，看起来更专业。
@Configuration public class WebConfig implements WebMvcConfigurer { @Override public void addViewControllers(ViewControllerRegistry registry) { registry.addViewController("/{spring:[^\\.]*}") .setViewName("forward:/index.html"); } }这段代码的意思是，只要路径里不包含点号（排除js、css等静态文件），全部转发到前端入口页面。这样刷新就不会404了。但注意，API接口路径一定要加上/api前缀，否则接口请求也会被这个规则拦走。
5.3 接口统一返回与异常处理
前后端联调时最烦人的就是一会儿返回字符串、一会儿返回对象、报错时格式还五花八门。我在项目中固定使用一个Result类，统一包装所有接口返回：
{ "code": 200, "message": "success", "data": {} }同时写一个全局异常处理器，拦截业务异常和系统异常，规范返回错误信息。前端axios做一层响应拦截，code不是200时统一弹出错误提示。这样整体联调会顺畅很多，也避免了前端同事写一堆重复的后端报错处理逻辑。这个设计在答辩时也可以主动提，“前后端接口规范”是评审老师关注的实际工程问题。
6. 演示数据、性能优化和答辩问答的准备清单
系统功能开发完只是第一步，很多项目死在最后的“演示环节”。这里说的不是代码质量问题，而是数据、速度和临场发挥。
6.1 演示数据要“像人写的”
我每次评审学生系统，最先看的就是演示数据。如果景点表里全是“景点1”“测试数据”“aaa”，印象分会大打折扣。人文类项目尤其如此，内容本身就是展示对象。
建议提前录入南京本地有代表性的景点和文化条目：夫子庙、中山陵、明孝陵、老门东、南京博物院、玄武湖、鸡鸣寺、阅江楼、总统府等，每条内容至少包含简介和一段人文典故。文化专题可以覆盖秦淮灯会、金陵刻经、鸭血粉丝汤、盐水鸭这类有辨识度的内容。图片不一定要精修，但不要全部用占位图，可以统一用本地静态图片，避免演示时外链图片加载缓慢或失效。
数据量也不用过度追求，景点二十条左右、文化专题三十条左右、路线六到八条就足够演示了。但每条数据要真实，能讲出内容。
6.2 性能优化三件事：索引、缓存、分页
虽然毕设数据量小，但“有没有性能意识”是评委关心的问题。我建议至少做这三件事：
第一，索引。搜索的name字段加普通索引，收藏表加“user_id + target_id”的联合唯一索引，评价表的“spot_id + status”加索引。索引能解释清楚，就已经体现数据库设计能力了。第二，缓存。把首页景点推荐列表、热门文化专题这类读多写少的数据用Redis缓存起来，比如缓存三十分钟，后台修改后主动清理缓存。第三，分页。列表查询全部用MyBatis-Plus分页插件，前端传pageNum和pageSize，避免一次查询全表数据。
这三件事技术含量不高，但每一条都有实际意义，也都能在答辩时展现在细节里。
6.3 我把答辩常问的问题列了一遍
根据我做毕业设计辅导的经验，评委对这类系统基本上会围绕以下问题追问：
- 为什么选择SpringBoot？回答方向：基于Spring生态，简化配置，内嵌Tomcat，自动装配机制，适合快速构建独立Web服务。
- 搜索功能是怎么实现的？回答方向：基础检索用SQL模糊匹配，进阶方案使用HanLP分词，先切词再匹配标签，能处理自然语言搜索。
- 路线推荐的算法原理是什么？回答方向：基于标签筛选候选景点，结合开放时间和游玩时长，使用贪心算法按成本最小原则生成顺序，用Haversine公式计算景点间路程。
- 推荐算法为什么不用协同过滤？回答方向：系统用户数据量少，冷启动问题严重；基于内容和标签的推荐更容易解释，效果也足够满足场景需求。
- 系统怎么保证安全？回答方向：密码用BCrypt加密存储，登录后签发JWT令牌，后端拦截器校验登录状态，管理员角色单独做权限控制。
- Vue打包放进SpringBoot后刷新404怎么解决？回答方向：配置了转发规则，非API路径统一转发到前端入口，由前端路由接管。
这些问题如果提前准备过，基本都能从容应对。反过来，如果没准备，评委随便问一个“你搜索是精确匹配还是模糊匹配”都可能当场卡住。把核心代码里的每个设计决策都想清楚“为什么”，比背答案有用得多。
实话说，人文旅游网站这个题目的技术点并不难，难的是把“人文”和“智慧”真正落到系统和内容里。文化内容有厚度、推荐和路线规划有算法、前后端集成有细节、演示数据有真实感，这套组合下来，项目就已经超过大部分同类选题了。我个人带项目的习惯是：项目做完后，先不看代码能不能跑，而是先让同学用自然的语言把整个系统讲一遍，讲顺了之后再打磨细节。最后再给一个实用的小建议——录一份三分钟的完整操作演示视频存到U盘，现场万一网络或者环境出问题，打开视频就能救场，这个小动作每年都帮好多学生稳住了答辩。
