基于SpringBoot+Thymeleaf+MySQL的旅游景点酒店预订网站设计与实现

简介：在Web应用开发中，SpringBoot作为主流Java后端框架，与Thymeleaf模板引擎、MySQL数据库组合，构成了经典的服务端渲染技术栈。其核心原理在于通过控制器将业务数据封装到Model，再由Thymeleaf在服务端动态渲染HTML页面，实现前后端一体化交付。这种架构不仅降低了对前端工程化和跨域处理的依赖，还保留了清晰的Controller-Service-Mapper分层，特别适合中小型业务系统的快速构建。在旅游信息化场景中，基于该技术栈开发的景点与酒店预订网站，能够覆盖用户注册登录、景点/酒店浏览、在线下单、订单管理、评论互动等完整业务闭环，为毕业设计或课程实践提供可运行的工程样板。本文即围绕这类系统的数据库设计、核心代码实现、部署运维及常见问题展开，给出可落地的SpringBoot实战参考。 每年四月份开始，就会有不少学生朋友来问毕业设计的事。问得最多的一类，就是某某管理系统、某某预订网站。今天这篇，我直接拿一个真实能跑的项目来说——基于SpringBoot+Thymeleaf+MySQL开发的旅游景点酒店预订网站，Java完整源代码和数据库脚本都包含在内。它不是网上那种只有半截代码的Demo，而是一套从用户注册登录到下单预订完整闭环的项目，基本覆盖了毕设答辩时老师最爱问的几个点。

这套项目的好处在于：技术栈主流，界面不花哨但够用，数据库表结构清晰，业务逻辑不复杂但五脏俱全。不管是做毕设、课程设计，还是想通过一个完整项目来理解SpringBoot后台开发的整个链路，都非常合适。下面我就从设计思路、数据库、代码实现、部署运维几个维度，把这个项目彻底拆开讲。

1. 项目整体设计与思路拆解

1.1 项目到底做了什么事

旅游景点酒店预订网站，核心业务不复杂。用户进到网站之后，能浏览旅游景点和酒店列表，可以查看详情，然后选择日期和数量进行预订。预订之后，在个人中心能查看自己的订单记录，可以对已消费的景点或酒店进行评价。管理员则通过后台维护景点信息、酒店信息、用户状态和订单状态。

这里有一个很关键的取舍：到底是做成“旅游平台”这种多商家入驻的模式，还是做一个“单站管理”的模式。毕设项目里，我建议做成单站管理就好。也就是说，景点和酒店都直接由管理员在后台添加维护，用户只能浏览和下单。这样既能把业务闭环做完整，又不会因为引入商家端、结算体系而把项目复杂度无限放大，导致代码写不完、论文也没法聚焦。

1.2 为什么选SpringBoot+Thymeleaf而不是前后端分离

这个项目名字里就写了SpringBoot+Thymeleaf，那自然要聊清楚为什么这么选。很多同学现在一上来就想着Vue+SpringBoot前后端分离，觉得这样才“高级”。但实际上，毕设答辩时老师更关注的是你能不能把一个完整业务跑通，能不能把设计逻辑讲清楚。

Thymeleaf是一种服务端模板引擎，它能在HTML页面里直接渲染Java后台传来的数据。选它有几个现实原因。第一，项目结构简单，不需要单独启动前端工程，也不需要处理跨域问题。第二，对于“页面数量不多、交互不复杂”的预订网站来说，服务端渲染的体验并不差，页面加载快，而且写起来直观。第三，和SpringBoot整合非常顺滑，只要在pom.xml里引入依赖，再把页面放在templates目录下，Controller返回的逻辑视图名就能自动对应到模板文件。对新手来说，这种“看得见摸得着”的渲染方式，比前后端分离那种页面和数据分离的调试方式友好得多。

我见过不少同学用前后端分离做毕设，结果答辩现场前端跨域问题没解决，页面数据出不来。如果你做的不是那种强交互、多状态管理的大型系统，老老实实上Thymeleaf反而更稳。

1.3 技术选型的底层逻辑

除了SpringBoot和Thymeleaf，ORM层面我建议用MyBatis-Plus。它本质上还是MyBatis，只是帮我们把单表的增删改查都封装好了，不需要写一大堆XML文件。这个项目里的用户表、景点表、酒店表、订单表基本都是单表操作，用MyBatis-Plus可以省掉大量重复代码，让你把精力放在业务和页面上。如果你在简历里写了了解MyBatis-Plus，这也是一个不错的加分点。

数据库用MySQL，这也是最稳妥的选择。版本上建议5.7或者8.0都可以，但要注意8.0的驱动名和连接URL中存在一些时区和驱动类的差异，后面我会专门讲坑。前端样式用Bootstrap，不自己造轮子，也不用维护复杂的Vue组件。因为这是一个毕设项目，保证界面干净、布局合理、能正常响应就足够了。

2. 功能模块划分与数据库设计

2.1 前台和后台的功能边界

系统面向两类角色：普通用户和管理员。

普通用户的功能集中在网站前台：

• 注册、登录、退出登录
• 浏览景点列表、酒店列表
• 查看景点详情、酒店详情
• 提交景点门票预订、酒店房间预订
• 在个人中心查看订单列表，对订单进行取消或删除操作
• 对已“完成”的订单发表评论

管理员的功能集中在后台管理端：

• 管理员登录
• 景点信息管理：新增、编辑、上下架、删除
• 酒店信息管理：新增、编辑、上下架、删除
• 用户管理：查看用户列表、禁用/启用账号
• 订单管理：查看所有订单、按状态筛选、修改订单状态
• 评论管理：查看评论、删除违规评论

这里有一个容易被忽视但很重要的点：前台和后台不要各写一套登录逻辑。我处理的方式是在用户表里加一个role字段，1表示普通用户，0表示管理员。登录时根据角色跳转到不同首页，同时用一个拦截器做权限控制。这样做数据模型简单，代码量少，而且答辩时你能讲清楚“同一个用户体系如何通过角色字段区分不同身份”。

2.2 数据库表结构设计

整个项目用到的数据表，我拆成了8张，分别是用户表、景点表、酒店表、订单表、评论表、收藏表、公告表和分类表。这里我挑重点讲。

用户表：

CREATE TABLE `t_user` ( `id` int(11) NOT NULL AUTO_INCREMENT, `username` varchar(50) NOT NULL COMMENT '登录名', `password` varchar(100) NOT NULL COMMENT '密码，建议MD5或BCrypt', `nickname` varchar(50) DEFAULT NULL COMMENT '昵称', `phone` varchar(20) DEFAULT NULL, `email` varchar(100) DEFAULT NULL, `avatar` varchar(255) DEFAULT NULL, `role` tinyint(1) DEFAULT '1' COMMENT '0管理员 1普通用户', `status` tinyint(1) DEFAULT '1' COMMENT '1正常 0禁用', `create_time` datetime DEFAULT NULL, PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

景点表和酒店表结构类似，核心字段有名称、简介、图片、地址、价格、开放时间/房型、状态等。这里要注意，图片字段存的是URL路径，不是图片本身。很多新手会把图片转成Base64往数据库里存，一旦图片多了，数据库体积暴涨，页面渲染也会变卡。正确做法是图片上传后存到本地某个目录或OSS，数据库里只存访问路径。

订单表是最关键的一张表，因为景点门票和酒店预订本质上都是“下订单”这个动作。我把两类订单合成一张表，通过product_type字段区分是景点(1)还是酒店(2)。这样做的好处是订单管理后台只有一套代码，不需要写两套。缺点是如果以后要做复杂的订单扩展，单表会有点拥挤，但对于毕设来说足够。

订单表核心字段：

CREATE TABLE `t_order` ( `id` int(11) NOT NULL AUTO_INCREMENT, `order_no` varchar(32) NOT NULL COMMENT '订单编号', `user_id` int(11) NOT NULL COMMENT '下单用户', `product_type` tinyint(1) NOT NULL COMMENT '1景点 2酒店', `product_id` int(11) NOT NULL, `product_name` varchar(100) NOT NULL, `price` decimal(10,2) NOT NULL COMMENT '单价', `num` int(11) NOT NULL DEFAULT '1' COMMENT '数量', `total_price` decimal(10,2) NOT NULL, `book_date` varchar(20) DEFAULT NULL COMMENT '游玩/入住日期', `contact_name` varchar(50) DEFAULT NULL, `contact_phone` varchar(20) DEFAULT NULL, `status` tinyint(1) DEFAULT '0' COMMENT '0待确认 1已确认 2已完成 3已取消', `create_time` datetime DEFAULT NULL, PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

这样的设计已经能够支撑一个完整的预订流程：用户在前台选择景点或酒店，填写联系人信息和预订日期，提交订单，管理员在后台确认或完成订单，用户看到状态变化后可以评论。

2.3 SQL脚本里的那些细节

数据库脚本不是把建表语句一放就完事了，还要考虑初始化数据和兼容性。

第一，字符集一定要用utf8mb4，而不是utf8。因为utf8在MySQL里最多存3字节，像一些生僻字或者emoji表情会存不进去。虽然网站上可能用不到emoji，但用户评论区保不准有人粘贴一个特殊符号，用了utf8mb4就不会出现乱码或报错。

第二，密码字段不能明文存。虽然我这里为了演示写的是简单方式，但你在毕设里最好用BCrypt或者至少MD5加盐。答辩时如果老师问“你的密码安全吗”，你至少能说出我做了加密处理。

第三，初始化数据里一定要有一条管理员账号。很多同学辛辛苦苦把项目跑起来，结果后台登录入口不知道账密。我的脚本里固定初始化一个admin/admin123，并在文档里写清楚，这样拿到项目的人第一分钟就能进后台。

3. 核心代码实现与关键环节

3.1 项目目录结构与启动入口

项目使用Maven管理依赖，结构如下：

src/main/java/com/example/travel ├── TravelApplication.java ├── controller ├── service ├── mapper ├── entity ├── config ├── interceptor └── common

启动类没什么特别：

@SpringBootApplication @MapperScan("com.example.travel.mapper") public class TravelApplication { public static void main(String[] args) { SpringApplication.run(TravelApplication.class, args); } }

注意点有两个。第一，@MapperScan一定要写，否则MyBatis-Plus的Mapper接口不会被扫描到，启动会报找不到Bean。第二，SpringBoot启动时如果你遇到端口被占用，可以临时在application.yml里改server.port，或者直接杀掉占用进程。

application.yml中的关键配置：

server: port: 8080 spring: datasource: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://localhost:3306/travel?useUnicode=true&characterEncoding=utf8&useSSL=false&serverTimezone=Asia/Shanghai username: root password: root thymeleaf: cache: false servlet: multipart: max-file-size: 10MB

开发阶段记得把Thymeleaf的缓存关掉，不然改一个HTML页面要重启整个项目才能看到效果，极其浪费时间。

3.2 实现一条完整的酒店预订流程

以酒店预订为例，完整链路是这样的：用户进入酒店列表页，点击详情页，选择房型、入住日期、入住天数，填写联系人和手机号，提交订单，后台生成一条订单记录。

实体类：

@TableName("t_hotel") public class Hotel { @TableId(type = IdType.AUTO) private Integer id; private String name; private String address; private String price; private String roomType; private String images; private String description; private Integer status; private Date createTime; // getter/setter 省略 }

Mapper接口一行代码都不用写：

public interface HotelMapper extends BaseMapper<Hotel> { }

Service层做基本的列表分页和详情查询：

@Service public class HotelService { @Resource private HotelMapper hotelMapper; public IPage<Hotel> getHotelPage(int pageNum, int pageSize) { Page<Hotel> page = new Page<>(pageNum, pageSize); QueryWrapper<Hotel> wrapper = new QueryWrapper<>(); wrapper.eq("status", 1).orderByDesc("id"); return hotelMapper.selectPage(page, wrapper); } }

Controller层控制请求跳转和数据绑定：

@Controller @RequestMapping("/hotel") public class HotelController { @Resource private HotelService hotelService; @GetMapping("/list") public String list(@RequestParam(defaultValue = "1") int page, Model model) { model.addAttribute("page", hotelService.getHotelPage(page, 8)); return "hotel/list"; } @GetMapping("/detail/{id}") public String detail(@PathVariable Integer id, Model model) { model.addAttribute("hotel", hotelService.getById(id)); return "hotel/detail"; } }

这里很多人会纠结：Controller层我要不要写Service？直接Mapper不行吗？从功能上确实可以直接注入Mapper，但这样会把业务逻辑和Web层耦合在一起。答辩时老师可能会问“你们项目分了几层”，如果Controller里直接操作数据库，就尴尬了。所以哪怕麻烦一点，也要保留Controller->Service->Mapper这条链路。

Thymeleaf页面渲染时，列表页核心代码长这样：

<div class="row" th:each="hotel : ${page.records}"> <div class="col-md-4"> <div class="card"> <img class="card-img-top" th:src="${hotel.images}" alt=""> <div class="card-body"> <h5 class="card-title" th:text="${hotel.name}">酒店名称</h5> <p class="card-text" th:text="${hotel.address}">地址</p> <p class="card-text text-danger" th:text="${hotel.price} + ' 元/晚'">价格</p> <a class="btn btn-primary" th:href="@{/hotel/detail/{id}(id=${hotel.id})}">查看详情</a> </div> </div> </div> </div>

提交订单的Controller接受一个表单对象，生成订单号并保存：

@PostMapping("/submit") public String submit(Order order) { order.setOrderNo("T" + System.currentTimeMillis()); order.setStatus(0); order.setCreateTime(new Date()); orderService.save(order); return "redirect:/order/my"; }

订单号用时间戳生成，简单但不严谨，如果并发量大会重复。毕设里够用。答辩时你可以说，生产环境会改用“日期+随机数+自增序列”的方式。

3.3 Thymeleaf页面渲染的几种常用姿势

Thymeleaf最常见的用法就是th:text、th:href、th:each、th:if，但有几个细节值得注意。

th:each遍历时，如果还想拿到下标，可以这样写：

<tr th:each="order, iter : ${orderList}"> <td th:text="${iter.count}">1</td> </tr>

th:if条件判断，通常用来做状态显示切换：

<span th:if="${order.status == 0}" class="badge badge-warning">待确认</span> <span th:if="${order.status == 1}" class="badge badge-success">已确认</span>

th:inline可以直接在JavaScript里获取后端数据，这个用起来很香。比如地图页面或者统计页面，有时候需要把后端列表转成JS数组：

<script th:inline="javascript"> var hotelList = [[${hotelList}]]; console.log(hotelList); </script>

但要小心，如果数据量较大，这种内联方式会把数据直接输出到HTML源码里。毕设没问题，生产环境要注意接口脱敏。

3.4 登录拦截与权限控制

预订网站里有两个操作一定需要用户登录：提交订单和个人中心。管理员后台则必须要求role=0。SpringBoot里最方便的方式是用HandlerInterceptor。

先定义拦截器：

public class LoginInterceptor implements HandlerInterceptor { @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { Object user = request.getSession().getAttribute("loginUser"); if (user == null) { response.sendRedirect("/login"); return false; } return true; } }

再定义管理员拦截器，在用户登录基础上再校验角色：

public class AdminInterceptor implements HandlerInterceptor { @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { User user = (User) request.getSession().getAttribute("loginUser"); if (user == null || user.getRole() != 0) { response.sendRedirect("/login"); return false; } return true; } }

然后在配置类里面注册拦截路径：

@Configuration public class WebConfig implements WebMvcConfigurer { @Override public void addInterceptors(InterceptorRegistry registry) { registry.addInterceptor(new LoginInterceptor()) .addPathPatterns("/order/**", "/user/**"); registry.addInterceptor(new AdminInterceptor()) .addPathPatterns("/admin/**"); } }

这里要注意，静态资源路径比如/css/, /js/, /images/**通常不会被拦截，因为它们不是Controller路径，但如果有自定义资源映射，最好也在拦截器里排除掉。

4. 数据库脚本的导入与初始化

4.1 适合新手的数据库准备方式

拿到项目后，第一件事就是建库导数据。我推荐用Navicat或者DataGrip，也可以用IDEA自带的Database面板。如果你电脑上还没装MySQL，建议直接装MySQL 8.0版本，网上有官方安装包。

数据库脚本文件通常是.sql格式，里面包含了CREATE DATABASE、CREATE TABLE和INSERT语句。用Navicat导入时，右键连接，选择“运行SQL文件”，选到项目里的travel.sql即可。导入完成后刷新表列表，能看到8张表就已经成功了。

这里有个小坑：很多从网上下载的项目，SQL脚本里写的字符集是老旧的latin1，导入后中文全是乱码。所以我的脚本开头固定加上：

SET NAMES utf8mb4; SET FOREIGN_KEY_CHECKS = 0;

这样能最大程度避免乱码和外键约束导致的导入失败。另外，如果你用的是MySQL 8.0，而项目连接URL里没有serverTimezone=Asia/Shanghai，启动时大概率会报时区错误。

4.2 IDEA数据库工具导入脚本

对于用IDEA开发的同学，其实不需要额外装Navicat。IDEA右侧的Database面板可以直接连接MySQL。连接成功之后，选中你的数据库，右键“Run SQL Script”，选择travel.sql，就会自动执行。这种方式的好处是，SQL执行日志会在IDEA控制台里展示，如果某条语句报错，你能直接看到是哪张表、哪个字段的问题。

如果项目自带的SQL脚本是旧版本的，导入MySQL 8.0时可能会遇到“datetime”类型默认值的问题。老版本的SQL语句里如果有：

`create_time` datetime DEFAULT '0000-00-00 00:00:00'

这种写法在MySQL 8.0的严格模式下会直接报错。解决方案有两个：一是把默认值改成NULL，二是启动时去掉sql_mode里的NO_ZERO_DATE。我的项目脚本中已经用DEFAULT NULL，不会触发这个问题，但如果你从别处拿的脚本，要特别留意。

4.3 初始化数据与实际运行效果

脚本里不仅要有表结构，还要有几条能看得见的业务数据。比如景点表至少放5条国内知名景点，酒店表放3-5条不同价位的酒店，用户表放一个admin。这些数据在第一次打开网站时就能看到效果，而不是白屏一张。

初始化数据尽量真实一些。比如景点表的图片路径，可以直接用网上可访问的图片URL，也可以先放在本地static/images目录下。如果图片在外面，项目迁移后不会丢；如果在本地，离线演示时也能加载。我建议做两手准备：脚本里存相对路径/images/scenic/xxx.jpg，同时把示例图片打包在项目里。这样无论是演示还是答辩，都不会因为网络问题导致图片显示不了。

我个人在导入脚本后还会做一次“冒烟测试”：启动项目，前台注册一个测试用户，提交一笔酒店订单，再到后台确认订单。如果这一条链路能走通，说明数据库、后端、前端模板基本都没问题。剩下的事情就是按自己的需求去改页面和功能了。

5. 从部署到答辩的实战经验

5.1 本地运行的正确姿势

拿到项目后，第一件事不是急着改代码，而是先把项目跑起来。

第一步，确保JDK版本和项目匹配。SpringBoot 2.x通常要求JDK 8或11，SpringBoot 3.x要求JDK 17以上。我的项目基于SpringBoot 2.7，用JDK 8最稳。有些同学电脑装的是JDK 18，启动时可能会报“IllegalArgumentException”或者一些奇怪的类加载错误。如果遇到这种问题，优先把JDK版本降下来。

第二步，Maven配置。国内网络环境下面，pom.xml第一次加载依赖会比较慢。建议在Maven的settings.xml里配置阿里云镜像。不然卡在下载依赖半个多小时，体验极差。

第三步，启动参数。在IDEA中直接运行TravelApplication类的main方法即可。如果控制台输出“Tomcat started on port(s): 8080”，说明启动成功。然后浏览器访问http://localhost:8080，就能看到网站首页。

这里再提醒一个常见问题：如果你修改了application.yml中的数据库密码，但忘记删掉target目录下的旧classes文件，可能出现配置不生效的情况。IDEA中遇到这种诡异问题，先执行mvn clean，再重新启动。

5.2 常见问题排查速查表

我把这些年帮人调试类似项目时遇到的最高频问题整理成一张表，供大家参考。

还有一点，如果你的项目在别人电脑上跑得好好的，到自己电脑上报错，90%是环境问题，而不是代码问题。JDK版本、MySQL版本、Maven版本一个一个核对，别上来就怀疑源码有bug。

5.3 打包部署到云服务器

现在很多学校答辩会要求“现场演示”，但有些同学觉得自己电脑带过去太麻烦，或者担心现场网络不好，会提前把项目部署到云服务器上。我也建议这么做，因为线上访问演示比本地方便得多。

打包命令很简单：

mvn clean package

构建完成后，target目录下会生成一个travel-0.0.1-SNAPSHOT.jar。在服务器上安装好JDK和MySQL，导入SQL脚本后启动：

java -jar travel-0.0.1-SNAPSHOT.jar --spring.profiles.active=prod

如果不需要多环境，直接把application.yml里的数据库地址改成服务器上的就行。这里有个坑：如果用云服务器，防火墙要开放8080端口，同时MySQL要允许远程连接。MySQL默认只监听127.0.0.1，需要在my.cnf里注释掉bind-address，并给root账号授权远程访问。但注意，这是开发环境做法，真实生产环境千万不要把root开给公网，低版本和弱口令很容易出问题。

6. 项目扩展建议

6.1 代码层面的进一步优化

如果你想让这个项目在答辩时更有亮点，可以从几个方向扩展。

第一，把密码从简单的MD5改成BCrypt加密。Spring Security里自带的BCryptPasswordEncoder就能用，不用引入完整的Spring Security模块。改完之后，注册和登录逻辑都走加密校验，数据库里存的是加密串，看起来更专业。

第二，增加接口参数校验。比如订单提交时，联系人手机号可以用正则校验，价格字段用@DecimalMin限制。SpringBoot自带的validation依赖就能做，代码量不大但能体现细节。

第三，把硬编码的常量抽成枚举或者配置类。比如订单状态0/1/2/3，散落在代码里，到后期很容易记混。定义一个OrderStatus枚举，代码可读性和可维护性都会好很多。

6.2 业务功能层面的扩展

旅游网站还有一个常见功能是搜索。现在很多毕设版的列表页只有分页，没有关键词搜索。加一个搜索功能其实不难，在Controller里接收一个keyword参数，传给Service层时用QueryWrapper的like条件。比如：

QueryWrapper<Scenic> wrapper = new QueryWrapper<>(); wrapper.like(StringUtils.isNotBlank(keyword), "name", keyword);

这样列表页就可以通过搜索框过滤景点和酒店。很实用，展示也多一个点。

另一个值得扩展的是数据统计。后台加一个简单的统计面板，显示今日订单数、累计用户数、热门景点Top5。我建议用ECharts画一个柱状图，数据可以从订单表里按产品ID分组统计。这部分代码不多，但答辩效果非常好。因为老师一看你不仅会增删改查，还能做简单数据分析和可视化，印象分会高不少。

6.3 给即将答辩的同学一些经验

最后再分享一个实际体会：项目能跑只是起点，能讲清楚才算完成。答辩前花点时间梳理一下典型问题，比如“你这个系统和其他预订网站有什么区别”“订单状态是怎么流转的”“如果并发下单你怎么处理”。不需要记长篇大论，能用一两句话把自己的设计逻辑讲明白就行了。

我当时做类似项目时，提前准备了一张系统架构图，从用户浏览器到Controller到Service到Mapper再到数据库，每一步都标好。答辩的时候照着图讲一遍整个流程，老师点点头就知道你是真做了项目的，不是只把别人的代码跑起来。如果你还能现场演示一下“禁用某个用户后，这个用户登录不了”的细节，那基本就稳了。

本文还有配套的精品资源，点击获取