Spring Boot旅游管理系统源码解析：从数据库设计到Docker部署

做了这么多年Java后端，接触过的管理系统少说也有十几个，但旅游这类带明显业务闭环的项目，反而是最能锻炼人的。它不像纯CRUD的后台管理那么枯燥，也不像高并发秒杀系统那样上来就分布式。景点、线路、酒店、订单、状态流转、角色权限，这一套组合拳打下来，Spring Boot的核心知识基本都能覆盖到。今天这篇文章，就把我整理的这套Spring Boot旅游管理系统源码掰开揉碎讲清楚，从数据模型到核心模块，从接口规范到Docker部署，再到实际开发中踩过的那些坑，一次说透。适合正在做毕业设计、想系统学习Spring Boot实战、或者准备接手类似业务系统的朋友参考。

1. 项目定位：这套旅游管理系统到底要解决什么问题

1.1 旅游行业的业务痛点与系统切入点

旅游行业的业务流程天然就带着状态变化的特征：用户浏览景点、选择线路、提交订单、完成支付、出行游玩、事后评价。每个环节都有数据要记录，每个状态都要能追踪，还要区分普通用户和管理员这类不同角色看到的内容。很多刚接触这类项目的人，上来就急着写代码，结果做到一半发现表结构设计不合理，订单状态改不清楚，权限控制一塌糊涂，越写越乱。

这套系统的切入点，就是把一条完整的旅游消费链路拆成清晰的业务模块。用户端覆盖了景点查询、线路浏览、酒店预订、下单支付、收藏评价；管理端则包含用户管理、景点维护、线路发布、酒店管理、订单处理、数据统计。这样设计的好处很明显：业务边界清楚，后端接口的职责天然就分开了，每个模块的增删改查都有明确的业务含义，而不是为了做CRUD而做CRUD。

1.2 面向的读者与适用场景

这个项目我实测下来，最适合三类人参考。第一类是准备毕业设计的同学，系统的功能体量够完整，代码规范可以直接当模板，论文里的需求分析、数据库设计、功能实现这些章节都有现成的素材支撑；第二类是刚工作一两年、想系统梳理Spring Boot实战技能的Java开发，可以从项目里看到统一异常处理、JWT鉴权、状态机设计这些偏工程化的写法；第三类是想做旅游类产品原型验证的开发者，不需要从零开始搭框架，直接拉源码改改就能跑起来演示。

但我要说清楚，这个项目的定位是"完整可用"，不是"高并发架构"。单机部署、MySQL存储、Redis做缓存和Token管理，这个组合已经能支撑中小型旅游管理系统的日常访问量了。如果你的目标是学习分布式、微服务、消息队列，那需要另找专门的项目。

2. 核心需求拆解与数据库表结构设计

2.1 功能模块地图

我习惯在写业务代码之前，先把功能模块画清楚。这套系统分前台和后台两个端，前台面向普通游客，后台面向系统管理员。

前台模块包括：用户注册登录、景点列表与详情、旅游线路推荐、酒店信息查询、在线下单、订单中心、收藏与评价。后台模块包括：管理员登录、用户管理、景点管理、线路管理、酒店管理、订单审核与处理、评价管理、系统公告管理。

每个模块听着简单，但落到数据库设计上就需要仔细规划了。比如景点和线路并不是一对一的，一个景点可能出现在多条线路里，一条线路可能包含多个景点，这种多对多关系如果处理不好，后面查询和扩展都会很痛苦。

2.2 核心数据表及其设计思路

我把这个项目中的核心表整理了一下，总共8张，基本覆盖了整个业务闭环：

这些表里，t_order表是最关键的。很多人第一次做订单表，直接把所有信息塞进去，前端要什么就给什么字段，后患无穷。我的做法是订单表只存关键业务标识和金额快照，用户详细信息和线路酒店信息通过关联查询获取。之所以要存金额快照而不是关联线路表实时算价，是因为价格可能会变，下订单那一刻的价格才是有约束力的，这一点你以后做电商类项目会深有体会。

2.3 外键与索引设计的取舍

这个项目的表之间是有明确关联关系的，但在建表语句里，我基本没有写物理外键约束。原因很实际：物理外键虽然能保证数据一致性，但在高并发写入场景下会带来额外的锁开销，而且后续做分库分表时会成为灾难。项目里我更倾向于通过逻辑外键（即普通的业务ID关联）来维持表之间的关系，配合代码层的事务控制来保证一致性。

索引方面，要给高频查询字段加索引。我实测下来，t_order表的user_id、t_scenic表的name、t_route表的status这几个字段是查询频率最高的，都建了普通索引。如果数据量上去，可以考虑联合索引，比如订单表(user_id, status)的组合，但在数据量不大的阶段，单个索引已经足够，不用过度设计。

3. 技术选型：为什么最终选了Spring Boot 2.7.18这套组合

3.1 Spring Boot版本选型：2.7.x还是3.x

这是我最近被问得最多的问题之一，网上关于"springboot版本太高"的抱怨也一直没断过。我的建议是，这个项目用Spring Boot 2.7.18，不要用Spring Boot 3.x。

原因有以下几点：第一，Spring Boot 3.x强制要求JDK 17及以上，但很多生产服务器和教程环境还停留在JDK 8，尤其是大量毕业设计选型时，导师的环境就是JDK 8；第二，Spring Boot 2.7.x是2.x分支的最后一个版本，官方维护周期覆盖到2023年之后，安全性和稳定性都有保障；第三，很多第三方中间件的兼容版本都是围绕2.x适配的，用3.x经常遇到这个starter不兼容那个包版本的问题，排查起来很浪费时间。

如果你的服务器已经过渡到JDK 17+，未来也没有老环境兼容的顾虑，那直接用Spring Boot 3.x完全没问题，但跟着我这篇文章实操的，建议保持一致用2.7.18。

3.2 持久层框架：MyBatis-Plus更贴合业务开发节奏

ORM框架的选择上，我最终选的是MyBatis-Plus而不是原生的MyBatis或者Spring Data JPA。很多人会纠结这几种方案，我讲讲实际感受。

Spring Data JPA在简单的单表操作上确实效率高，但一旦涉及多表关联和稍微复杂点的查询，就需要写JPQL或者Criteria查询，可读性比较差。原生MyBatis SQL完全可控，但每个Mapper要写一堆XML，单表CRUD也要手动维护，开发效率偏低。

MyBatis-Plus相当于在两者之间取了平衡。它基于MyBatis做了增强，内置了BaseMapper，单表CRUD直接继承就行，不需要写SQL；复杂查询可以用LambdaQueryWrapper构造条件，每个条件写出来就像在念业务需求；分页只要配置一个PaginationInnerInterceptor插件就能用。

3.3 周边组件的搭配：Redis、JWT、Lombok、Hutool

这套系统的周边组件选择主要围绕轻量和高效两个关键词展开。

Redis在这个项目里承担了两件事：一是存储登录Token和用户信息，利用它的过期机制天然支持登录态失效；二是做景点列表数据的缓存，热点数据查询先走Redis，命中不到再查MySQL，有效降低数据库压力。如果本地不想装Redis，可以用Spring Cache的本地缓存替代，但生产环境建议还是上Redis。

JWT用于无状态认证，后端签发Token，前端每次请求带上，后端通过拦截器鉴权。实际项目中我一般在JWT的payload里只放userId和username，不塞额外业务数据，避免Token体积膨胀。

工具类方面，Lombok解决实体类和DTO里大量的getter/setter样板代码，Hutool则提供了一些实用的日期、字符串、加密工具方法，让代码更简洁。

4. 关键模块实现：从注册登录到订单流转的完整链路

4.1 用户认证与角色授权

用户的注册和登录是系统的入口，也是最不能出错的模块。密码存储我使用的是BCrypt加密，这个是Spring Security框架已经集成好的加密算法。BCrypt的特点是自动加盐，同一个密码每次加密结果都不一样，数据库里就算泄露了密码哈希值，也很难逆向还原出原始密码。项目里我没有引入完整的Spring Security，而是引入了spring-security-crypto这个单独模块，只用来做密码加密和校验，因为完整的Security配置在前后端分离项目里说实话工作量不小。

登录成功之后，后端根据用户ID和用户名生成JWT Token返回给前端。前端把Token存到localStorage或者请求头里，之后的每次请求都在Authorization头带上这个Token。拦截器里我定义了白名单，包括登录、注册、获取景点列表、获取线路列表这些基础的查询接口，这些接口不需要登录也能访问；其他接口都会校验Token的有效性。管理员接口还会额外校验用户角色，非管理员直接返回403。

核心的JWT工具类大致是这个结构：

java复制public class JwtUtils {
    private static final String SECRET = "travel-system-secret";
    private static final long EXPIRE_TIME = 7 * 24 * 60 * 60 * 1000L;

    public static String generateToken(Long userId, String username) {
        return Jwts.builder()
                .setSubject(username)
                .claim("userId", userId)
                .setIssuedAt(new Date())
                .setExpiration(new Date(System.currentTimeMillis() + EXPIRE_TIME))
                .signWith(SignatureAlgorithm.HS256, SECRET)
                .compact();
    }

    public static Claims parseToken(String token) {
        return Jwts.parser()
                .setSigningKey(SECRET)
                .parseClaimsJws(token)
                .getBody();
    }
}

4.2 景点与线路管理：多对多关系的前后端落地

景点和线路的关系，在数据库层面是通过线路表里的scenic_ids字段来维护的。每条线路创建时，前端选择多个景点，后端把景点ID拼接成逗号分隔的字符串存进scenic_ids字段。这个方案虽然没那么"范式化"，但在业务体量不大时操作起来非常方便，查询一条线路的景点列表只需一次split再批量查景点表即可，不需要额外维护关联表。

当然这种设计也有代价。如果以后线路和景点需要做更复杂的统计，比如按景点热度统计线路销量，那建议拆出第三张关联表t_route_scenic。我在这个项目里没有拆，原因很简单：当前业务没有这种统计需求，YAGNI原则（你不会需要它的原则）在项目里同样适用。

线路列表接口我做了按状态筛选，后台管理员可以上架或下架线路，前台用户只能看到上架状态的线路。这里有个细节值得注意：状态字段不应该用int类型随意填，我用的是枚举配合MyBatis-Plus的EnumTypeHandler做映射，代码里操作的是OrderStatus.LISTED这种语义明确的枚举，数据库里存的是整数，可读性和扩展性都好。

4.3 订单状态机：把业务状态流转显性化

订单模块是整个系统的核心，也是最容易写乱的地方。我来来回回改了三个版本，最后才稳定下来。订单状态我定义了四种：待支付、已支付、已完成、已取消。状态之间的流转是固定的，不是想怎么跳就怎么跳。

这里最稳妥的做法是写一个状态机枚举，把允许的转换关系显式定义出来：

java复制public enum OrderStatus {
    PENDING_PAYMENT(0, "待支付"),
    PAID(1, "已支付"),
    COMPLETED(2, "已完成"),
    CANCELLED(3, "已取消");

    private final Integer code;
    private final String desc;

    private static final Map<Integer, Set<Integer>> ALLOWED_TRANSITIONS = new HashMap<>();

    static {
        // 待支付可以转为已支付或已取消
        ALLOWED_TRANSITIONS.put(0, new HashSet<>(Arrays.asList(1, 3)));
        // 已支付可以转为已完成
        ALLOWED_TRANSITIONS.put(1, new HashSet<>(Collections.singletonList(2)));
    }

    public boolean canTransitionTo(OrderStatus target) {
        Set<Integer> allowed = ALLOWED_TRANSITIONS.get(this.code);
        return allowed != null && allowed.contains(target.getCode());
    }
}

订单状态流转的时候，先校验当前状态是否允许转移到目标状态，校验通过再做更新操作。这个写法能有效防止前端或者别的接口乱改订单状态，属于偏工程化的防御式编程，实际项目中非常实用。代码里更新订单状态时用的是UPDATE语句加条件WHERE id = ? AND status = ?，利用数据库的行锁特性来防止并发状态覆盖，写法和Spring Data JPA直接save整条记录的思路完全不同，原子性和安全性好很多。

4.4 生成订单号：并发场景下不能忽略的细节

订单号的设计看起来不起眼，但直接关系到后续对账和排查问题。我采用的是"业务标识 + 时间戳 + 随机数"的结构：前缀字母区分业务类型（比如旅游订单用TOUR），中间是yyyyMMddHHmmss格式的时间戳，最后加4位随机数字。

这种方案在同一秒内生成大量订单时存在一定的碰撞概率，但对于这个体量的项目来说已经够了。如果后续数据量大、并发上来了，强烈建议改成分布式ID方案，比如美团开源的Leaf或者简单的雪花算法，核心目的就是保证全局唯一性和趋势递增。

5. 前后端分离下的接口规范与文件资源管理

5.1 统一返回体与全局异常处理

前后端分离的项目里，接口返回数据格式必须统一，否则前端解析逻辑会写的很痛苦。我在项目里封装了一个Result对象，所有接口返回的数据都包一层：

java复制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("操作成功");
        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;
    }
}

光有统一返回体还不够，如果代码里随手throw new RuntimeException，前端收到的就是一堆看不懂的底层堆栈。所以我还写了一个全局异常处理器，用@RestControllerAdvice注解统一拦截异常，业务异常、参数校验异常、系统未知异常分开处理，返回给前端的是一个友好提示和明确的错误码。

5.2 文件上传与资源映射

系统中的景区图片和用户头像都涉及文件上传。文件上传的接口逻辑其实不复杂，核心是MultipartFile接收文件、判断文件类型和大小、生成不重复的文件名、写入本地磁盘目录。真正容易踩坑的地方有两个。

第一个是上传文件的临时目录和大小限制。Spring Boot的默认单文件上传大小限制是1MB，在开发环境随便传个景点照片就可能超限。我在application.yml里显式调大了限制：

yaml复制spring:
  servlet:
    multipart:
      max-file-size: 10MB
      max-request-size: 50MB

第二个是文件访问的URL映射。文件上传到服务器本地磁盘后，不能直接通过浏览器访问。需要在WebMvcConfigurer里配置资源映射，把本地的上传目录暴露为一个虚拟路径，这样前端拿到文件URL才能正常展示图片。这里有一个非常隐蔽的坑：在Spring Boot 2.7.x版本里，拦截器的路径匹配策略默认是AntPathMatcher，但到某些高版本或Spring Boot 3.x之后，默认变成了PathPatternParser，如果你把addResourceHandlers和addInterceptors混用，又用了**通配符，很可能会导致资源映射失效。这个问题我见过好几个同事排查了大半天，实际原因就是版本升级带来的路径匹配规则变化。

5.3 大文件上传断点续传的思考

网上关于springboot如何上传下载大文件的问题一直热度很高。我这套系统目前用不到断点续传，但如果要做，思路其实是清晰的：前端将文件切片，后端提供三个接口——初始化上传、上传分片、合并分片。初始化接口创建文件记录，上传分片接口按序号接收每片数据，合并分片接口把所有分片按序合并成完整文件。后端需要注意的点是：分片要存临时目录，等全部上传完成后再合并，合并时要校验分片完整性。这个方案比直接设置很大的max-file-size要可靠得多，而且支持上传失败后从断点重新上传。

6. 从源码到上线：打包、Docker部署与数据库初始化

6.1 Maven打包配置

Spring Boot项目打的Jar包通常比较大，因为要把所有依赖都打进去。我使用的是Spring Boot Maven插件自带的repackage功能，它会生成一个可执行的fat jar。为了让镜像构建更快，我通常会在pom.xml里配置跳过单元测试，这样打包速度会快很多。

xml复制<build>
    <finalName>travel-system</finalName>
    <plugins>
        <plugin>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-maven-plugin</artifactId>
        </plugin>
    </plugins>
</build>

打包命令很简单：

bash复制mvn clean package -DskipTests

执行完成后，target目录下会生成travel-system.jar，这个文件就是整个系统的可运行产物。

6.2 Docker镜像构建与docker-compose编排

配了JDK 1.8环境的服务器，直接用java -jar命令跑就行。想要更规范一点，就用Docker部署，我这里给出一个实际的Dockerfile示例：

dockerfile复制FROM openjdk:8-jdk-alpine
LABEL maintainer="your-email@example.com"
WORKDIR /app
COPY target/travel-system.jar /app/app.jar
ENV TZ=Asia/Shanghai
RUN ln -snf /usr/share/zoneinfo/$TZ /etc/localtime && echo $TZ > /etc/timezone
EXPOSE 8080
ENTRYPOINT ["java", "-Xms256m", "-Xmx512m", "-jar", "/app/app.jar", "--spring.profiles.active=prod"]

这里有几个细节值得说：ENV TZ=Asia/Shanghai和ln -snf那行是为了把容器时区设置成北京时间，否则数据库里存的日期时间会和本地时间对不上；JVM内存参数-Xms256m和-Xmx512m限制容器的堆内存，避免容器无限制占用宿主机内存。

如果整套系统还包括MySQL和Redis，用docker-compose编排是最省事的，一条命令就能把三个容器拉起来：

yaml复制version: "3"
services:
  mysql:
    image: mysql:8.0
    container_name: travel-mysql
    environment:
      MYSQL_ROOT_PASSWORD: root123
      MYSQL_DATABASE: travel_system
    ports:
      - "3306:3306"
    volumes:
      - ./sql:/docker-entrypoint-initdb.d

  redis:
    image: redis:7
    container_name: travel-redis
    ports:
      - "6379:6379"

  app:
    build: .
    container_name: travel-app
    depends_on:
      - mysql
      - redis
    ports:
      - "8080:8080"
    environment:
      SPRING_DATASOURCE_URL: jdbc:mysql://mysql:3306/travel_system
      SPRING_DATA_REDIS_HOST: redis

这个编排文件里最关键的一点是MySQL镜像的volumes挂载，把宿主机sql目录下的初始化SQL脚本挂载到容器的/docker-entrypoint-initdb.d目录。MySQL容器首次启动时会自动执行这个目录下的所有SQL脚本，这样数据库表结构和初始化数据就自动建好了，不需要手动进容器执行SQL。所谓"springboot jdk1.8打包到docker desktop"，本质就是搞清楚Dockerfile怎么写、镜像怎么构建、容器端口怎么映射，这套流程走通一次，以后任何Java项目都能套用。

6.3 环境配置分离：开发环境和生产环境的切换

我把配置写成了多环境的形式：application.yml是公共配置，application-dev.yml是开发环境配置，application-prod.yml是生产环境配置。通过--spring.profiles.active参数来控制激活哪个环境，本地开发用dev，部署用prod，这个习惯越早养成越好。

生产环境的数据库连接密码不应该硬编码在配置文件里，最推荐的做法是通过环境变量注入。在Dockerfile的ENTRYPOINT或docker-compose的文件里配置环境变量，Spring Boot的配置文件用${DB_PASSWORD}占位符引用，密码只存在于部署环境变量里，不进Git仓库，安全性要好得多。

7. 开发过程中踩过的坑与排查经验

7.1 Service层循环依赖：A依赖B，B又依赖A

这个项目早期version里，我把订单Service和用户Service互相注入，结果Spring容器启动直接报错：The dependencies of some of the beans in the application context form a cycle。当时第一反应是这什么情况？后来debug看调用链才发现，订单Service里要查用户信息，所以注入了UserService；用户Service的删除用户逻辑里要连带处理用户的订单，所以又注入了OrderService。两个Service互相依赖，形成了循环引用。

网上很多人遇到这个问题第一反应是加@Lazy注解，让Spring延迟初始化其中一个Bean，用是能用，但这只是治标不治本。我最后还是通过重构解决的：把用户删除时处理订单的逻辑抽出来放到一个独立的UserOrderCleanupService里，这样OrderService不再依赖UserService，循环依赖自然消失。这个案例给了我一个教训，凡是出现循环依赖，大概率是业务职责边界没切清楚。

7.2 Spring Boot版本太高带来的兼容性问题

前面提到的Spring Boot 3.x升级，实际踩坑案例可太多了。我记得有一次项目升级之后，发现Redis的连接一直失败，定位了半天才发现是Lettuce连接池在Spring Boot 3.x里的默认配置项改了，原来的spring.redis.lettuce.pool属性被拆成了新的配置路径，老配置即使写了也不报错，就是默默不生效。这种问题最烦人，因为不直接报错，只是运行时行为不对，排查起来很费时间。

如果你的项目用了很多第三方starter，升级大版本前一定要先去官方仓库确认兼容版本。比如MyBatis-Plus在Spring Boot 3.x下必须用专门的mybatis-plus-spring-boot3-starter，用老的starter直接启动就报ClassNotFoundException。所以说，生产环境不是越新越好，稳定可靠优先级最高。

7.3 文件上传后无法访问：本地开发和生产环境的路径差异

有一次在本地开发环境下，图片上传成功了，数据库里也存了路径，但浏览器访问图片就是404。排查下来发现是文件上传的保存路径写死了本地绝对路径，换一台机器跑就找不到了。后来我把上传目录配置到application.yml里，通过配置项注入，并在代码里判断目录不存在时自动创建，这才彻底解决问题。

还有一个细节：Windows和Linux的路径分隔符不一样，代码里拼接路径时不要写死/或者\，用Java的File.separator或者Paths.get来拼接，这样跨平台部署就不会踩坑。

7.4 前端跨域配置的"灵异事件"

前后端分离开发时，前端页面跑在Vite的5173端口，后端接口在8080端口，跨域是绕不开的问题。Spring Boot的跨域配置正常很简单，写个CorsFilter或者用@CrossOrigin注解就行。但有一次我配置了全局跨域后，POST请求依然报跨域错误，GET请求却正常。

后来发现是因为请求头里带了Authorization字段，属于非简单请求，浏览器会先发一个OPTIONS预检请求，而我的拦截器把OPTIONS请求拦截了，导致预检请求没有正确返回跨域响应头。解决办法是在拦截器中放行OPTIONS请求，或者让跨域配置的处理顺序先于拦截器。这个坑很典型，网上搜索"springboot 跨域配置失效"能看到大量类似案例。

写在最后

这套旅游管理系统从设计到编码再到部署，前后迭代了大几轮，最大的体会是：业务逻辑的建模能力才是系统开发中的分水岭。代码写得好不好，技术栈新不新，反而是次要的。

我在实际开发里的一个建议是：先从订单状态和核心数据模型入手，把这两块设计稳了，系统的大梁就起来了，其他模块都是锦上添花。如果后续你有精力，可以往这几个方向扩展：引入消息队列处理下单后的异步通知、用定时任务实现超时未支付订单的自动取消、把图片文件从本地存储切换到对象存储OSS、加入Elasticsearch实现景点全文检索。架构演进的路是一步一步走出来的，先把眼前这套系统吃透，比什么都强。