SSM+Vue旅游资源网站毕业设计完整实战指南

又到了一年里被毕设题目反复“折磨”的时候，最近来问我的学弟学妹里，有好几个拿的都是“SSM+Vue旅游资源网站”这类题目。实话实说，这个题目在计算机类本科毕设里属于典型的“老牌选手”，技术上不算激进，但需要做的东西一点也不少。如果能把程序结构和论文思路都打通，它既可以当一份完成度很高的毕设，也可以在答辩时让老师清楚地看到你的工程能力。

这篇文章我就围绕“ssm+vue旅游资源网站”这个项目，从选题逻辑、数据库设计、前后端分工、核心代码实现、论文写作和答辩准备几个维度完整拆一遍。适合正在做同类题目、或者打算拿旅游类网站当毕设项目的人参考，哪怕你目前只写过增删改查，跟着这套思路也能把一个合格的项目搭起来。

1. 项目定位与整体设计思路

1.1 为什么SSM+Vue这套组合至今还是毕设的稳妥选择

很多学生看到现在到处都是Spring Boot、微服务、前后端分离，就会疑惑：为什么还要做一个SSM的项目？这里有个非常实际的背景：不少高校的选题库和答辩组仍然保留了SSM体系，题目写什么就按什么来，这是最稳妥的路线。如果提纲上明确写着“基于SSM框架的旅游资源网站”，那你就不要在毕设里私自换成Spring Boot，除非指导老师明确表示可以调整。否则答辩时会面临“你的题目和实现不一致”的尴尬局面。

从技术本身来说，SSM不是过时的东西。Spring管对象和事务，SpringMVC管请求分发，MyBatis管数据库操作，这三者配合能让一个本科生把“分层思想”讲得很清楚。相比Spring Boot那种“自动配置一把梭”的用法，SSM反而更能逼迫你去理解Bean、IoC和过滤器这些基础概念。

前端这块配Vue是加分项。老式毕设喜欢用JSP+jQuery，做出来的页面一眼就回到2015年。用Vue做单页应用，配上Element UI或Element Plus，页面的观感会明显好于传统模板渲染。旅游资源这种偏展示型的网站，前端体验恰恰是用户第一眼关注的东西，所以Vue在这里不是炫技，而是解决实际问题。

1.2 业务功能边界：把“资源展示”变成可验收项目

很多同学拿到“旅游资源网站”这个题目后，第一反应是拼命加功能：支付、抢票、线路规划、智能推荐……我见过一位同学想做一个完整版“在线旅游电商平台”，结果写了三个月，连核心流程都没跑通，最后只能熬夜砍功能。

正确的思路是先把项目定性成“资源展示+轻交互”。游客可以浏览景点和旅游线路，注册用户可以收藏景点、发表评论，管理员可以在后台管理景点、线路、公告、用户和评论。这个范围的拿捏是有讲究的：

• 有完整的用户体系：注册、登录、权限区分，这是每一个答辩老师都会关注的点。
• 有核心业务实体：景点、线路、资讯，做的是旅游资源领域的事。
• 有典型的系统行为：浏览、搜索、详情、收藏、评论，能体现数据库设计和业务逻辑。
• 有后台管理端：管理员的增删改查，能体现完整的闭环。

把边界定在这个程度，既能在一两个月内做出来，又足够支撑一篇结构完整的论文。支付、地图、推荐这些可以写进“未来展望”，但不要真花时间去开发。

角色划分也很清晰，我用下表把它结构化：

1.3 程序与论文的配合节奏

我后来带项目时一直强调一件事：不要等程序全部写完再开始写论文，也不要先把论文编出来再补程序。正确的节奏是用论文大纲反推程序模块，用程序截图填充论文。

具体操作上，我建议先花两天列出论文的章节框架：摘要写什么、需求分析分哪几节、数据库表画哪些、系统实现要哪些截图、测试写哪些用例。然后按照这个框架去开发程序，每完成一个模块，马上截图并写好功能说明。比如你做完了景点管理，就立刻把列表页截图、新增页截图、修改页截图存到一个“论文素材”文件夹里，顺手写下这段功能是怎么实现的。

这样到论文阶段，你不需要回忆“当时那个功能是怎么做的”，素材都在手边，写作速度会快很多，而且截图和程序永远对得上。很多同学最后要花大量时间返工，就是因为程序界面改版后，论文里的旧截图和新代码对不上，答辩时被老师一眼看出来。

2. 核心细节解析与实操要点

2.1 数据表设计：少踩“字段拍脑袋”的坑

旅游资源网站的数据表不算复杂，但设计得规不规范，答辩老师一眼就能看出来。我通常建议最少建六张表：

• 用户表：id、用户名、密码、昵称、手机号、头像、角色、注册时间。
• 景点表：id、景点名称、所属地区、封面图片、简介、详细内容、门票价格、开放时间、创建时间、状态。
• 线路表：id、线路名称、出发地、目的地、天数、价格、线路图片、详情、创建时间。
• 评论表：id、用户id、景点id、评论内容、评论时间。
• 收藏表：id、用户id、景点id、创建时间。
• 公告表：id、标题、内容、发布时间。

这套表里有一个比较常见的坑：图片字段。景点封面图很可能不止一张，但毕设项目没必要做独立图片表。最省事也最稳妥的做法是直接在景点表里用一个字符串字段，比如cover_image，存图片的相对路径或完整URL。前端拿到这个字符串直接渲染，后面想要多图，用逗号分隔字符也足够应付。

另一个容易出问题的地方是价格字段。做旅游类项目时，门票价格、线路价格一定用decimal类型，不能图省事用float或double。很多同学在真实项目中吃过浮点数计算的亏，这里用decimal(10, 2)就能避免价格显示成99.999999这种奇怪情况。

评论表和收藏表都要记得加索引。尤其是收藏表，最好对user_id和scenic_id建立唯一索引，这样同一个人重复收藏同一个景点时，数据库会直接拦截，应用层不用写一堆判断逻辑。我当时做的时候，后端收藏接口先查一遍是否存在，再配合数据库唯一索引双保险，既直观又防脏数据。

外键策略也值得提前定好。删除景点时，如果该景点下已经有评论和收藏，直接物理删除会导致孤儿数据。一种做法是删景点前先删相关的评论和收藏，另一种是给景点表加一个status字段做逻辑删除。毕设层面我推荐做逻辑删除，答辩时还能解释“保留历史数据”的业务含义。

2.2 后端分层：别把Controller写成万能类

接手过几个学生的半成品项目，发现最典型的问题就是Controller里塞满了业务代码，查数据库、拼数据、写返回，全塞在一个方法里。比如这样的代码：

@Controller public class ScenicController { @Autowired private JdbcTemplate jdbcTemplate; @RequestMapping("/list") @ResponseBody public List<Map<String, Object>> list(String keyword) { // 直接在这里写SQL语句拼条件 String sql = "select * from t_scenic where name like '%"+keyword+"%'"; return jdbcTemplate.queryForList(sql); } }

这种写法，功能倒是能做出来，但答辩时只要老师追问一句“你的项目怎么分层”，就会露出破绽。规范的SSM项目至少要有Controller、Service、Mapper三层：

• Controller层：接收参数、校验参数、调用Service、返回结果。
• Service层：处理业务逻辑，比如判断评论人是否登录、收藏是否已存在。
• Mapper层：只负责和数据库交互。

为了让前端处理返回值更方便，还需要一个统一的返回类型。比如定义Result类，包含code、msg、data三个字段。成功就返回new Result(200, "操作成功", data)，失败就返回new Result(500, "操作失败", null)。前端拿到这个结构体，在axios的响应拦截器里统一判断code，弹出提示信息，代码会干净很多。

还有一个小细节：查询景点列表时，全文搜索和分页要一起做。最简单的实现是用PageHelper分页插件，在Service层查询之前调用PageHelper.startPage(pageNum, pageSize)，紧接着执行的Mapper查询就会被自动拼接limit。这个方法用起来很爽，但一定要注意startPage和查询之间不能夹其他数据库操作，否则分页会失效。这个坑我在第4节还会专门讲。

2.3 Vue前端的状态与路由设计

前端部分是整个项目最容易出彩、也最容易翻车的地方。如果你是从零开始，又暂时没有明确要求Vue版本，我建议直接用Vue3 + Element Plus，因为这是现在主流的组合，资料多，遇到问题也好搜。当然，如果学校模板指定的是Vue2 + Element UI，那也没必要硬改，功能上差异不大。

页面结构上，我习惯把前台和后台分成两套路由区域：

前台： / 首页 /scenic/list 景点列表 /scenic/detail/:id 景点详情 /route/list 旅游线路 /notice/list 公告列表 /login 登录 /register 注册 /user/center 个人中心 后台： /admin/dashboard 数据概况 /admin/scenic 景点管理 /admin/route 线路管理 /admin/user 用户管理 /admin/comment 评论管理 /admin/notice 公告管理

这背后要做三件关键的事：

第一是axios封装。新建一个request.js，配置baseURL指向后端地址，请求拦截器从localStorage里取token并放到请求头，响应拦截器统一处理业务码。这样每个页面调接口都只需要传URL和参数，不用重复处理错误提示。

第二是路由守卫。在router/index.js里给后台路由加上meta: { requiresAuth: true }，然后在全局前置守卫里判断：如果用户信息里没有管理员标记，就跳回登录页。游客可以访问的页面则不需要守卫。

第三是状态管理。Vue3项目用Pinia，Vue2项目用Vuex，把登录用户的昵称、角色、头像存到store里，同时同步到localStorage，刷新页面后从localStorage恢复。很多同学登录后一刷新就回到未登录状态，就是因为只把数据存在内存里，没有做本地持久化。

前台页面我建议关注一个体验点：景点列表的卡片布局。每个景点卡展示封面图、名称、地区、价格和一个“去看看”按钮，图片高度保持一致，价格用醒目的颜色标出来，整体观感会比纯表格列表好得多。这种页面细节花不了太多时间，但对答辩印象分提升非常明显。

3. 实操过程与核心环节实现

3.1 环境准备与项目骨架搭建

先把开发环境说清楚，推荐组合是：

• JDK 1.8或11
• MySQL 5.7或8.0
• Maven 3.6+
• Node.js 16+
• 开发工具：IDEA + VS Code

工作目录里建议创建前后端两个文件夹，比如tourism-backend和tourism-frontend，长期维护起来一眼就懂。后端用Maven管理依赖，核心依赖需要这些：

<dependencies> <!-- Spring核心 --> <dependency> <groupId>org.springframework</groupId> <artifactId>spring-context</artifactId> <version>5.x.x</version> </dependency> <!-- SpringMVC --> <dependency> <groupId>org.springframework</groupId> <artifactId>spring-webmvc</artifactId> <version>5.x.x</version> </dependency> <!-- MyBatis --> <dependency> <groupId>org.mybatis</groupId> <artifactId>mybatis</artifactId> <version>3.5.x</version> </dependency> <dependency> <groupId>org.mybatis</groupId> <artifactId>mybatis-spring</artifactId> <version>2.x.x</version> </dependency> <!-- MySQL驱动 --> <dependency> <groupId>mysql</groupId> <artifactId>mysql-connector-java</artifactId> <version>8.0.x</version> </dependency> <!-- 数据库连接池 --> <dependency> <groupId>com.alibaba</groupId> <artifactId>druid</artifactId> <version>1.2.x</version> </dependency> <!-- JSON处理 --> <dependency> <groupId>com.fasterxml.jackson.core</groupId> <artifactId>jackson-databind</artifactId> <version>2.13.x</version> </dependency> <!-- 分页插件 --> <dependency> <groupId>com.github.pagehelper</groupId> <artifactId>pagehelper</artifactId> <version>5.3.x</version> </dependency> </dependencies>

这里的版本号我个人建议用稳定版本，不要一上来就追最新，Spring 5.x和MyBatis 3.5.x这种组合已经很多项目验证过了，能避免因为版本兼容问题浪费时间。

后端配置文件至少有四份：

• jdbc.properties：存放数据库连接信息。
• spring.xml：配置包扫描、数据源、SqlSessionFactory、事务管理器。
• spring-mvc.xml：配置注解驱动、静态资源放行、视图解析器（如果前后端分离，不需要JSP配置）。
• web.xml：配置Spring监听器和SpringMVC的DispatcherServlet。

前端用Vue CLI创建项目：

vue create tourism-frontend

选择Vue3预设，安装vue-router、pinia或axios。然后执行：

npm install element-plus @element-plus/icons-vue

Element Plus在main.js里做完整引入，虽然首屏包体积会大一些，但毕设项目无所谓，开发效率最重要：

import { createApp } from 'vue' import ElementPlus from 'element-plus' import 'element-plus/dist/index.css' import App from './App.vue' import router from './router' import { createPinia } from 'pinia' const app = createApp(App) app.use(ElementPlus) app.use(router) app.use(createPinia()) app.mount('#app')

3.2 用户登录、角色权限与拦截器

登录接口是毕设项目的“交通枢纽”，几乎所有页面交互都跟用户身份挂钩。我建议登录做成这样：

用户提交用户名和密码，Controller接收后调用Service，Service根据用户名查出用户记录，比对密码。密码在数据库里不要存明文，注册时用MD5或BCrypt加密一次，登录时把用户输入的密码做同样的加密再比对。如果一致，生成一个代表登录状态的token返回给前端。

token的实现有两种档次。最简单的是Session方案：登录成功把用户对象放到session里，后端拦截器判断session里有没有用户。这种方案代码少，答辩也能讲清楚，但前后端分离部署时跨域和Session失效问题比较烦人。

我推荐用JWT风格的token，不一定要引入完整jwt库，模拟一个也可以。登录成功后，后端把用户id和角色拼成一个带签名的字符串返回，前端存到localStorage，每次请求放请求头。后端做一个拦截器解析请求头，如果解析失败就返回401。

后端拦截器的核心逻辑：

public class AuthInterceptor implements HandlerInterceptor { @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { // 如果是跨域预检请求，直接放行 if ("OPTIONS".equalsIgnoreCase(request.getMethod())) { return true; } String token = request.getHeader("Authorization"); if (token == null || "".equals(token)) { response.setStatus(401); return false; } // 解析token，判断是否有效、是否过期 // 解析出的userId放入request属性，方便Controller使用 return true; } }

这个拦截器要注册到SpringMVC中，同时配置放行路径，比如/api/user/login、/api/user/register、/api/scenic/**这些公开接口不需要token，而/api/user/center/**、/api/favorite/**则需要登录。管理员接口比如/api/admin/**还要额外校验用户角色是否为1。

前端路由守卫配合起来也很简单：

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

3.3 景点检索、详情与评论收藏实现

景点列表页是访问量最高的页面，它的核心是“条件查询+分页”。哪些条件适合用来筛选？最常用的是景点名称关键字、所属地区、价格范围。对应的MyBatis XML我一般这么写：

<select id="selectScenicPage" resultMap="ScenicResultMap"> SELECT s.id, s.name, s.region, s.cover_image, s.price, s.open_time FROM t_scenic s <where> <if test="name != null and name != ''"> AND s.name LIKE CONCAT('%', #{name}, '%') </if> <if test="region != null and region != ''"> AND s.region = #{region} </if> <if test="minPrice != null"> AND s.price &gt;= #{minPrice} </if> <if test="maxPrice != null"> AND s.price &lt;= #{maxPrice} </if> </where> ORDER BY s.create_time DESC </select>

Service层再配合PageHelper：

public PageInfo<Scenic> getScenicPage(int pageNum, int pageSize, ScenicQuery query) { PageHelper.startPage(pageNum, pageSize); List<Scenic> list = scenicMapper.selectScenicPage(query); return new PageInfo<>(list); }

这样前端每次只传pageNum、pageSize和几个筛选项，就能拿到分页数据。

景点详情页除了显示景点信息，还要显示评论列表。评论接口按景点id分页查询，每条评论要带上发表人的昵称和头像，所以SQL要关联用户表。这里用resultMap映射会比resultType更直观：

<select id="selectCommentsByScenicId" resultMap="CommentResultMap"> SELECT c.id, c.content, c.create_time, u.nickname, u.avatar FROM t_comment c LEFT JOIN t_user u ON c.user_id = u.id WHERE c.scenic_id = #{scenicId} ORDER BY c.create_time DESC </select>

收藏模块是“用户与景点”关系的核心实现。接口设计就两个：一个添加收藏，一个取消收藏。添加时先查询是否已收藏，如果已收藏就返回提示，如果没有就插入一条记录。取消收藏直接按userId和scenicId删除记录。个人中心里查询当前用户的收藏列表时，关联景点表把景点的基本信息和封面图带出来，方便做一个“我收藏的景点”卡片列表。

后台管理模块基本都是增删改查，这里不展开每个接口，但有一个思路值得分享：后台列表页沿用前台的分页组件，每个管理页用Element Plus的el-table + el-pagination + el-dialog组合。弹窗里放表单，提交时调用新增或更新接口，成功后刷新表格。这套模式写熟手之后，一张后台页面大概一晚上就能做完，六张管理页面也花不了太久。

3.4 论文撰写的章节组织与查重应对

程序做完后，论文才是重头戏。SSM+Vue旅游资源网站的论文目录基本是固定的套路，我建议按这六章走：

第一章绪论。写选题背景和研究意义，重点说明“为什么需要旅游资源网站，为什么要用Java+Vue技术栈”，最后放一张国内外研究现状的综述。

第二章需求分析。先写业务流程，再写功能需求，用用例图展示游客、用户、管理员各自能做什么。非功能性需求要提性能、易用性、安全性。这一章对应程序里的“功能边界”，写得越具体，后面的系统设计越好写。

第三章系统设计。包括系统总体架构图、功能模块图、数据库E-R图和表结构设计。实际上，E-R图和表结构直接抄自己建的表就行，逆向梳理一遍，改造成可视化图形。

第四章系统实现。这是论文最占篇幅的一章，按功能模块逐个写，每个模块放核心代码片段和运行截图。注意代码不用贴全部，只贴关键方法，并配一段文字说明“这是做什么的，为什么这么做”。

第五章系统测试。写测试环境、测试方法，然后列测试用例表：测试编号、测试项、输入数据、预期结果、实际结果。别全写“通过”，针对边界条件写一两个失败用例反而显得真实。

第六章总结与展望。总结做了一个什么系统、用了什么技术、有什么不足，后续可以增加什么功能。

关于查重，我必须提醒一句：参考文献里的概念介绍，千万不要大段复制教科书原文。写技术介绍时，用自己的话把“Spring是什么、MyBatis是什么”重新表述一遍。尤其要小心网上的博客模板，很多毕业论文模板章节相似度极高，直接照抄会被查重系统标红。正确做法是定义概念后，立刻结合自己项目里的具体场景说一句，比如“在本系统中，Spring负责管理Service和Mapper对象的创建和依赖注入”，这样既不容易重复，又能体现你对技术的掌握。

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

4.1 跨域报错与预检请求处理

前后端分离最常遇到的就是跨域问题。现象很明确：前端控制台报No 'Access-Control-Allow-Origin' header is present on the requested resource。

原因简单说，就是前端跑在http://localhost:8080，后端跑在http://localhost:8088，浏览器认为这不是同一个源。解决办法一般是在后端加一个跨域过滤器。

@Component public class CorsFilter implements Filter { @Override public void doFilter(ServletRequest req, ServletResponse res, FilterChain chain) throws IOException, ServletException { HttpServletResponse response = (HttpServletResponse) res; response.setHeader("Access-Control-Allow-Origin", "http://localhost:8080"); response.setHeader("Access-Control-Allow-Credentials", "true"); response.setHeader("Access-Control-Allow-Methods", "GET, POST, PUT, DELETE, OPTIONS"); response.setHeader("Access-Control-Allow-Headers", "Content-Type, Authorization"); chain.doFilter(req, res); } }

一个隐藏很深的坑是预检请求。前端请求带了Authorization这样的自定义头，或者请求方法是PUT、DELETE时，浏览器会先发一个OPTIONS请求确认服务器是否允许。如果你的后端拦截器把所有OPTIONS请求都拦下来要求登录，跨域就永远过不了。所以在拦截器的preHandle里一定要放行OPTIONS请求，我前面的代码示例里已经写到了这一步。

如果你不想在后端处理跨域，也可以在前端利用开发服务器做代理。在Vue项目的vue.config.js里配置：

module.exports = { devServer: { proxy: { '/api': { target: 'http://localhost:8088', changeOrigin: true } } } }

这样所有/api开头的请求都转发到后端，浏览器看到的是同源地址。但这个方法只对开发环境有效，正式打包部署后还是要用Nginx或其他方式统一入口。

4.2 登录状态反复失效的两种解决办法

这是我见过学生踩得最多的坑之一，表现形式是：登录成功后页面跳转正常，但刷新一下或者点几个页面后就提示“未登录”。如果你用的是Session方案，多半问题出在跨域配置没有带上Cookie。浏览器默认在同源请求时才会携带Cookie，跨域请求需要后端在响应头设置Access-Control-Allow-Credentials: true，同时前端axios要设置withCredentials: true。

但个人建议直接切换成token方案，能避开上面这一整摊事。登录接口返回一个token字符串，前端存localStorage，每次请求在拦截器里加上：

service.interceptors.request.use(config => { const token = localStorage.getItem('token') if (token) { config.headers['Authorization'] = token } return config })

后端拦截器从请求头拿到token，验证通过就把用户信息放到request属性里，后面的Controller直接取。这套方案不受Cookie跨域限制，部署到Nginx时也好处理。

token还有一个好处是答辩时容易讲。你可以说“因为系统采用无状态的会话保持方案，服务器不需要保存用户的登录状态，减轻了内存压力”，这句话翻译成大白话就是“每个请求都带着自己的身份证明来过检”。

4.3 MyBatis常见报错与驼峰映射

写MyBatis遇到报错是常态，我把高频问题整理成一张速查表：

驼峰命名这个问题在SSM项目里特别容易反复出现。Java实体类习惯用createTime，数据库列名习惯用create_time，如果不在全局配置开启驼峰映射，查出来的createTime就是null。配置方式是在mybatis-config.xml里：

<settings> <setting name="mapUnderscoreToCamelCase" value="true"/> </settings>

注意只开启驼峰映射还不够，数据库列名必须真的是create_time这种下划线格式，如果开发时有人图省事把列名直接命名为create_time，但实体类是create_time，那映射出来又会错，所以命名规范要从建表开始就统一。我个人的习惯是数据库全部用lower_case_with_underscore，Java实体全部用驼峰，中间靠MyBatis的映射自动转换。

4.4 答辩前最后三天的检查清单

最后说点跟答辩直接相关的实操经验。答辩内容、截图、提问环节都有对应的准备技巧，建议最后三天按下面的清单过一遍：

还有一个小技巧：答辩演示时，建议用授课千万注意不要念代码。讲登录功能时，就说“用户输入用户名密码，后端校验成功后返回token，前端保存到本地，之后请求自动携带，实现会话保持”，然后用演示操作补充细节，老师看到的是“论述清晰+系统可用”，这两点都满足，分数一定不会差。

这个项目做完之后，我个人实际带项目的体会是：毕设最重要的不是技术多炫，而是“完整”两个字。功能链路完整，文档和代码对得上，答辩时讲得清楚，这三点做到，就已经是一份非常合格的毕业设计。如果你时间充裕，再往里面加一点小创新，比如用Redis缓存热门景点数据，或者把后台改造成带统计图表的Dashboard，就是锦上添花。

最后再分享一个小技巧：每天开发结束后，花十分钟在本地Gitee或GitHub仓库提交一次代码。别嫌麻烦，那些最后做不下去、程序跑不起来、论文写不出来的同学，大多数不是能力问题，而是改着改着把自己改乱了，没有可以回退的干净版本。用好了版本控制，你的毕设进度就会稳很多。