SpringBoot+Vue+MySQL旅游网站管理平台：全栈毕设项目详解

如果你正在为毕业设计或课程设计发愁，想找一个“既能体现工作量、又不会把自己绕晕”的题目，“SpringBoot + Vue 安康旅游网站管理平台”是非常值得认真考虑的方向。这不是客套话：旅游网站管理平台这套业务，天然包含了 Java 后端常见的大部分核心功能，又有 Vue 前端可以展示交互效果，再配上 MySQL 管理结构化数据，正好覆盖了一个学生全栈项目最主流的技术路线。这篇文章不会只给一张架构图就结束，我会从业务拆解、数据库设计、后端接口组织、前端页面实现、本地部署到常见问题排查，把这套源码从头到尾讲透，适合正在做毕设、课设，或者想通过一个完整项目把 Java 和 Vue 串联起来的同学参考。

1. 以“旅游管理平台”作为毕设选题，本质是在考哪几层能力

先把这个题目拆开看。旅游网站管理平台听起来像“给景区做个展示网站”，但如果真的只做几个展示页面，代码量撑不起一份毕业设计，答辩的时候也很难讲出亮点。我整理这个项目时，把业务范围重新划分成了三块：内容管理、预订交易、后台运营。内容管理负责景点、酒店、旅游线路、攻略文章这些信息对象的增删改查；预订交易负责用户从下单到订单状态变更的完整流程；后台运营则是管理员对数据、公告、用户权限的维护。一套题目落到这三块里，后端就能覆盖权限拦截、事务、文件上传，前端能覆盖列表、详情、表单、路由守卫，无论从评分角度还是从简历包装角度，都有实打实的材料可以讲。

1.1 表面是内容展示，底层是“内容 + 交易 + 管理”三种模式的组合

第一层是游客端展示。景点列表、景点详情、线路推荐、酒店房型、攻略文章，这些页面没有特别复杂的算法，但需要用分页、关键字搜索、分类筛选来提升体验。实际开发中，很多同学在第一版只把数据遍历出来，忽视了前端加载时的空状态提示和 loading 反馈；真正在演示时，用户点击搜索没有结果，或者接口响应稍慢，这些问题立刻会被注意到。

第二层是交易闭环。用户把一条旅游线路或者景区门票加入预订流程，后端创建订单、生成订单编号、按状态跟踪流程。这是整个项目里最有区分度的地方。有了订单，你才需要在数据库里设计状态字段，需要在前端展示支付按钮，需要考虑取消订单后数据怎么处理；没有订单，整个系统就退化成了一般的文章管理系统，难度会明显下降。

第三层是后台管理。管理员登录后维护景点数据、上下架线路、处理订单状态、发布公告，必要时还可以禁用某个用户。后台管理解决的是“谁来更新网站内容”的问题，它决定了系统不是一套静态网页，而是一个有人维护、可运营的平台。这三层互相印证：前台用户能看到什么内容，取决于后台维护的数据；后台需要处理什么数据，又来源于订单和用户行为。把三层讲清楚，系统的整体逻辑就自洽了。

1.2 前后台两个端口的角色划分，是答辩最容易被追问的细节

很多答辩老师在听完功能演示后，第一个追问往往就是“普通用户和管理员是怎么区分的”。如果只有页面跳转而没有权限控制，答案就不完整。安康旅游项目里，用户表用 role 字段区分角色，前端路由用 meta 属性配合路由守卫控制页面访问，后端再用拦截器对非白名单接口统一校验 Token，三层配合才是完整的权限方案，而不是表面上的“登录就能进后台”。

前台端口面向普通游客。不登录也可以浏览大部分内容，但收藏、预订、发表评论这些操作需要登录后才能完成，这是实际网站通行的做法。后台端口面向管理员。普通用户的 Token 即使拿到手也无法调用管理端接口，因为后端在拦截器里已经校验角色；前端也会根据登录者的角色渲染不同菜单。前台与后台虽然共用一套代码工程，但在业务上已经做到了隔离。这个设计思路不复杂，却能在答辩时成为明显的加分项。

2. SpringBoot、Vue、MySQL 的组合逻辑：为什么这套技术栈适合学生项目

一套技术栈的选择，不能只因为“大家都在用”就说它合适。我在给同学做技术方案评估时，会反复强调三个维度：环境搭建成本、学习曲线、部署维护成本。SpringBoot、Vue、MySQL 恰好在这三个维度上都对学生友好，这也是这类源码能成为毕设热门的原因。

2.1 SpringBoot 降低的是环境成本，不是业务复杂度

对比传统 SSM 项目，Spring + Spring MVC + MyBatis 的配置相当繁琐，光 XML 文件就能让新手在第一天失去耐心。SpringBoot 通过起步依赖把常用组件打包，自动配置让数据源、Web 容器、依赖注入默认可用，内嵌 Tomcat 也意味着不需要单独安装和配置外部服务器。对于课程设计场景，时间和耐心本身就是稀缺资源，凡是能用默认配置解决的事情，都不值得手动折腾两小时。

但需要提醒的是，SpringBoot 的自动配置不意味着可以不理解原理。系统启动后如何确定数据源连接成功、拦截器为什么能在 Controller 执行前拦截请求，这些问题依然要读一点源码。我的经验是：把启动日志完整读一遍，比刷十篇框架教程都有效。日志里每一行都对应了一次组件初始化，把这些节点串起来，你对框架的理解会立刻上一个台阶。

2.2 Vue 的组件化思维，让前端从“堆页面”变成“搭积木”

Vue 的核心优势是数据驱动视图和组件复用。旅游平台里有很多相似结构的页面，比如景点列表、酒店列表、旅游线路列表，它们都遵循“筛选条件 + 列表 + 分页 + 详情”的模式。用组件化方式把搜索栏、分页器、图片卡片抽成公共组件，各个页面只通过 props 传参，改动一处样式整站生效。这在原生 JavaScript 里会变成一场灾难，在 Vue 里则是日常操作。

选择 Vue 还有一个更实际的理由：生态成熟。管理后台需要使用表格、弹窗、表单校验、日期选择器，Element Plus 这类组件库可以让后台页面快速做出像样的效果，不必从零画控件。对需要交付整套源码的学生项目来说，稳定、上手快、文档全，就是核心竞争力。另外，Vue 的中文社区资源非常多，遇到问题搜到的解决方案基本都是可用的，这比什么都重要。

2.3 MySQL：关系型数据库依然是业务系统的最佳底座

旅游平台涉及用户、订单、资源之间的关联查询，比如查“某个用户的所有未支付订单”，用 SQL 的 JOIN 一条语句就能完成。MySQL 对事务的支持也很关键：创建订单时既要扣减库存，又要更新用户订单数，一旦中途出错就应该整体回滚，这种一致性需求正是关系型数据库的强项。

在这个项目里，不需要引入 PostgreSQL，也不需要刻意折腾 NoSQL。MySQL 安装简单、可视化工具多、教程丰富，在校生最熟悉的就是它。项目跑完导出 SQL 文件，别人导入也能完整复现，这是课程设计验收最需要的可移植性。如果嫌配置不够规范，可以在本地开 binlog 实践一下主从同步，但学生阶段完全不必研究这些，先保证 CRUD 和事务正确即可。这套架构的产物并不是那种高并发高可用的工业级系统，但学习项目的关键是逻辑完整性和可复现性，这一点上面这组技术已经做得很到位了。

3. 数据库表设计：旅游数据模型如何从“景点列表”变成“订单闭环”

我习惯在设计 SpringBoot 项目时先设计数据库，而不是先写代码。数据库表结构定下来，实体类、Mapper、业务接口都会顺着它长出来。安康旅游项目我规划了十张左右的表，下面按角色说明。

3.1 信息型表与关联型表：先把业务对象拎清楚

信息型表对应前台展示的内容，包括景点表、酒店表、旅游线路表、攻略表、公告表。以景点表为例，至少要有这几类字段：基本属性（名称、地址、简介、图片地址）、商业属性（门票价格、开放时间）、运营属性（状态、浏览量、创建时间）。酒店表还需要增加星级、联系电话；旅游线路表需要增加天数、成团人数；攻略文章表要注意 content 字段使用 TEXT 类型，避免 varchar 长度不够。

关联型表如用户收藏表、评论表、订单表，它们保存的是用户与内容之间的互动关系。收藏表可以设计成 target_type 加 target_id 的泛化结构，比分别建“景点收藏表”“酒店收藏表”更省事，后续扩展其他资源时也不需要额外建表。评论表则要关联用户表和资源表，做联表查询时按资源类型过滤。这部分的命名和关系理清了，后面的代码才能写顺。

3.2 订单表承载的是完整业务状态机

订单是交易闭环的核心。一个简洁但完整的订单表结构如下：

CREATE TABLE `orders` ( `id` bigint(20) NOT NULL AUTO_INCREMENT, `order_no` varchar(32) NOT NULL COMMENT '订单编号', `user_id` bigint(20) NOT NULL COMMENT '下单用户ID', `product_type` tinyint(4) NOT NULL COMMENT '1:景点门票 2:酒店房间 3:旅游线路', `product_id` bigint(20) NOT NULL COMMENT '关联资源ID', `product_name` varchar(100) DEFAULT NULL COMMENT '资源名称，冗余存储', `price` decimal(10,2) DEFAULT '0.00' COMMENT '单价', `quantity` int(11) DEFAULT '1' COMMENT '数量', `total_price` decimal(10,2) DEFAULT '0.00' COMMENT '总价', `status` tinyint(4) DEFAULT '0' COMMENT '0:待支付 1:已支付 2:已完成 3:已取消', `create_time` datetime DEFAULT NULL, `pay_time` datetime DEFAULT NULL, `update_time` datetime DEFAULT NULL, PRIMARY KEY (`id`), KEY `idx_user_id` (`user_id`), KEY `idx_create_time` (`create_time`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='订单表';

订单编号用订单表主键之外生成的唯一串，可以包含日期和随机数，方便人工识别。product_name 做冗余存储，是因为在订单列表页要展示资源名称，如果每次都去联查景点表或酒店表，查询逻辑会复杂很多；冗余字段的代价是数据可能不一致，但这种程度的冗余在管理平台里完全可以接受。

订单状态机需要讲清楚：待支付只能转移到已支付或已取消，已支付可以确认完成，已取消是终态。前端几个按钮对应状态流转，后端接口层还要校验非法跳转。比如一个待支付订单，不允许直接调用接口改成已完成。这样一个简单的状态机，已经足够完成一个毕设要求的业务逻辑。

3.3 建表时通用字段一步到位，避免后期返工

很多新手建表只关心业务字段，忽视公共字段，后面要加字段时再改代码，既费时又容易漏掉关联查询。我的建议是，所有业务表一次性加好这些公共字段：create_time、update_time、status、remark。凡是要作为查询条件的字段都要建索引，比如 user_id、product_id，避免数据量稍微上来之后出现明显的查询卡顿。

字符集方面，表结构统一使用 utf8mb4，而不是 utf8。utf8mb4 是 MySQL 对 UTF-8 的完整实现，能兼容更多字符，虽然中文项目用 utf8 也不会出错，但从更稳妥的角度出发，直接选 utf8mb4 更省心。字段注释也要写清楚，一个 name 是“景点名称”还是“酒店名称”，在写 Mapper 映射和前端表格列头时，能减少大量的理解成本。

4. SpringBoot 后端落地：统一返回、JWT 鉴权、接口规范一次讲透

后端要解决的问题，不只是把 CRUD 写完，而是让接口有统一的规范，让权限控制能够覆盖所有需要保护的路由，让前端拿到的数据结构是稳定的。下面按代码组织方式展开。

4.1 代码目录与分层约定

后端我建议分成 entity、mapper、service、controller、config、common、utils 几个包路径。entity 映射数据库表，mapper 写数据库操作，service 处理业务逻辑，controller 暴露接口，config 放配置类，common 放统一返回对象，utils 放 JWT 等工具类。

这里有两个约定值得坚持。第一，所有 Controller 的返回值类型必须是 Result 。这个类包装了 code、message、data 三个字段，前端只需要判断 code 值，不需要为每个接口单独处理异常结构。第二，Service 层只做业务判断，不直接接收 HttpServletRequest，保持业务逻辑的可测试性。这样做的好处是，后续要换成 Spring Security 或者做单元测试，Service 层的代码不需要大改。

Result 类的核心很简单，静态方法生成成功或失败的结果对象：

public class Result<T> { private Integer code; private String message; private T data; public static <T> Result<T> success(T data) { Result<T> result = new Result<>(); result.setCode(200); result.setMessage("success"); result.setData(data); return result; } public static <T> Result<T> error(String message) { Result<T> result = new Result<>(); result.setCode(500); result.setMessage(message); return result; } }

前端在 axios 响应拦截器里统一判断 code，弹提示信息，各个页面就不用重复写整套错误处理逻辑了。

4.2 JWT 登录机制：拦截器是实现多处登录校验的关键

在课程设计这个量级里，直接使用 Spring Security 确实有点重，配置和理解成本都不低。更常见的做法是自定义拦截器配合 JWT。登录成功后，后端签发一个 Token 返回给前端，前端在后续请求的 Header 里带上这个 Token；后端拦截器拦截所有非白名单接口，校验 Token 是否有效以及角色是否匹配。

JwtUtil 工具类里主要是 createToken 和 parseToken 两个方法，用 HMAC 算法签名。Token 里保存 userId 和 role，有效期设为 24 小时。登录接口的流程是：查询用户、校验密码、生成 Token、返回用户信息和 Token。这里要注意密码不能明文存储，至少用 BCrypt 加密，课程设计阶段用这个完全可以。

拦截器注册要放在 WebMvcConfigurer 中实现，并设置好白名单路径。项目里常见的白名单有用户注册、用户登录、首页轮播、景点列表、景点详情、公告资讯，这些接口不需要登录就能访问。除了白名单外，其他接口一律经过 Token 校验。遇到校验失败的情况，拦截器直接返回 401，前端收到 401 后自动跳转到登录页。

4.3 接口清单：整个平台需要哪些后端方法

整理一份接口清单，能快速估算工作量。核心接口大致如下：

设计原则很简单：查询列表接口一律分页，返回分页对象而不是裸 List；管理端修改订单状态单独做一个接口，前端根据按钮传对应的状态常量。不要在 Service 里写一堆 if-else 判断前端传的是什么，尽量让每个接口的职责单一。

4.4 文件上传与静态资源映射，必须成对配置

管理员维护景点信息时需要上传图片，常见的实现是用 MultipartFile 接收文件，保存到本机指定目录，文件名用 UUID 拼上原后缀，返回路径存入数据库。但保存到磁盘只是第一步，还要配置静态资源映射，否则前端访问 /files/xxx.jpg 时会直接 404。

@Configuration public class WebMvcConfig implements WebMvcConfigurer { @Value("${file.upload-dir}") private String uploadDir; @Override public void addResourceHandlers(ResourceHandlerRegistry registry) { registry.addResourceHandler("/files/**") .addResourceLocations("file:" + uploadDir + "/"); } }

注意在 Windows 和 Linux 下，路径写法有差异，Windows 是 file:D:/upload/，Linux 是 file:/usr/local/upload/。这一层配置漏掉，前端图片就会全部裂开，这是文件上传类功能最容易踩的坑。

5. Vue 端开发重点：游客页面与后台管理面板用同一套工程完成

Vue 前端要做的工作不少，最关键的是把目录组织好，把请求封装做对，再把前后台两套页面在逻辑上分开。前端工程里我建议按下面的结构组织。

5.1 前端目录组织，决定维护成本

推荐这样的目录结构：

src ├── api ├── router ├── store ├── views │ ├── front │ └── admin ├── components └── utils

前台页面放在 views/front 下，后台页面放在 views/admin 下，路由也分开配置。前台路由挂在根路径，比如 /、/scenic、/hotel、/scenic/:id；后台路由统一放在 /admin 下，并给后台路由加上 meta.requiresAdmin 标记。这样即使有人手动输入 /admin 的地址，路由守卫也能把他拦回登录页。

组件目录里放的是公共组件，比如分页器、图片卡片、搜索栏。这些组件在景点列表、酒店列表、线路列表里复用，避免了在三个页面里复制三份同样的代码。状态管理建议用 Pinia，如果项目规模不大，甚至可以只用 localStorage 存 token 和用户信息，没有必要为了用 Pinia 而用 Pinia。

5.2 axios 封装与 token 注入，一次配置全站生效

axios 封装要解决三个问题：统一 baseURL、自动带 Token、统一处理错误码。开发环境可以借助 Vite 代理，把 /api 开头的请求转发到后端端口，这样 baseURL 统一写 /api 即可，不需要在代码里写死后端地址。

请求拦截器从 localStorage 取出 Token，注入到 Authorization 请求头。响应拦截器判断 HTTP 状态码和业务 code，如果返回 401，说明 Token 失效或未登录，直接清空本地存储并跳转到登录页。这样一个封装写好后，所有页面都不用关心 Token 怎么带上，不用关心登录过期怎么处理。

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

响应拦截器里统一处理业务 code，如果 code 不等于 200，把 message 提取出来，用组件库的 Message 组件弹出提示。后续所有接口，页面里只需要写业务逻辑，错误提示由拦截器统一完成。

5.3 后台管理的搭建思路，本质是表格 + 表单 + 弹窗

后台管理面板的大多数页面，本质是表格加表单加弹窗。表格负责数据展示和操作按钮，表单负责新增或编辑，弹窗负责承载表单。使用 Element Plus 组件库，把表格列和表单字段对应好，后端返回的数据直接填充进表格，整个后台的开发速度会快很多。

左侧菜单栏建议用配置式渲染。菜单数组里记录 path、title、icon 和 role 字段，根据当前用户的 role 过滤菜单项。新增一个管理页面时，只需要增加一条菜单配置和对应的页面组件，不需要改动侧边栏组件代码。这样后台的可扩展性会好很多，也为后续增加新的功能模块留好了位置。

前台页面则更注意展示效果，可以加入一些卡片式的列表、图片懒加载、详情页的轮播图。前台代码不需要实现管理端那些复杂的表单校验，重心放在交互体验和数据渲染上。两套页面风格可以不同，但必须共用同一套 axios 封装和路由守卫。

6. 本地部署最小步骤：数据库初始化、配置调整、双端启动

一套源码拿到手，第一件事是跑起来。很多人卡在这一步，问题往往不是代码本身，而是环境配置缺少某个细节。下面把从零开始的步骤完整列出来。

6.1 application.yml 中每一项配置的含义

后端配置集中在 application.yml 里，最关键的是数据源配置和文件上传配置：

spring: datasource: url: jdbc:mysql://localhost:3306/ankang_travel?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai username: root password: root driver-class-name: com.mysql.cj.jdbc.Driver servlet: multipart: max-file-size: 10MB max-request-size: 20MB jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: GMT+8 server: port: 8300 file: upload-dir: D:/upload/

URL 里的 serverTimezone 参数很重要，MySQL 8 连接时如果不设置时区，经常会报 CST 相关异常，加上 Asia/Shanghai 就能解决。jackson 配置控制的是 LocalDateTime 的序列化格式，如果不配置，默认会输出一串数组，前端很难直接使用。file.upload-dir 是图片保存目录，记得提前创建好目录，不然上传时可能因为目录不存在而失败。

6.2 初始化步骤和启动验证清单

下面是完整的环境准备和启动流程：

1. 安装 JDK 8 或 11、Maven 3.6+、MySQL 5.7 或 8.0、Node.js 14 以上版本。
2. 用命令行或可视化工具创建数据库，字符集选择 utf8mb4：create database ankang_travel default character set utf8mb4;
3. 导入项目提供的 SQL 文件，初始化表结构和测试数据。
4. 修改 application.yml 里的数据库用户名和密码，改成你自己本机的账号。
5. 后端目录执行mvn spring-boot:run，看到 Tomcat started 日志即启动成功。
6. 前端目录执行npm install，等待依赖安装完成后执行npm run dev。
7. 浏览器访问前端地址，默认端口由 Vite 配置决定，通常 3000 或 5173。

启动成功后，用普通用户账号登录前台，确认能浏览景点和线路；再用管理员账号登录后台，确认能进入管理面板。SQL 文件里如果没有预设管理员，可以先用注册接口注册一个账号，再手动把 user 表的 role 字段改成 ADMIN，然后重新登录。

7. 实际开发中踩过的坑：问题现场、排查过程与最终修复

这一部分，我把反复出现的几个典型问题整理出来。这些问题如果只给结论，你下次遇到可能还是不会排查，所以我按“问题现象 + 排查方向 + 最终修复”的方式来写。

7.1 跨域请求被拦截，但前后端配置看起来都没有错

前端 Vite 运行在 3000 端口，后端在 8300 端口，浏览器报 CORS 错误。奇怪的是，前端已经在 Vite 配置里写了 proxy，看起来配置没有问题。排查之后发现，axios 请求里写的是完整地址http://localhost:8300/api/xxx，请求根本没有经过 Vite 代理。Vite 代理只对相对路径如/api生效，写了完整的后端地址就绕开了代理，由浏览器直接发起了跨域请求。

最终使用的是统一相对路径方案。axios 的 baseURL 写成/api，Vite 配置里做代理转发：

server: { port: 3000, proxy: { '/api': { target: 'http://localhost:8300', changeOrigin: true } } }

如果不用代理，在后端开启 CORS 也可以，但注意两个方向只能选一个。既开代理又开 CORS，在某些请求场景下会出现重复响应头，反而引发额外的问题。

7.2 Long 类型主键传到前端后精度丢失

订单表的主键是 BIGINT，前端拿到的订单 ID 有时候变成一串不对的数字，末尾几位变成了 0，导致根据 ID 查询订单详情失败。原因是 JS 的 Number 类型只能安全表示 2^53 以内的整数，而 MySQL 的 BIGINT 最大到 19 位，超出安全范围后精度就会丢失。

最简单的修复方式，是把 Long 类型字段序列化为字符串。在实体类的主键字段上加上：

@JsonSerialize(using = ToStringSerializer.class) private Long id;

这样前端拿到的是字符串类型，接口传参时后端再转回 Long，精度就不会丢失。这个坑在课程设计阶段不容易被发现，但只要订单数据量稍微多一点，概率就很高。

7.3 图片上传成功，但前端访问图片 404

图片上传接口返回了成功，数据库里也存了路径，前端用<img src="/files/xxx.jpg">却访问不到，控制台 404。原因通常是文件确实保存到了本地磁盘，但 SpringBoot 没有配置静态资源映射。前端请求 /files 开头的路径时，SpringBoot 不知道这个路径对应磁盘上的哪个目录，自然返回 404。

解决方案就是前面提到的 WebMvcConfig，把/files/**映射到上传目录。这个配置加上之后，图片才能被正确访问。另外上传目录建议用纯英文路径，如果带有中文，URL 编码处理容易出各种小问题，一旦出现会浪费大量时间。

7.4 LocalDateTime 字段返回给前端变成奇怪的数组格式

接口返回的创建时间显示为[2024, 5, 1, 14, 30, 0]，前端直接懵掉。这是因为 Jackson 默认把 LocalDateTime 序列化成了 ISO 数组格式，而不是字符串。修复方式是在 application.yml 里全局配置：

spring: jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: GMT+8

配置之后，所有 LocalDateTime 字段都会输出成2024-05-01 14:30:00的字符串格式，前端可以直接渲染。这个问题在前后端联调时出现频率很高，提前配置好能省掉大量沟通成本。

我在实际把这个项目从头到尾调通的过程中，最大的感受是：旅游网站管理平台的难度并不像表面看起来那样“弱”，它对工程规范性有实打实的要求。数据库字段乱一点，拦截器顺序错一点，跨域配置漏一点，系统都会在执行时立刻卡住。对适用课程设计和学习场景的读者，我的建议是拿到源码后不要抱着“跑通就行”的心态，把启动流程完整走两遍，第一次按文档走，第二次故意改错配置再排查一遍，这样积累下来的排错经验，比多看十几个视频都更有价值。后续如果想增强项目，可以在现有订单基础上加上支付模拟、图表报表或者更细的权限模型，核心思路是一样的，只是数据关系变多了，整体架构并不会被推翻重来。