前阵子帮一位同学从选题阶段开始梳理了一套“SpringBoot + Vue + MySQL 地方特色旅游网站平台”的毕业设计，从源码结构、数据库脚本、论文提纲到部署文档全部过了一遍。这类题目在每年的毕设名单里出现频率很高，但真正能把网站做成完整业务闭环、答辩时不慌的其实不多。旅游网站看起来是人人都懂的业务，实际上手就会发现一系列问题：功能边界怎么定？表结构怎么设计才不会越写越乱？前后端分离的项目怎么联调？最重要的，演示和部署的时候要给评委看什么？

下面我按自己实际推进项目的顺序来写：先聊选题阶段的功能规划和技术选型，再拆数据库设计，走一遍后端接口和前端页面的核心实现，最后说说部署文档、论文结构和答辩准备。不管你是已经写完代码准备整理文档，还是刚拿到题目还没动手，按这个思路过一遍，应该都能把项目“收得干净、讲得清楚”。

1. 选题值不值：一个文旅站点的功能边界怎么定

1.1 这个题目好在哪，又难在哪

旅游网站的业务足够直观，评委不需要你解释“什么是预订”“什么是收藏”，这是它作为毕设题目最大的优势。技术面又很完整：前端要做列表页、详情页、登录注册、个人中心，后端要做查询、下单、评论、权限校验，数据库要设计好几张业务表以及它们的关联关系，论文里能写的东西非常充实。

难点也很真实。第一，地方特色类的旅游网站很容易做得千篇一律，无非就是景点图片加一段介绍文字，看不出“特色”；第二，景点数据要靠自己整理，图片、简介、价格、开放时间这些信息如果太潦草，演示效果会大打折扣；第三，订单和评论这类模块涉及状态变化，处理不好就会出现重复下单、重复评论这类低级问题。建议把重心放在“完整闭环”上，而不是追求功能数量。

1.2 前后台功能清单与角色划分

这个网站要服务三类使用角色：游客、注册用户、管理员。游客能看不能买，注册用户能预订收藏评论，管理员进后台维护内容。下面是一份比较合理的模块划分。

前台页面包括：首页、景点列表、景点详情、线路推荐、登录注册、个人中心。后台建议做一个单独的管理员界面，别和用户中心混在一起，权限控制更清晰，论文里也能多画一张模块图。

1.3 功能“切分”技巧：守住核心闭环

做毕设最忌讳的就是“什么功能都想加”。接真实支付、做多商户、搞秒杀，这些对于课程设计来说都是包袱。这个项目的核心闭环应该是：游客浏览景点 → 用户登录 → 预订门票（模拟支付） → 生成订单 → 用户查看订单 → 管理员后台看到并处理订单。

围绕这条闭环，必须做的模块只有：景点展示、用户登录注册、预订下单、订单查看、简单的后台管理。评论和收藏属于加分的常规模块，做起来不复杂，建议保留。线路推荐、轮播图属于内容展示，难度低，能撑页面。至于优惠券、积分、多级评论、数据大屏，不建议作为第一版目标，先把主链路跑通，时间富余再考虑。

2. 技术栈这么组合：前后端分离的每一环都在干什么

2.1 SpringBoot、Vue、MySQL三者的分工与选型原因

后端选择Spring Boot，核心原因是自动装配带来的开发效率。不用写XML配置，内嵌一个容器就能直接跑起来，写接口、连数据库、做参数校验都有成熟方案。Vue则胜在组件化和单页应用体验，页面跳转不用刷新整页，列表、详情、后台表格都适合拆成组件复用。MySQL是关系型数据库里最通用的选择，免费、资料多、老师也熟悉，导出SQL脚本交给评审老师检查非常方便，这对于毕设场景是很重要的优势。

这套组合几乎没有需要迟疑的地方。Spring Cloud太重，SSM手写配置又太琐碎，Vue3 + Vite + Element这类现代前端工具链反而能体现你对工程化的理解。唯一的建议是：技术栈要在开题报告里写清楚理由，而不是只罗列名词。

2.2 后端工程目录：看懂每一层的职责

实际项目中我习惯按下面这个结构组织后端代码：

src/main/java/com/example/travel/ ├── config/ // 跨域配置、拦截器注册、静态资源映射 ├── controller/ // 接口层，接收请求、参数校验、返回统一结果 ├── service/ // 业务逻辑层，处理订单、登录、评论等核心逻辑 ├── mapper/ // 数据访问层，数据库读写 ├── entity/ // 实体类，对应数据库表 ├── common/ // 统一返回结果、全局异常、JWT工具类、常量枚举 └── TravelApplication.java

分层的意义在答辩时最容易体现。比如问到“预订流程怎么保证不重复下单”，你可以定位到service层的某个方法，讲清楚里面的校验和事务，而不是把一堆SQL写在Controller里，评委想看也看不懂。

2.3 开发前的准备：依赖、数据库客户端、接口调试工具

后端依赖建议保持精简：Spring Web、MyBatis-Plus、MySQL驱动、JWT相关包、Hutool这类工具包就够了。MyBatis-Plus最大的价值是CRUD不用手写SQL，分页查询直接用内置Page对象，能省下大量时间，同时它的LambdaQueryWrapper写法可读性好，答辩演示时也不难看懂。

至于开发工具，IDE用熟悉的就行，数据库客户端只要能连MySQL、能执行SQL脚本即可。接口调试建议准备一款调试工具，自测接口时会频繁使用，部署文档里把它列为可选工具，对新手更友好。

3. 数据库设计：把景点、订单、评论整理成表关系

3.1 核心表有哪些，各自为了解决什么问题

旅游网站的数据库表大概在七到八张，太少说明业务没展开，太多说明设计过度。我把核心表列在这里，你可以直接对照自己的项目查漏补缺：

强调一下分类表：很多同学偷懒把分类直接做成景点表里的一个字符串字段，后期想改分类名称要更新很多行数据，分类筛选也麻烦。独立一张表是成本最低的规范化设计，论文里还能写一句“遵循数据库第三范式”，一举两得。

3.2 重点表字段拆解（含建表SQL）

景点表是整个网站的“内容底盘”，字段设计直接影响前后端开发。参考建表语句如下：

CREATE TABLE `attraction` ( `id` INT NOT NULL AUTO_INCREMENT COMMENT '主键', `name` VARCHAR(100) NOT NULL COMMENT '景点名称', `category_id` INT NOT NULL COMMENT '分类ID，关联category表', `cover` VARCHAR(255) DEFAULT NULL COMMENT '封面图URL', `summary` VARCHAR(500) DEFAULT NULL COMMENT '景点简介，列表页展示', `content` TEXT COMMENT '景点详细介绍，详情页展示', `price` DECIMAL(10,2) NOT NULL DEFAULT 0 COMMENT '门票参考价', `stock` INT NOT NULL DEFAULT 0 COMMENT '每日可售库存', `opening_hours` VARCHAR(100) DEFAULT NULL COMMENT '开放时间，例如08:00-17:30', `address` VARCHAR(255) DEFAULT NULL COMMENT '详细地址', `recommend` TINYINT DEFAULT 0 COMMENT '是否推荐：1推荐 0不推荐', `status` TINYINT DEFAULT 1 COMMENT '状态：1上架 0下架', `create_time` DATETIME DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间', `update_time` DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '更新时间', PRIMARY KEY (`id`), KEY `idx_category` (`category_id`), KEY `idx_recommend` (`recommend`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='景点表';

这里有几个经验：summary要有个长度限制，列表页卡片只用简介，点击进去再读content，避免列表接口返回大量文本；price用DECIMAL而不用FLOAT，金额类型不该有精度问题；status字段实现“下架”功能，而不是物理删除，这也是商品类系统的通用做法。

订单表是另一个关键表，字段建议包括：订单号、用户ID、景点ID、景点名称（冗余字段）、门票数量、单价、总金额、订单状态、联系人姓名、联系电话、游玩日期、创建时间。景点名称这种冗余字段看起来“违背范式”，但实际查询订单列表时不用反复关联景点表，性能更好，论文里可以解释为“空间换时间的适度冗余”。

3.3 索引、逻辑外键、初始化数据的三点建议

第一，外键建议只保留在ER图上，数据库物理层不建。不是不重要，而是毕设阶段数据量小，物理外键会带来删除顺序的麻烦，代码里删数据时还要先删关联表，容易报错。通过代码逻辑维护关联关系更可控。

第二，索引不要乱加。常用查询条件无非是分类、推荐位、景点名称关键词，给这些字段建普通索引就够了。订单表按用户ID查，所以user_id要建索引。加了索引后，答辩时被问到查询性能，也能回答出“为高频查询条件建立索引”这样专业的表述。

第三，数据库脚本一定要带初始数据。我见过太多项目SQL文件里只有空表结构，演示时页面空空如也，再好的界面也撑不住。建议整理二十到三十条景点数据、若干条线路数据、几条轮播图数据，再加上一个预先创建好的管理员账号，脚本导入后系统立刻能演示。数据内容可以围绕当地特色设计，比如自然湖泊、古城遗址、民俗文化村这类主题，让“地方特色”落到字面上。

4. 后端接口怎么开发：从登录鉴权到预订闭环

4.1 JWT登录：一次搞懂无状态鉴权

登录方案直接决定后续所有接口的写法。如果还用传统的Session，前端后端都要处理跨域Cookie问题，部署时更麻烦。JWT方案是无状态的，核心流程是：用户登录成功后，后端生成一段加密的Token返回给前端，前端保存到本地存储，之后每个请求都在请求头带上这个Token，后端拦截器校验通过就放行。

生成Token的逻辑大致是这样的：

String token = Jwts.builder() .setSubject(String.valueOf(user.getId())) .claim("username", user.getUsername()) .claim("role", user.getRole()) .setExpiration(new Date(System.currentTimeMillis() + 60 * 60 * 24 * 7L)) .signWith(SignatureAlgorithm.HS256, secretKey) .compact();

Controller层不需要判断“用户是否登录”，而是由拦截器统一处理。但要注意一点：景点列表、景点详情这些公开接口要加入白名单，否则游客还没登录就什么都看不了。管理员专属接口还要额外校验角色字段，只有管理员角色的Token才允许访问，这也是论文里“权限控制”章节的素材。

4.2 景点列表与详情：覆盖80%查询场景的写法

景点列表接口需要支持分页、按分类筛选、按关键词搜索、按推荐位过滤、按价格排序。用MyBatis-Plus的条件构造器写起来很直观：

public Page<Attraction> pageList(AttractionQuery query) { LambdaQueryWrapper<Attraction> wrapper = new LambdaQueryWrapper<>(); if (StrUtil.isNotBlank(query.getKeyword())) { wrapper.like(Attraction::getName, query.getKeyword()); } if (query.getCategoryId() != null) { wrapper.eq(Attraction::getCategoryId, query.getCategoryId()); } if (query.getRecommend() != null) { wrapper.eq(Attraction::getRecommend, query.getRecommend()); } if (StrUtil.isNotBlank(query.getOrder())) { wrapper.orderByDesc(Attraction::getPrice); } wrapper.eq(Attraction::getStatus, 1); return attractionMapper.selectPage( new Page<>(query.getPageNum(), query.getPageSize()), wrapper); }

这种写法的好处是参数越多过滤条件越多，不会因为加了一个筛选就重写SQL。详情接口更简单，按ID查景点记录。至于景点下的评论列表，可以返回详情时一起带上，也可以单独做接口，我建议单独做分页接口，因为景点详情返回的内容已经不少，评论混在里面会让数据变大。

4.3 预订、收藏、评论：事务、幂等与状态流转

预订是这个项目业务逻辑最重的地方。我的实现思路是：从前端拿到景点ID、游玩日期、门票数量，后端先查景点库存，确定有足够的余票，然后计算金额创建订单，同时扣减库存。这三步必须放在一个事务里，加@Transactional注解，否则库存扣了订单没生成，数据就对不上了。

订单状态我用整数表示：0待支付、1已支付、2已完成、3已取消。模拟支付就是把状态从0改成1，前台做个“确认支付”按钮即可。很多同学会忽略“防重复下单”，其实加一个简单校验就行：同一用户、同一景点ID、同一游玩日期，如果已存在待支付订单就提示“该日期已有待支付订单，请勿重复下单”。

收藏的实现更简单，但要考虑幂等：用户点击收藏时，如果已经收藏过，应该取消收藏（前端图标切换），而不是重复插一条数据。这里用“先查询再决定插入还是删除”即可，不需要复杂设计。

评论可以加一个门槛：只有购买过该景点的用户才能评论，这个逻辑会让系统显得完整，答辩时也是不错的加分点。评论内容要有长度限制，比如5到500字，存库前做一次校验。

4.4 统一返回体与全局异常：让前端好做事

后端所有接口的返回结构要统一，否则前端每个页面都要单独处理不同数据格式。我一般用这样的结构：

public class Result<T> { private Integer code; // 200成功，其他失败 private String message; // 提示信息 private T data; // 业务数据 }

再加上一个全局异常处理器，比如参数校验失败、景点库存不足、Token过期，都抛出业务异常，由统一处理器转换成对应的Result返回。这样Controller里不需要到处写try-catch，代码干净，前端也能通过code字段做统一判断。

5. 前端页面怎么做：从路由到请求再到页面

5.1 路由设计：页面之间的跳转关系

Vue项目的页面组织通过路由配置来管理，一个实用的路由设计如下：

路由写完建议加上前置守卫：访问需要登录的页面时，检查本地是否存有Token，没有就跳转登录页。这个逻辑非常基础，但很多毕设项目不做，导致刷新页面后个人中心直接报错。

5.2 axios封装与Token注入：让每个请求自动带身份

前端请求后端如果每个接口都手动拼请求头，代码会非常啰嗦。统一封装axios是必须做的，核心代码可以这样写：

import axios from 'axios'; const request = axios.create({ baseURL: '/api', timeout: 10000 }); request.interceptors.request.use(config => { const token = localStorage.getItem('token'); if (token) { config.headers.Authorization = token; } return config; }); request.interceptors.response.use( response => { const res = response.data; if (res.code !== 200) { // 统一提示错误，比如 Message.error(res.message) return Promise.reject(new Error(res.message || '请求失败')); } return res; }, error => { return Promise.reject(error); } ); export default request;

这样做的直接收益是：登录之后，所有需要身份的接口自动携带Token，响应中的业务错误码也能统一提示。项目里所有接口调用都通过这个封装的文件走，不会出现“有的请求带Token、有的不带”这种低级bug。

5.3 跨域、图片、富文本：三个容易翻车的细节

第一个坑是跨域。前后端分离开发时，前端跑在5173端口，后端跑在8080端口，浏览器会拦截跨域请求。开发环境最简单的处理方式是在构建工具配置代理，让前端把请求转发给后端：

server: { port: 5173, proxy: { '/api': { target: 'http://localhost:8080', changeOrigin: true } } }

生产环境如果是前后端分开部署，再由后端配置跨域会有点麻烦，建议把前端构建产物放在静态服务器托管，同时配置反向代理把/api路径转发到后端端口。

第二个坑是图片存储。有些同学把图片转成Base64字符串直接存数据库，一张图片几万字符，数据库瞬间膨胀，查询还慢。正确做法是把图片文件保存到服务器某个上传目录，数据库里只存图片的相对路径，后端再配置静态资源映射，把upload目录映射成可访问的URL。

第三个坑是富文本内容展示。景点详情如果使用了富文本编辑器，前端展示时尽量别直接v-html绑定用户输入内容，容易带来脚本注入风险。要么对内容做好过滤，要么展示时选择靠谱的富文本渲染组件，内容安全性在论文的“系统测试”里也能提一笔。

6. 部署、论文和答辩：把毕业设计完整交付

6.1 从零到一：本地部署的完整步骤

部署文档的价值在于让评审老师能按图索骥，把项目跑起来。一份合格的部署步骤大概是这个顺序：

第4步和第5步之间经常出问题的是端口冲突和数据库连接失败，部署文档里要把“常见问题”列出来，比如“后端启动提示端口被占用怎么解决”“前端请求接口报跨域错误怎么办”，这两条能帮老师节省大量时间。

6.2 部署文档应该包含什么

部署文档不是把命令行抄一遍就行。我的建议是包含六块内容，每一块都对应一个实际问题：环境要求、数据库配置、后端启动、前端启动、本地预览地址和默认账号、常见报错排查。默认账号那一点很容易被忽略，但评审老师最可能就是拿你写的账号去登录后台，看不到任何提示会显得项目不完整。另外文档里要放一张目录结构说明，标注源码、SQL脚本、论文文档分别在哪里。

6.3 论文结构：六章写法与答辩常见问题

论文的结构尽量和系统对应，通常按这个顺序展开：绪论（研究背景、研究现状、研究内容）、需求分析（角色分析、功能需求、非功能需求）、系统设计（总体架构、功能模块设计、数据库设计）、系统实现（逐模块贴核心代码并配运行截图）、系统测试（测试环境、功能测试用例表、测试结果）、结语。每张图都要自己截图重新绘制，不要直接搬项目截图，图的质量直接影响老师的第一印象。

答辩演示建议按业务闭环来走：首页 → 景点列表（演示搜索和分类筛选） → 景点详情 → 注册登录 → 预订支付 → 个人中心查看订单 → 后台登录管理景点和订单 → 展示数据统计页面。整个过程控制在八分钟以内。常被问到的问题也无非这几个：

• 为什么用SpringBoot而不用传统的手写配置方式？（答自动装配、内嵌容器、生态成熟）
• 数据库为什么这么设计？（围绕业务闭环，注意订单冗余字段和逻辑外键）
• 如何保证订单和库存的数据一致性？（答事务管理）
• 系统有什么不足？（准备一个真实缺口，比如模拟支付可以升级为真实支付，推荐功能可以用更多数据分析来做）

最后再说两句实测体会

带完这一整套项目，我最大的感受是：毕业设计最怕的不是代码写不出来，而是最后“交不出去”。这里提到的“交不出去”，就是指数据库里没有像样的数据、部署文档写得模棱两可、演示的时候不知道从哪个页面开始讲。如果你正在做同类型的旅游网站，时间不够的情况下，优先级应该是这样排的：先保证核心闭环完整，再准备丰富的初始化数据，然后写好部署文档，最后才是优化界面细节。做完这些，答辩基本不会出大问题。项目源码里最好再留一个我上面提到的SQL初始化脚本，把景点、分类、轮播图、管理员数据一次导入，这样无论是自己演示还是老师接手检查，第一步永远是从“能跑起来”开始。