尧图网站建设 
简介面向具备一定Java和Web基础的学习者这套基于Spring Boot的旅游管理系统是一份完整的毕业设计资料包内含项目源码、高分论文、数据库文件以及部署文档说明适用于课程设计、毕业答辩和旅游业务信息化管理实践。系统采用Java与MySQL构建设有管理员和用户双角色涵盖个人中心、景点分类、景点购票、酒店信息及预定、游记分享等主要功能界面设计简洁数据存储经过安全处理。压缩包共858个文件以java源码、vue组件、js脚本、css样式和sql数据库文件为主同时包含xml配置、部署脚本、word论文等整体23.72MB目录结构清晰便于查阅。已有56人学习下载。资料完整呈现了从需求分析、系统设计到编码实现、测试上线的全过程部署说明与论文框架能帮助读者快速复现项目深入理解Spring Boot与数据库设计在实际开发中的落地方式。1. 从 .vue.bak 和 .bat 文件说起这套旅游管理系统凭什么可以直接跑拿到这份资源时我先翻了一遍文件清单发现里面没有常见的README.md而是一堆IndexMain.vue.bak、update-password.vue.bak这类备份文件外加1-install.bat、2-run.bat、3-build.bat三个批处理脚本。这说明它不是一个只用于答辩的静态源码包而是一个能真实跑起来的 Vue Spring Boot 前后端分离项目——.bak后缀暗示作者在开发过程中保留过多次迭代版本脚本的存在则意味着作者自己就是用这套流程在本地部署的。对于准备拿 Spring Boot 做毕业设计、又不想只交一个「能打开的后台页面」的同学来说这类资源的价值恰恰在于它把数据库设计、后端接口、前端页面和部署脚本串成了一条完整的链路。本文不打算逐行朗读源码而是站在「我要把它跑起来并讲清楚原理」的角度把关键模块的设计逻辑、实现方式、部署细节和排错经验拆开讲透。2. 前后端分离下的 Spring Boot 项目结构与四层架构对照2.1 从 .classpath 看项目底层的框架选型文件列表里的.classpath是 Eclipse 或 MyEclipse 工程标记它暴露了一个重要信息这个项目虽然用 VSCode 或 IDEA 也能打开但它的初始工程结构是基于 Eclipse 生态创建的。.classpath里通常会记录源码目录、输出目录和依赖的 classpath 条目如果你用 IDEA 导入建议直接选择「Import Project」而不是「Open」避免 JDK 和依赖路径解析错误。结合3-build.bat这类 Maven 打包脚本可以推断后端是标准的 Spring Boot Maven 工程前端则是 Vue CLI 生成的src/views模块化页面。基于Spring Boot的旅游管理系统 ├── 后端 (Spring Boot MyBatis/MyBatis-Plus) │ ├── controller // 接收前端请求返回 JSON │ ├── service // 业务逻辑层 │ ├── mapper/dao // 数据库访问层 │ ├── entity/pojo // 实体类 │ └── config // 拦截器、安全配置 ├── 前端 (Vue 2 Element UI) │ ├── views // 页面组件 │ ├── router // 路由配置 │ └── api // axios 请求封装 └── sql 数据库脚本提示.classpath中如果有web.resources目录说明静态资源可能仍在src/main/webapp下但 Vue 构建产物通常会在打包后放入resources/static部署时注意区分。这类结构的核心价值在于后端只提供 RESTful API前端通过 axios 请求数据渲染页面。和传统的 JSP Servlet 单体项目比它把「数据操作」和「页面展示」彻底解耦Spring Boot 的自动配置机制又省去了大量 XML 配置这也是它成为毕业设计主流选型的原因。2.2 实体类、Mapper 与 Service 的分层职责以「景点信息管理」模块为例后端代码通常会分成四层。entity/ApartmentScenery.java一类的实体类与数据库表字段一一对应字段命名遵循驼峰式命名法例如数据库字段scenery_name映射为sceneryName。Mapper 层负责 SQL 操作如果用的是 MyBatis-Plus常见的selectPage方法已经内置了分页逻辑不需要手写 LIMIT 子句。// TourismSceneryServiceImpl.java 核心分页查询逻辑 Override public PageScenery getSceneryPage(int pageNum, int pageSize, String name) { PageScenery page new Page(pageNum, pageSize); LambdaQueryWrapperScenery wrapper new LambdaQueryWrapper(); // like 条件拼接name 为空时绕过此条件 wrapper.like(StringUtils.hasText(name), Scenery::getName, name); // 按创建时间倒序保证新上架的景点排前面 wrapper.orderByDesc(Scenery::getCreateTime); return sceneryMapper.selectPage(page, wrapper); }这段代码的关键在于wrapper.like()的第一个参数传递了一个boolean表达式当name为空字符串或 null 时这个条件会被自动忽略。这种写法避免了手动拼接 SQL 时常见的「多一个 AND 导致语法错误」问题。Page对象是 MyBatis-Plus 的分页模型构造参数里的pageNum从 1 开始不是 0前端传参时要注意下标一致否则第一页数据会变成第二页。2.3 Controller 层的统一返回格式与异常处理在真实的旅游管理系统中前端需要根据后端返回的结果决定提示「操作成功」还是「操作失败」。因此 Controller 层几乎不会直接返回List或boolean而是包一层统一响应对象。Result类通常包含code、message、data三个字段code200表示成功code500表示服务器异常。// SceneryController.java 新增景点信息 PostMapping(/add) public Result addScenery(RequestBody Scenery scenery) { if (scenery.getName() null || scenery.getName().trim().isEmpty()) { return Result.error(景点名称不能为空); } boolean success sceneryService.save(scenery); return success ? Result.success(添加成功) : Result.error(添加失败请重试); }这里有两个容易踩坑的细节。第一RequestBody要求前端必须以application/json格式传参如果前端用的是表单提交application/x-www-form-urlencoded会直接抛出HttpMessageNotReadableException第二Result.error()和Result.success()是静态工厂方法但在实际项目中这种返回值层面的 if-else 只适合处理「预期内的业务失败」像数据库连接断开这类不可预期异常应该由全局异常处理器统一拦截避免把堆栈信息直接暴露给前端页面。3. 数据库设计拆解从 ER 图到 MySQL 建表语句的落地过程3.1 用户、景点、酒店、订单之间的关联关系旅游管理系统的表结构通常围绕「用户—景点—酒店—订单」四条主线展开。sys_user表存储管理员和普通用户通过role字段区分scenery表保存景点名称、图片、开放时间、门票价格、剩余票数hotel表记录酒店名称、房型、价格、可订数量而order表则把用户、景点和酒店关联起来。在设计时最容易忽略的是「冗余字段」和「状态字段」的取舍。表名关键字段说明sys_userid, username, password, role, statusrole 区分管理员/用户status 控制账号封禁sceneryid, name, image, price, tickets_total, tickets_lefttickets_left 用于购票余量控制hotel_roomid, hotel_id, room_type, price, stock酒店房间库存按天扣减需结合日期表order_infoid, user_id, type, ref_id, status, create_timetype1 景点票type2 酒店房order_info表设计的巧妙之处在于用type字段区分订单类型而不是分别建scenery_order和hotel_order两张表。这样做的好处是用户「我的订单」页面只需要查一张表坏处是ref_id无法做数据库级外键约束查询时只能通过type判断后再用ref_id回查对应表。对于毕设项目这种折中方案完全可以接受但需要在 Service 层写一个getOrderDetailByType方法来分派查询逻辑。3.2 库存扣减的正确姿势乐观锁代替同步锁在景点购票场景中两个用户同时购买最后一张票时如果代码写成「先查询余票再判断余票大于 0然后扣减」就会产生超卖问题。Spring Boot 单机部署时可以加synchronized关键字但如果是集群部署锁只会作用于单台 JVM依然无效。更稳妥的做法是使用数据库乐观锁在scenery表加一个version字段每次更新时校验版本号。-- 购票时执行的更新语句CAS 思想的应用 UPDATE scenery SET tickets_left tickets_left - 1, version version 1 WHERE id #{sceneryId} AND version #{oldVersion} AND tickets_left 0;这条 SQL 的执行逻辑是只有当数据库里当前行的tickets_left仍然大于 0、version等于我们查询时的旧版本号时才会执行扣减并让版本号加一。如果两个请求同时执行数据库行锁会让一个请求成功、另一个请求的WHERE条件不再成立更新影响行数为 0。Service 层通过判断rows 0就能识别「抢票失败」并返回友好提示。相比SELECT FOR UPDATE悲观锁这种方式在读多写少的场景下性能更好也不存在锁等待和死锁问题。3.3 酒店预定的日期冲突检测酒店预定比景点购票多一个维度日期。用户选择入住日期和离店日期后系统要判断指定房型在这些日期内是否可用。常见做法是建立一张hotel_room_stock表以「房型 ID 日期」为唯一索引每条记录保存当天的剩余间数。-- 查询某房型在入住和离店日期之间是否有连续可用房间 SELECT date, stock FROM hotel_room_stock WHERE room_id #{roomId} AND date BETWEEN #{checkIn} AND #{checkOut} AND stock 0;如果这个查询返回了任何一行说明在入住区间内至少有一天满房预定操作就应该被拒绝。这里有个性能隐患如果查询的日期跨度是 30 天并且每天都有多条记录这条 SQL 在room_id和date没有联合索引时会全表扫描。建表时务必加上UNIQUE KEY uk_room_date (room_id, date)既保证同一天同房型只有一条记录又能让上面的查询快速命中索引。4. 批量脚本背后的部署链路1-install.bat 到 3-build.bat 逐行拆解4.1 三个脚本各自承担的任务边界1-install.bat通常是环境初始化比如自动检测本机是否安装了 JDK 和 Maven2-run.bat是直接以开发模式启动 Spring Boot 后端执行mvn spring-boot:run3-build.bat则是先执行mvn clean package打包成可执行 JAR再启动前端构建。这套设计非常贴近真实项目的「开发—测试—部署」流程先安装依赖再本地调试最后产出正式包。# 1-install.bat 核心片段示意 echo off echo [INFO] 检查 JDK 版本... java -version echo [INFO] 检查 Maven 环境... mvn -v echo [INFO] 安装后端依赖... call mvn clean install -DskipTests提示如果本机用 IDEA 内置的 Mavenmvn命令可能不在 PATH 环境变量中脚本会直接报「不是内部或外部命令」。解决方案是打开 Maven 安装目录的bin文件夹把完整路径复制到系统 PATH 里或者在脚本开头用cd /d D:\apache-maven-3.8.6\bin切换目录。4.2 application.yml 里的三个必改配置项不管脚本里做了什么Spring Boot 项目最终都要通过application.yml或application.properties)来读取配置。旅游管理系统涉及三类关键配置端口号、MySQL 连接信息、MyBatis 映射路径。server: port: 8080 # 后端 API 服务端口 spring: datasource: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://localhost:3306/travel_db?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/ShanghaiuseSSLfalse username: root password: 123456 # 改成你自己的数据库密码 jackson: date-format: yyyy-MM-dd HH:mm:ss # 统一全局日期格式 time-zone: GMT8 mybatis-plus: mapper-locations: classpath:mapper/*.xml configuration: map-underscore-to-camel-case: true # 数据库下划线自动转驼峰这里最容易被忽略的是 JDBC URL 上的serverTimezoneAsia/Shanghai。因为新版 MySQL 驱动默认时区与系统有时差不加这个参数会在运行时报The server time zone value йʱ is unrecognized的错误。另一个是map-underscore-to-camel-case: true它允许实体类的hotelName字段直接映射数据库表的hotel_name列省去大量TableField注解。4.3 数据库初始化与账号权限数据库文件通常是.sql脚本或.sql.bak备份文件。用 Navicat 或命令行导入时要注意两点先建数据库再导入表导入时选择 UTF-8 编码。命令行的导入姿势是mysql -u root -p travel_db travel_db.sql如果报错Unknown database travel_db说明脚本里没有包含建库语句或执行前没有手动建库。顺便核对一下sys_user表里的初始管理员账号密码很多项目的默认密码在插入语句里是明文或简易加密串登录前先用 SQL 查一下避免在登录页卡在「用户名或密码错误」。5. 用 JPA 与 MyBatis 混合开发时的事务边界一个容易翻车的组合5.1 事务注解的失效场景不少旅游管理系统为了赶进度会在同一个 Service 类里同时使用 Spring Data JPA 的 Repository 和 MyBatis 的 Mapper。两者并存不是问题真正的问题是事务管理。比如「购买景点票」这个操作既要用 MyBatis 更新景点余票又要用 JPA 插入订单记录。如果在同一个方法上加Transactional却因为 JPA 和 MyBatis 的数据源配置不同导致事务管理器不确定用哪一个就会静默失效。// 购票事务示例需要保证余票扣减与订单插入同生共死 Transactional(rollbackFor Exception.class) public boolean buyTicket(Long userId, Long sceneryId, Integer count) { int rows sceneryMapper.deductTickets(sceneryId, count); if (rows 0) { throw new BusinessException(余票不足扣减失败); } OrderInfo order new OrderInfo(); order.setUserId(userId); order.setRefId(sceneryId); order.setType(1); order.setStatus(0); orderInfoRepository.save(order); // JPA return true; }一个非常隐蔽的坑是标注Transactional的方法被同类内部的另一个方法调用时事务会失效。因为 Spring 的事务是基于 AOP 代理实现的同类调用绕过了代理对象。解决办法是把事务方法拆分到不同的 Service 类中或者使用AopContext.currentProxy()获取当前类的代理对象。另外rollbackFor Exception.class是必写项否则运行时只回滚RuntimeException而像SQLException这类受检异常默认不会触发回滚。5.2 Controller 层直接操作 JPA Repository 的坏味道阅卷老师或评审专家通常不喜欢在 Controller 里看到xxxRepository.save()或xxxMapper.selectById()直接出现。这暴露了一个问题业务逻辑没有被封装到 Service 层。在旅游管理系统的「游记分享管理」模块中用户发布一篇游记既要保存游记标题和正文又要更新用户的「游记数」字段。如果 Controller 里连续调用两个数据层方法中途出错会导致数据不一致而且代码不可复用。// TravelNotesServiceImpl.java 发布游记的标准做法 Override Transactional(rollbackFor Exception.class) public Long publishNote(String title, String content, Long userId) { TravelNote note new TravelNote(); note.setTitle(title); note.setContent(content); note.setUserId(userId); note.setStatus(1); // 1已发布 travelNoteMapper.insert(note); userTravelStatMapper.incrementNoteCount(userId); return note.getId(); }incrementNoteCount是通过一条UPDATE user_stat SET note_count note_count 1 WHERE user_id #{userId}实现的它利用数据库自身的原子操作避免了「先查再改」的并发问题。这个模式在景区点赞、收藏功能中也同样适用——避免把count 1的累加操作放在 Java 层做因为那是非原子操作。5.3 延迟加载与 JSON 序列化的冲突后端代码在详情页需要同时返回景点信息和该景点下的购票记录时有些人会写出类似Scenery实体中直接维护一个ListOrderInfo字段。但 MyBatis 的嵌套查询默认是懒加载当 Jackson 序列化结果为 JSON 时如果 session 已经关闭就会冒出LazyInitializationException。一个务实的解决方法是使用 MyBatis-Plus 的分步查询或TableField(exist false)配合selectById手动组装而不是依赖实体类内的关联集合。前端要什么数据结构后端就组装什么而不是简单地把数据库表结构原样抛给前端。6. Spring Boot 多环境配置把旅游系统的部署拆成 dev 和 prod 两套流程6.1 从2-run.bat联想到的 profile 配置必要性2-run.bat执行的spring-boot:run默认走 dev 环境但当你用3-build.bat打出 JAR 包部署到服务器时同一份配置里的数据库密码、端口号不可能继续沿用本机的localhost:3306。Spring Boot 的profiles机制可以完美解决这一点不需要维护两个 JAR 包而是通过启动参数切换配置。# application-dev.yml 本地开发环境 server: port: 8080 spring: datasource: url: jdbc:mysql://localhost:3306/travel_dev username: root password: root123 # application-prod.yml 服务器生产环境 server: port: 9090 spring: datasource: url: jdbc:mysql://10.1.2.100:3306/travel_prod username: deployer password: x7fQ#s2L启动时用--spring.profiles.activeprod指定使用哪一套配置。如果没有指定Spring Boot 会读取默认的application.yml所以在默认文件里写spring.profiles.active: dev比较稳妥避免本地调试时误连生产库。6.2 打包 JAR 并部署到 CentOS 服务器前端项目构建后生成dist目录里面是纯静态文件可以放进 Nginx 的html目录并通过反向代理把/api开头的请求转发到后端9090端口。后端 JAR 包直接放置到/opt/travel目录下用nohup后台启动# 构建后端跳过测试 mvn clean package -DskipTests # 后台启动 nohup java -jar travel-system.jar --spring.profiles.activeprod /opt/travel/logs/app.log 21 这里有一个小技巧21把标准错误输出合并到标准输出日志文件里。启动后立刻查看日志确认没有任何ERROR级别的记录再用tail -f观察Tomcat started on port(s): 9090字样。如果端口一直被占用用lsof -i:9090找到占用进程并评估是关闭旧服务还是换一个端口。6.3 用 Actuator 做部署后的健康检查在pom.xml中加入spring-boot-starter-actuator后访问/actuator/health可以返回服务健康状态和数据库连接情况。旅游系统牵涉到 MySQL 数据库健康指数里db一项会显示UP或DOWN。curl http://127.0.0.1:9090/actuator/health返回示例{status:UP,components:{db:{status:UP},diskSpace:{status:UP}}}如果status显示DOWN优先查看 MySQL 是否允许远程连接、数据库账号是否存在、JDBC URL 中的 IP 是否通。生产环境部署时记得用 Spring Security 对/actuator/**接口加权限控制避免敏感指标被未授权访问——这正是热词里频繁提到的安全要点。通过这些配置和命令整个旅游管理系统才真正完成了从「本地开发源码」到「可交付部署项目」的全流程闭环部署文档说明里写的每一步也都能在这几组操作里一一得到验证。本文还有配套的精品资源点击获取 Spring Boot旅游管理系统实战剖析：前后端分离与部署全流程
简介面向具备一定Java和Web基础的学习者这套基于Spring Boot的旅游管理系统是一份完整的毕业设计资料包内含项目源码、高分论文、数据库文件以及部署文档说明适用于课程设计、毕业答辩和旅游业务信息化管理实践。系统采用Java与MySQL构建设有管理员和用户双角色涵盖个人中心、景点分类、景点购票、酒店信息及预定、游记分享等主要功能界面设计简洁数据存储经过安全处理。压缩包共858个文件以java源码、vue组件、js脚本、css样式和sql数据库文件为主同时包含xml配置、部署脚本、word论文等整体23.72MB目录结构清晰便于查阅。已有56人学习下载。资料完整呈现了从需求分析、系统设计到编码实现、测试上线的全过程部署说明与论文框架能帮助读者快速复现项目深入理解Spring Boot与数据库设计在实际开发中的落地方式。1. 从 .vue.bak 和 .bat 文件说起这套旅游管理系统凭什么可以直接跑拿到这份资源时我先翻了一遍文件清单发现里面没有常见的README.md而是一堆IndexMain.vue.bak、update-password.vue.bak这类备份文件外加1-install.bat、2-run.bat、3-build.bat三个批处理脚本。这说明它不是一个只用于答辩的静态源码包而是一个能真实跑起来的 Vue Spring Boot 前后端分离项目——.bak后缀暗示作者在开发过程中保留过多次迭代版本脚本的存在则意味着作者自己就是用这套流程在本地部署的。对于准备拿 Spring Boot 做毕业设计、又不想只交一个「能打开的后台页面」的同学来说这类资源的价值恰恰在于它把数据库设计、后端接口、前端页面和部署脚本串成了一条完整的链路。本文不打算逐行朗读源码而是站在「我要把它跑起来并讲清楚原理」的角度把关键模块的设计逻辑、实现方式、部署细节和排错经验拆开讲透。2. 前后端分离下的 Spring Boot 项目结构与四层架构对照2.1 从 .classpath 看项目底层的框架选型文件列表里的.classpath是 Eclipse 或 MyEclipse 工程标记它暴露了一个重要信息这个项目虽然用 VSCode 或 IDEA 也能打开但它的初始工程结构是基于 Eclipse 生态创建的。.classpath里通常会记录源码目录、输出目录和依赖的 classpath 条目如果你用 IDEA 导入建议直接选择「Import Project」而不是「Open」避免 JDK 和依赖路径解析错误。结合3-build.bat这类 Maven 打包脚本可以推断后端是标准的 Spring Boot Maven 工程前端则是 Vue CLI 生成的src/views模块化页面。基于Spring Boot的旅游管理系统 ├── 后端 (Spring Boot MyBatis/MyBatis-Plus) │ ├── controller // 接收前端请求返回 JSON │ ├── service // 业务逻辑层 │ ├── mapper/dao // 数据库访问层 │ ├── entity/pojo // 实体类 │ └── config // 拦截器、安全配置 ├── 前端 (Vue 2 Element UI) │ ├── views // 页面组件 │ ├── router // 路由配置 │ └── api // axios 请求封装 └── sql 数据库脚本提示.classpath中如果有web.resources目录说明静态资源可能仍在src/main/webapp下但 Vue 构建产物通常会在打包后放入resources/static部署时注意区分。这类结构的核心价值在于后端只提供 RESTful API前端通过 axios 请求数据渲染页面。和传统的 JSP Servlet 单体项目比它把「数据操作」和「页面展示」彻底解耦Spring Boot 的自动配置机制又省去了大量 XML 配置这也是它成为毕业设计主流选型的原因。2.2 实体类、Mapper 与 Service 的分层职责以「景点信息管理」模块为例后端代码通常会分成四层。entity/ApartmentScenery.java一类的实体类与数据库表字段一一对应字段命名遵循驼峰式命名法例如数据库字段scenery_name映射为sceneryName。Mapper 层负责 SQL 操作如果用的是 MyBatis-Plus常见的selectPage方法已经内置了分页逻辑不需要手写 LIMIT 子句。// TourismSceneryServiceImpl.java 核心分页查询逻辑 Override public PageScenery getSceneryPage(int pageNum, int pageSize, String name) { PageScenery page new Page(pageNum, pageSize); LambdaQueryWrapperScenery wrapper new LambdaQueryWrapper(); // like 条件拼接name 为空时绕过此条件 wrapper.like(StringUtils.hasText(name), Scenery::getName, name); // 按创建时间倒序保证新上架的景点排前面 wrapper.orderByDesc(Scenery::getCreateTime); return sceneryMapper.selectPage(page, wrapper); }这段代码的关键在于wrapper.like()的第一个参数传递了一个boolean表达式当name为空字符串或 null 时这个条件会被自动忽略。这种写法避免了手动拼接 SQL 时常见的「多一个 AND 导致语法错误」问题。Page对象是 MyBatis-Plus 的分页模型构造参数里的pageNum从 1 开始不是 0前端传参时要注意下标一致否则第一页数据会变成第二页。2.3 Controller 层的统一返回格式与异常处理在真实的旅游管理系统中前端需要根据后端返回的结果决定提示「操作成功」还是「操作失败」。因此 Controller 层几乎不会直接返回List或boolean而是包一层统一响应对象。Result类通常包含code、message、data三个字段code200表示成功code500表示服务器异常。// SceneryController.java 新增景点信息 PostMapping(/add) public Result addScenery(RequestBody Scenery scenery) { if (scenery.getName() null || scenery.getName().trim().isEmpty()) { return Result.error(景点名称不能为空); } boolean success sceneryService.save(scenery); return success ? Result.success(添加成功) : Result.error(添加失败请重试); }这里有两个容易踩坑的细节。第一RequestBody要求前端必须以application/json格式传参如果前端用的是表单提交application/x-www-form-urlencoded会直接抛出HttpMessageNotReadableException第二Result.error()和Result.success()是静态工厂方法但在实际项目中这种返回值层面的 if-else 只适合处理「预期内的业务失败」像数据库连接断开这类不可预期异常应该由全局异常处理器统一拦截避免把堆栈信息直接暴露给前端页面。3. 数据库设计拆解从 ER 图到 MySQL 建表语句的落地过程3.1 用户、景点、酒店、订单之间的关联关系旅游管理系统的表结构通常围绕「用户—景点—酒店—订单」四条主线展开。sys_user表存储管理员和普通用户通过role字段区分scenery表保存景点名称、图片、开放时间、门票价格、剩余票数hotel表记录酒店名称、房型、价格、可订数量而order表则把用户、景点和酒店关联起来。在设计时最容易忽略的是「冗余字段」和「状态字段」的取舍。表名关键字段说明sys_userid, username, password, role, statusrole 区分管理员/用户status 控制账号封禁sceneryid, name, image, price, tickets_total, tickets_lefttickets_left 用于购票余量控制hotel_roomid, hotel_id, room_type, price, stock酒店房间库存按天扣减需结合日期表order_infoid, user_id, type, ref_id, status, create_timetype1 景点票type2 酒店房order_info表设计的巧妙之处在于用type字段区分订单类型而不是分别建scenery_order和hotel_order两张表。这样做的好处是用户「我的订单」页面只需要查一张表坏处是ref_id无法做数据库级外键约束查询时只能通过type判断后再用ref_id回查对应表。对于毕设项目这种折中方案完全可以接受但需要在 Service 层写一个getOrderDetailByType方法来分派查询逻辑。3.2 库存扣减的正确姿势乐观锁代替同步锁在景点购票场景中两个用户同时购买最后一张票时如果代码写成「先查询余票再判断余票大于 0然后扣减」就会产生超卖问题。Spring Boot 单机部署时可以加synchronized关键字但如果是集群部署锁只会作用于单台 JVM依然无效。更稳妥的做法是使用数据库乐观锁在scenery表加一个version字段每次更新时校验版本号。-- 购票时执行的更新语句CAS 思想的应用 UPDATE scenery SET tickets_left tickets_left - 1, version version 1 WHERE id #{sceneryId} AND version #{oldVersion} AND tickets_left 0;这条 SQL 的执行逻辑是只有当数据库里当前行的tickets_left仍然大于 0、version等于我们查询时的旧版本号时才会执行扣减并让版本号加一。如果两个请求同时执行数据库行锁会让一个请求成功、另一个请求的WHERE条件不再成立更新影响行数为 0。Service 层通过判断rows 0就能识别「抢票失败」并返回友好提示。相比SELECT FOR UPDATE悲观锁这种方式在读多写少的场景下性能更好也不存在锁等待和死锁问题。3.3 酒店预定的日期冲突检测酒店预定比景点购票多一个维度日期。用户选择入住日期和离店日期后系统要判断指定房型在这些日期内是否可用。常见做法是建立一张hotel_room_stock表以「房型 ID 日期」为唯一索引每条记录保存当天的剩余间数。-- 查询某房型在入住和离店日期之间是否有连续可用房间 SELECT date, stock FROM hotel_room_stock WHERE room_id #{roomId} AND date BETWEEN #{checkIn} AND #{checkOut} AND stock 0;如果这个查询返回了任何一行说明在入住区间内至少有一天满房预定操作就应该被拒绝。这里有个性能隐患如果查询的日期跨度是 30 天并且每天都有多条记录这条 SQL 在room_id和date没有联合索引时会全表扫描。建表时务必加上UNIQUE KEY uk_room_date (room_id, date)既保证同一天同房型只有一条记录又能让上面的查询快速命中索引。4. 批量脚本背后的部署链路1-install.bat 到 3-build.bat 逐行拆解4.1 三个脚本各自承担的任务边界1-install.bat通常是环境初始化比如自动检测本机是否安装了 JDK 和 Maven2-run.bat是直接以开发模式启动 Spring Boot 后端执行mvn spring-boot:run3-build.bat则是先执行mvn clean package打包成可执行 JAR再启动前端构建。这套设计非常贴近真实项目的「开发—测试—部署」流程先安装依赖再本地调试最后产出正式包。# 1-install.bat 核心片段示意 echo off echo [INFO] 检查 JDK 版本... java -version echo [INFO] 检查 Maven 环境... mvn -v echo [INFO] 安装后端依赖... call mvn clean install -DskipTests提示如果本机用 IDEA 内置的 Mavenmvn命令可能不在 PATH 环境变量中脚本会直接报「不是内部或外部命令」。解决方案是打开 Maven 安装目录的bin文件夹把完整路径复制到系统 PATH 里或者在脚本开头用cd /d D:\apache-maven-3.8.6\bin切换目录。4.2 application.yml 里的三个必改配置项不管脚本里做了什么Spring Boot 项目最终都要通过application.yml或application.properties)来读取配置。旅游管理系统涉及三类关键配置端口号、MySQL 连接信息、MyBatis 映射路径。server: port: 8080 # 后端 API 服务端口 spring: datasource: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://localhost:3306/travel_db?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/ShanghaiuseSSLfalse username: root password: 123456 # 改成你自己的数据库密码 jackson: date-format: yyyy-MM-dd HH:mm:ss # 统一全局日期格式 time-zone: GMT8 mybatis-plus: mapper-locations: classpath:mapper/*.xml configuration: map-underscore-to-camel-case: true # 数据库下划线自动转驼峰这里最容易被忽略的是 JDBC URL 上的serverTimezoneAsia/Shanghai。因为新版 MySQL 驱动默认时区与系统有时差不加这个参数会在运行时报The server time zone value йʱ is unrecognized的错误。另一个是map-underscore-to-camel-case: true它允许实体类的hotelName字段直接映射数据库表的hotel_name列省去大量TableField注解。4.3 数据库初始化与账号权限数据库文件通常是.sql脚本或.sql.bak备份文件。用 Navicat 或命令行导入时要注意两点先建数据库再导入表导入时选择 UTF-8 编码。命令行的导入姿势是mysql -u root -p travel_db travel_db.sql如果报错Unknown database travel_db说明脚本里没有包含建库语句或执行前没有手动建库。顺便核对一下sys_user表里的初始管理员账号密码很多项目的默认密码在插入语句里是明文或简易加密串登录前先用 SQL 查一下避免在登录页卡在「用户名或密码错误」。5. 用 JPA 与 MyBatis 混合开发时的事务边界一个容易翻车的组合5.1 事务注解的失效场景不少旅游管理系统为了赶进度会在同一个 Service 类里同时使用 Spring Data JPA 的 Repository 和 MyBatis 的 Mapper。两者并存不是问题真正的问题是事务管理。比如「购买景点票」这个操作既要用 MyBatis 更新景点余票又要用 JPA 插入订单记录。如果在同一个方法上加Transactional却因为 JPA 和 MyBatis 的数据源配置不同导致事务管理器不确定用哪一个就会静默失效。// 购票事务示例需要保证余票扣减与订单插入同生共死 Transactional(rollbackFor Exception.class) public boolean buyTicket(Long userId, Long sceneryId, Integer count) { int rows sceneryMapper.deductTickets(sceneryId, count); if (rows 0) { throw new BusinessException(余票不足扣减失败); } OrderInfo order new OrderInfo(); order.setUserId(userId); order.setRefId(sceneryId); order.setType(1); order.setStatus(0); orderInfoRepository.save(order); // JPA return true; }一个非常隐蔽的坑是标注Transactional的方法被同类内部的另一个方法调用时事务会失效。因为 Spring 的事务是基于 AOP 代理实现的同类调用绕过了代理对象。解决办法是把事务方法拆分到不同的 Service 类中或者使用AopContext.currentProxy()获取当前类的代理对象。另外rollbackFor Exception.class是必写项否则运行时只回滚RuntimeException而像SQLException这类受检异常默认不会触发回滚。5.2 Controller 层直接操作 JPA Repository 的坏味道阅卷老师或评审专家通常不喜欢在 Controller 里看到xxxRepository.save()或xxxMapper.selectById()直接出现。这暴露了一个问题业务逻辑没有被封装到 Service 层。在旅游管理系统的「游记分享管理」模块中用户发布一篇游记既要保存游记标题和正文又要更新用户的「游记数」字段。如果 Controller 里连续调用两个数据层方法中途出错会导致数据不一致而且代码不可复用。// TravelNotesServiceImpl.java 发布游记的标准做法 Override Transactional(rollbackFor Exception.class) public Long publishNote(String title, String content, Long userId) { TravelNote note new TravelNote(); note.setTitle(title); note.setContent(content); note.setUserId(userId); note.setStatus(1); // 1已发布 travelNoteMapper.insert(note); userTravelStatMapper.incrementNoteCount(userId); return note.getId(); }incrementNoteCount是通过一条UPDATE user_stat SET note_count note_count 1 WHERE user_id #{userId}实现的它利用数据库自身的原子操作避免了「先查再改」的并发问题。这个模式在景区点赞、收藏功能中也同样适用——避免把count 1的累加操作放在 Java 层做因为那是非原子操作。5.3 延迟加载与 JSON 序列化的冲突后端代码在详情页需要同时返回景点信息和该景点下的购票记录时有些人会写出类似Scenery实体中直接维护一个ListOrderInfo字段。但 MyBatis 的嵌套查询默认是懒加载当 Jackson 序列化结果为 JSON 时如果 session 已经关闭就会冒出LazyInitializationException。一个务实的解决方法是使用 MyBatis-Plus 的分步查询或TableField(exist false)配合selectById手动组装而不是依赖实体类内的关联集合。前端要什么数据结构后端就组装什么而不是简单地把数据库表结构原样抛给前端。6. Spring Boot 多环境配置把旅游系统的部署拆成 dev 和 prod 两套流程6.1 从2-run.bat联想到的 profile 配置必要性2-run.bat执行的spring-boot:run默认走 dev 环境但当你用3-build.bat打出 JAR 包部署到服务器时同一份配置里的数据库密码、端口号不可能继续沿用本机的localhost:3306。Spring Boot 的profiles机制可以完美解决这一点不需要维护两个 JAR 包而是通过启动参数切换配置。# application-dev.yml 本地开发环境 server: port: 8080 spring: datasource: url: jdbc:mysql://localhost:3306/travel_dev username: root password: root123 # application-prod.yml 服务器生产环境 server: port: 9090 spring: datasource: url: jdbc:mysql://10.1.2.100:3306/travel_prod username: deployer password: x7fQ#s2L启动时用--spring.profiles.activeprod指定使用哪一套配置。如果没有指定Spring Boot 会读取默认的application.yml所以在默认文件里写spring.profiles.active: dev比较稳妥避免本地调试时误连生产库。6.2 打包 JAR 并部署到 CentOS 服务器前端项目构建后生成dist目录里面是纯静态文件可以放进 Nginx 的html目录并通过反向代理把/api开头的请求转发到后端9090端口。后端 JAR 包直接放置到/opt/travel目录下用nohup后台启动# 构建后端跳过测试 mvn clean package -DskipTests # 后台启动 nohup java -jar travel-system.jar --spring.profiles.activeprod /opt/travel/logs/app.log 21 这里有一个小技巧21把标准错误输出合并到标准输出日志文件里。启动后立刻查看日志确认没有任何ERROR级别的记录再用tail -f观察Tomcat started on port(s): 9090字样。如果端口一直被占用用lsof -i:9090找到占用进程并评估是关闭旧服务还是换一个端口。6.3 用 Actuator 做部署后的健康检查在pom.xml中加入spring-boot-starter-actuator后访问/actuator/health可以返回服务健康状态和数据库连接情况。旅游系统牵涉到 MySQL 数据库健康指数里db一项会显示UP或DOWN。curl http://127.0.0.1:9090/actuator/health返回示例{status:UP,components:{db:{status:UP},diskSpace:{status:UP}}}如果status显示DOWN优先查看 MySQL 是否允许远程连接、数据库账号是否存在、JDBC URL 中的 IP 是否通。生产环境部署时记得用 Spring Security 对/actuator/**接口加权限控制避免敏感指标被未授权访问——这正是热词里频繁提到的安全要点。通过这些配置和命令整个旅游管理系统才真正完成了从「本地开发源码」到「可交付部署项目」的全流程闭环部署文档说明里写的每一步也都能在这几组操作里一一得到验证。本文还有配套的精品资源点击获取