企业官网建设流程全解析

简介：一份基于SpringBoot+Vue开发的旅游管理系统毕业设计源码包，面向计算机相关专业毕业生、课程设计及期末大作业需求者，也适合希望学习前后端分离项目的初中级开发者。系统覆盖管理员与用户双端，包含景点信息、旅游线路、公告文章、变幻图、用户资料管理及系统设置等模块，功能完整、界面直观，可直接作为毕业设计或课程设计参考。压缩包共857个文件，容量24.16MB，核心由139个Java源码、51个Vue组件、47个HTML页面及配套CSS、JS构成，另含SQL脚本和部署批次文件，便于快速搭建运行环境。资源同时附有万字报告文档、部署说明与演示PPT，代码包含注释并经过测试，能够帮助读者快速理解项目结构、掌握SpringBoot+Vue整合开发思路，也可用于答辩展示与二次开发。目前已有238人学习下载，适合需要完整项目方案、快速验证或深入研读源码的读者。

1. 旅游管理系统，毕业设计里最不会翻车的Java选题之一

旅游管理系统在Java毕业设计里属于“不会惊艳全场，但几乎不会翻车”的选题。游客注册登录、景点信息展示、线路下单、支付状态流转、后台管理维护，这一套业务刚好把Java Web开发的核心知识点全部串起来：Controller层接收请求、Service层写业务逻辑、DAO层操作数据库、JWT控制登录态。更关键的是它的业务复杂度适中，一个人在一两个月内能独立做完，答辩时导师从需求、数据库、部署三个方向追问，你都有东西可答。适合两类人：一类是Java基础能写增删改查、想在最短时间拿出完整可演示项目的应届生；另一类是已经工作、需要用一套源码快速了解Spring Boot项目结构的开发者。这篇笔记按完整落地路径来讲：先定技术选型和表结构，再拆三个核心模块的实现思路，最后把部署流程和典型踩坑讲透。

2. 技术选型与项目结构：骨架立不对，后面每步都在返工

2.1 Spring Boot 2.7还是SSM：毕设场景下的选型逻辑

先给结论：能用Spring Boot就不用SSM。旅游管理系统里要处理登录拦截、事务、JSON返回、文件上传、异常统一处理，SSM方案得写一堆spring-mvc.xml、web.xml的配置，每加一个拦截器或数据源就要去翻XML，出了问题排查链路特别长。Spring Boot用注解和自动配置把这些大部分收敛掉了，你只需要关注application.yml和业务代码。

版本组合上，我一般推荐Spring Boot 2.7.x + JDK 8/11 + MySQL 5.7/8.0 + MyBatis。这套组合有三个现实理由：第一，多数学校机房和毕业设计验收环境还是JDK 8，你本机用JDK 17写的代码部署到实验室机器上可能直接跑不起来；第二，Spring Boot 2.7还在社区维护期内，网上搜得到的插件、博客、踩坑帖基本都兼容它；第三，MyBatis的starter在2.7下用mybatis-spring-boot-starter 2.2.x就能稳定工作，不需要处理Spring Boot 3带来的javax到jakarta坐标迁移。

前端方案见表1，你按自己的时间和答辩要求选。

这条笔记的实现讲解以Spring Boot + Thymeleaf为主，因为这是最容易完整落地、也最容易复现的路径。你要是选Vue方案，后端接口设计照样能用，只是多一层跨域配置和静态资源映射。

2.2 数据库表设计：五张核心表怎么建才像真实项目

旅游管理系统的表不用建太多，但每一张都要能讲清楚“为什么存在”。最常见的做法是五张核心表：用户表、景点表、线路表、订单表、评论表。用户表管登录和角色，景点表存旅游资源的静态信息，线路表把多个景点组合成可售卖的产品，订单表关联用户和线路并承载交易状态，评论表做用户互动。订单表必须单独拆出来，因为一个用户会买多条线路，一条线路会被多个用户购买，订单就是中间实体，同时承担金额和状态字段。

建表时要注意几个容易在验收时被导师问住的点：一是密码字段不要存明文，用BCrypt生成的60位哈希值存储；二是金额字段用DECIMAL(10,2)而不是FLOAT，浮点数计算金额会出现精度问题；三是订单状态用varchar存中文枚举值，比如“待支付”、“已支付”、“已取消”，不要用0/1/2的数字，导师看数据库一眼就能懂。下面是初始化的SQL脚本，包含核心表的建表语句：

CREATE TABLE t_user ( id BIGINT PRIMARY KEY AUTO_INCREMENT COMMENT '用户ID', username VARCHAR(50) NOT NULL UNIQUE COMMENT '用户名', password VARCHAR(100) NOT NULL COMMENT 'BCrypt加密后的密码', phone VARCHAR(20) COMMENT '手机号', role VARCHAR(20) DEFAULT 'USER' COMMENT '角色：USER/ADMIN', create_time DATETIME DEFAULT CURRENT_TIMESTAMP COMMENT '注册时间' ) ENGINE=InnoDB COMMENT '用户表'; CREATE TABLE t_scenic ( id BIGINT PRIMARY KEY AUTO_INCREMENT COMMENT '景点ID', name VARCHAR(100) NOT NULL COMMENT '景点名称', city VARCHAR(50) COMMENT '所在城市', intro TEXT COMMENT '景点简介', image_url VARCHAR(255) COMMENT '图片URL', price DECIMAL(10,2) COMMENT '门票价格', open_time VARCHAR(50) COMMENT '开放时间说明' ) ENGINE=InnoDB COMMENT '景点表'; CREATE TABLE t_route ( id BIGINT PRIMARY KEY AUTO_INCREMENT COMMENT '线路ID', name VARCHAR(100) NOT NULL COMMENT '线路名称', days INT COMMENT '行程天数', price DECIMAL(10,2) COMMENT '线路价格', scenic_ids VARCHAR(500) COMMENT '包含景点ID，逗号分隔', cover_url VARCHAR(255) COMMENT '封面图URL' ) ENGINE=InnoDB COMMENT '旅游线路表'; CREATE TABLE t_order ( id BIGINT PRIMARY KEY AUTO_INCREMENT COMMENT '订单ID', user_id BIGINT NOT NULL COMMENT '下单用户ID', route_id BIGINT NOT NULL COMMENT '线路ID', travel_date DATE COMMENT '出行日期', person_count INT DEFAULT 1 COMMENT '出行人数', total_amount DECIMAL(10,2) COMMENT '总金额', status VARCHAR(20) DEFAULT '待支付' COMMENT '订单状态', pay_no VARCHAR(64) COMMENT '支付单号', create_time DATETIME DEFAULT CURRENT_TIMESTAMP COMMENT '下单时间', KEY idx_user_id (user_id), KEY idx_route_id (route_id) ) ENGINE=InnoDB COMMENT '订单表';

说两个容易被忽略的参数：第一，所有表都用ENGINE=InnoDB，它支持事务和外键，innodb引擎在订单支付场景下才能保证数据一致性，MyISAM是做不到行级锁和崩溃恢复的；第二，订单表的user_id和route_id要建普通索引，否则后台按用户查订单时会全表扫描，数据量上百条感觉不出来，答辩时如果导师问“数据库怎么优化”，你能答出索引这个点就是加分项。

2.3 项目初始化：pom.xml和application.yml一次配到位

Maven依赖配置是整个系统的地基。Spring Boot 2.7.18这个版本号建议锁死，不要用2.7.x通配，避免某天Maven拉到一个有兼容问题的补丁版。核心依赖包含web、thymeleaf、mybatis、mysql驱动、lombok、jjwt这几组。具体配置如下：

<parent> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-parent</artifactId> <version>2.7.18</version> </parent> <dependencies> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-thymeleaf</artifactId> </dependency> <dependency> <groupId>org.mybatis.spring.boot</groupId> <artifactId>mybatis-spring-boot-starter</artifactId> <version>2.2.2</version> </dependency> <dependency> <groupId>mysql</groupId> <artifactId>mysql-connector-java</artifactId> <version>8.0.28</version> </dependency> <dependency> <groupId>org.projectlombok</groupId> <artifactId>lombok</artifactId> <optional>true</optional> </dependency> <dependency> <groupId>io.jsonwebtoken</groupId> <artifactId>jjwt-api</artifactId> <version>0.11.5</version> </dependency> </dependencies>

这里有个细节：mybatis-spring-boot-starter 2.2.2对应的是MyBatis 3.5.x，配合Spring Boot 2.7没有问题。jjwt要同时引入api、impl和jackson三个artifact，否则运行时会报NoClassDefFoundError。

application.yml配置里最需要注意的是时区和SQL日志。数据库连接串JDBC要在后面拼上serverTimezone=Asia/Shanghai，不然MySQL 8的驱动默认按UTC解析时间，订单创建时间会比本地时间差8个小时，这个Bug排查起来非常隐蔽。配置如下：

server: port: 8080 spring: datasource: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://localhost:3306/travel?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai username: root password: 123456 thymeleaf: cache: false mybatis: mapper-locations: classpath:mapper/*.xml type-aliases-package: com.travel.entity logging: level: com.travel.mapper: debug

mybatis.mapper-locations指到classpath:mapper目录，所有DAO接口的SQL映射XML都放在src/main/resources/mapper下。type-aliases-package配置后，Mapper XML的resultType可以直接写User、Order这样的类名，不用写全限定名。logging级别调成debug是为了本地开发时能在控制台看到每条SQL的执行情况，排错时非常有用，部署到生产环境前记得改回info。

3. 核心模块实现：登录、景点管理和订单流转，扛住答辩的三块基石

3.1 JWT登录与权限控制：Token设计和拦截器实现

旅游管理系统至少要区分普通用户和管理员两种角色。用户登录后，后端签发一个JWT，前端每次请求把它放在Authorization请求头里，后端拦截器解析Token并判断角色。用JWT而不是Session是现在Java毕设的主流做法，因为Session在小项目里没问题，但答辩时导师很可能会问“换一台服务器Session怎么共享”，你的思路是按无状态设计走，用Token天然解决横向扩展问题。

JWT工具类建议单独封装，生成和解析的逻辑与业务代码隔离。代码如下：

@Component public class JwtUtils { // 密钥要足够长，这里用HS256要求至少32字节 private final String secret = "travel-management-system-secret-key-2025"; // Token有效期，单位毫秒，这里设置为2小时 private final long expire = 2 * 60 * 60 * 1000; public String generateToken(Long userId, String role) { return Jwts.builder() .setSubject(String.valueOf(userId)) .claim("role", role) .setIssuedAt(new Date()) .setExpiration(new Date(System.currentTimeMillis() + expire)) .signWith(Keys.hmacShaKeyFor(secret.getBytes()), SignatureAlgorithm.HS256) .compact(); } public Claims parseToken(String token) { return Jwts.parserBuilder() .setSigningKey(Keys.hmacShaKeyFor(secret.getBytes())) .build() .parseClaimsJws(token) .getBody(); } }

这里每一个参数都是有讲究的：secret长度最少32字节，否则HS256算法直接抛WeakKeyException；expire设成2小时，太短用户要反复登录，太长又增加Token被截获后的风险；claim里只放角色和userId，不要放密码、手机号等敏感信息。写死密钥在毕设里可以接受，但要记得在答辩时说明“生产环境应把密钥放到配置中心或环境变量”。

有了工具类，再写一个拦截器统一做登录校验。继承HandlerInterceptorAdapter的preHandle方法，放行登录接口和静态资源，其余接口必须校验Authorization头：

@Component public class JwtInterceptor implements HandlerInterceptor { @Autowired private JwtUtils jwtUtils; @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { // 放行OPTIONS预检请求 if ("OPTIONS".equals(request.getMethod())) { return true; } String token = request.getHeader("Authorization"); if (token == null || !token.startsWith("Bearer ")) { response.setStatus(401); return false; } try { Claims claims = jwtUtils.parseToken(token.substring(7)); request.setAttribute("userId", Long.valueOf(claims.getSubject())); request.setAttribute("role", claims.get("role")); return true; } catch (Exception e) { response.setStatus(401); return false; } } }

注意两点：一是token.startsWith("Bearer ")这个判断，对应的前端在axios请求拦截器里要设置Authorization: Bearer ${token}，两边字符串必须完全一致，大小写和空格一个都不能错；二是Token解析失败返回401，前端要统一拦截这个状态码并跳转到登录页，不要每个页面单独处理。需要管理员权限的接口，只需要在Controller里校验request.getAttribute("role")是否等于ADMIN即可。

3.2 景点管理模块：Controller怎么写才规范

景点管理是最典型的增删改查，但答辩时导师看的是你代码是否分层合理。我见过不少同学把所有逻辑全写在Controller里，一个方法七八十行，这会被直接问“如果Service层要为多个Controller复用怎么办”。正确的拆法是Controller只做参数接收和结果返回，Service写具体业务流程，Mapper负责SQL操作。

以分页查询景点为例，Controller层代码：

@Controller @RequestMapping("/scenic") public class ScenicController { @Autowired private ScenicService scenicService; @GetMapping("/list") public String list(@RequestParam(defaultValue = "1") Integer pageNum, @RequestParam(defaultValue = "10") Integer pageSize, Model model) { PageResult<Scenic> result = scenicService.pageQuery(pageNum, pageSize); model.addAttribute("result", result); return "scenic/list"; } }

Service层负责组装分页条件并调用Mapper：

@Service public class ScenicServiceImpl implements ScenicService { @Autowired private ScenicMapper scenicMapper; @Override public PageResult<Scenic> pageQuery(Integer pageNum, Integer pageSize) { // PageHelper做物理分页，第一条执行后会拦截下一条SQL并拼上LIMIT PageHelper.startPage(pageNum, pageSize); List<Scenic> list = scenicMapper.selectAll(); PageInfo<Scenic> pageInfo = new PageInfo<>(list); return new PageResult<>(pageInfo.getList(), pageInfo.getTotal()); } }

这里用到了PageHelper分页插件，它基于MyBatis拦截器实现，核心使用方式就是startPage(pageNum, pageSize)必须紧跟要分页的查询语句，中间不能插入别的查询操作，否则分页SQL会作用到错误的语句上。PageInfo里的getTotal()返回总记录数，getList()返回当前页数据，这两个是前端分页组件要用的关键数据。景点列表页在Thymeleaf模板里通过th:each遍历result.list即可渲染，这部分不做多讲。

3.3 订单状态流转：状态机设计是拿高分的隐藏点

订单模块是整个系统里业务最重的部分，也是答辩时最容易拉开档次的地方。很多毕设把订单状态做成一个随意的字符串字段，直接在Controller里setValue，导师追问“用户支付成功后异步回调来了，怎么防止重复更新”时答不上来。规范的写法是定义订单状态枚举，并把所有状态变更收敛到Service层，禁止Controller直接改状态。

订单状态枚举定义方式：

public enum OrderStatus { 待支付("待支付"), 已支付("已支付"), 已取消("已取消"), 已完成("已完成"); private final String desc; OrderStatus(String desc) { this.desc = desc; } }

Service层添加一个状态变更方法，统一处理合法流转：

public Boolean changeOrderStatus(Long orderId, String targetStatus) { Order order = orderMapper.selectById(orderId); if (order == null) { throw new RuntimeException("订单不存在"); } String current = order.getStatus(); // 禁止非法跳转：已支付不能变回待支付，已取消不能变成已完成 if ("已支付".equals(current) && "待支付".equals(targetStatus)) { throw new RuntimeException("支付状态不可回退"); } if ("已取消".equals(current) && !"已完成".equals(targetStatus)) { throw new RuntimeException("当前状态不可变更"); } order.setStatus(targetStatus); order.setPayNo("TRAVEL" + System.currentTimeMillis()); return orderMapper.updateById(order) > 0; }

为什么要这么做？因为订单状态是一个业务规则密集的字段，分散更新意味着每条变更逻辑都要重新校验上一状态，代码里出现遗漏的概率很大。集中在一个方法里，无论从Controller、定时任务还是支付回调进来，都走同一套校验逻辑，这在答辩时可以说是“借鉴了状态机思想”。还有一个容易被追问的点：用户在支付页面重复点击“确认支付”怎么办。只靠前端禁用按钮不够，Service层要在进入支付逻辑前加一个对当前状态是否为“待支付”的判断，不是待支付直接拒绝本次操作。

4. 部署全流程与典型避坑：能跑起来才算真正做完

4.1 本地部署验证：Maven打包加命令行启动

拿到源码后第一件事不是直接往服务器上传，而是先在本地把项目完整跑一遍。我见过太多人跳过本地验证直接部署服务器，结果日志里全是ClassNotFound，最后只能在服务器上边猜边改，效率极低。本地验证分三步走。

第一步，确认环境干净。在终端执行java -version查看JDK版本，mvn -version看Maven版本。版本不匹配是第一个大坑：项目的pom.xml是Java 8编译级别，你的本机却只有JDK 17且没有配置JAVA_HOME指向旧版本，编译时会有兼容问题。常见做法是用JDK 8安装包配置好环境变量，这里注意Windows的JAVA_HOME要填到JDK根目录而不是bin目录，Path里再加%JAVA_HOME%\bin，配好后新开一个终端窗口验证。

第二步，创建数据库并导入SQL。在MySQL里执行：

CREATE DATABASE travel DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;

然后用source命令导入项目里的schema.sql和data.sql。这里强调utf8mb4而不是utf8，因为在MySQL 8里utf8mb3最多支持3字节字符，一些保存表情或生僻字的数据会报错，utf8mb4才能完整覆盖Unicode。

第三步，打包并启动。在项目根目录执行以下命令：

mvn clean package -DskipTests

这条命令先把target目录清空，然后重新编译、打成一个可执行的jar包。-DskipTests是跳过单元测试，毕设项目里一般没有完整的测试类，但保留这个参数可以避免测试代码报错导致打包失败。

打包成功后，在target目录下执行：

java -jar travel-system-0.0.1-SNAPSHOT.jar

启动后观察控制台日志，看到“Started TravelSystemApplication”即表示启动成功。然后浏览器访问http://localhost:8080，如果页面能正常打开，说明本地部署已经完成，下一步才轮到服务器部署。

4.2 Linux服务器部署：java环境配置与systemd守护进程

服务器部署的核心差别在于两点：环境靠命令行配置，进程守护要用systemd而不是窗口方式。先装JDK 8和MySQL，这里用一个相对不易出错的顺序：先把JDK的tar.gz包解压到/usr/local/java，然后配置环境变量，接着启动MySQL并创建数据库，最后部署jar包。

以CentOS 7/8环境为例，配置java环境变量的操作：

mkdir -p /usr/local/java tar -zxvf jdk-8u202-linux-x64.tar.gz -C /usr/local/java cat >> /etc/profile <<EOF export JAVA_HOME=/usr/local/java/jdk1.8.0_202 export PATH=\$JAVA_HOME/bin:\$PATH EOF source /etc/profile java -version

第三步里反斜杠转义$PATH的作用是让变量在追加到文件时保持“变量引用”状态，而不是当场被展开成当前终端的PATH值，这是一个容易忽略的细节。执行source /etc/profile后，java -version输出1.8开头的版本号就说明环境变量生效。

jar包部署时，不要直接nohup java -jar放后台就不管。我一般会把它注册成systemd服务，这样服务器重启后项目能自动拉起，进程崩溃也能自动重启。服务文件配置如下：

[Unit] Description=Travel System After=network.target mysql.service [Service] Type=simple User=root WorkingDirectory=/opt/travel ExecStart=/usr/local/java/jdk1.8.0_202/bin/java -jar /opt/travel/travel-system.jar Restart=always RestartSec=10 [Install] WantedBy=multi-user.target

WorkingDirectory指定成jar包所在目录很重要，如果你的代码里有相对路径读写文件，比如上传图片保存到./upload，进程的工作目录决定了这个文件夹从哪里创建。Restart=always配合RestartSec=10表示进程异常退出后10秒自动拉起，Mad使用jstack抓线程栈就能看到状态。上传目录和数据权限也要注意，如果你的项目涉及文件上传，一定要在application.yml里配置一个独立的上传路径，并设置777权限。

4.3 五个典型踩坑：现象、原因、解决

坑一：数据库连接报Access denied或Communications link failure。现象是项目启动时连不上MySQL，报错提示用户认证失败或无法连接。原因通常是数据库密码和application.yml配置不一致，或者MySQL服务没启动。解决方法是先在MySQL命令行里用配置的用户名和密码登录验证，再确认MySQL端口3306处于监听状态，最后检查JDBC连接串的IP和端口。

坑二：页面样式丢失、跳转404。现象是启动成功后访问首页有HTML但没有CSS样式，刷新所有路径都返回404。原因多半是Thymeleaf模板找不对静态资源路径，或者把页面放在templates目录外了。解决方法是确认所有HTML页面都在src/main/resources/templates下，静态资源在static下，Controller返回的逻辑视图名要能和模板文件对应上。

坑三：JWT Token解析时报签名不匹配。现象是用户登录成功后，再发第二次请求就报401。原因是生成Token和解析Token使用的密钥不一致，最常见的是把带引号的secret字符串存到了配置中心，读取时多了引号字符，导致字节内容不同。解决方式是写一个单元测试用例，用同一份密钥生成再解析，确认能通过再排查哪里改了密钥。

坑四：上传的图片文件找不到。现象是后台管理上传了景点图片，页面显示400或浏览器访问图片路径404。原因是Linux环境下没有对应的上传目录，或者目录权限不是775。解决方法是在启动前创建好upload目录并chmod 777，同时检查图片URL返回的相对路径能否被静态资源映射到。

坑五：mysql-connector-java版本和MySQL服务版本差距过大。现象是启动时报Unknown character set或协议握手失败。原因是项目依赖的MySQL驱动太旧、服务器MySQL版本太新。解决方法是统一用mysql-connector-java 8.0.28版本，并在连接串中不加useSSL=true这个参数，本地连数据库时SSL会拖慢连接速度，报错也会干扰排查。

5. 从能跑到能答辩：三个必改点和一份自检清单

拿到毕设源码包之后，最忌讳的事情是原封不动运行、原封不动交。很多同学直接照着PPT里的截图和报告的文字交上去，结果导师从自己学院的知网查重系统里一比对，重复率能达到七八成。这套源码、万字报告、部署说明和PPT，本质上是给你画了一个框架和底稿，你要做的是把里面的内容替换成自己的理解。

第一个必改点是数据库表和字段。把t_scenic改成自己定义的scenic_spot也好，加一个用户收藏表也好，要让表结构里有至少一个模块是你自己设计的。第二个必改点是界面文案和Logo，这是成本最低的差异化改造，把系统的标题改成你自己的课题名，前端页面加一条你自己设计的样式。第三个必改点是报告里的系统分析部分，分解清楚哪些是原有的、哪些是你二次开发的。比如你给订单加了一个定时取消的超时任务，这就是一个可以重点讲的加分功能，对应的表、接口、界面全链路都要能自圆其说。

最后是答辩前要做的一份自检清单：

# 1. 本地依赖是否完整，从clone目录到启动不超过30分钟 mvn clean package -DskipTests java -jar target/travel-system.jar # 2. 核心演示路径是否走通 # 用户注册 -> 登录 -> 浏览景点 -> 选择线路下单 -> 模拟支付 -> 订单列表显示已支付 # 3. 管理员入口是否可用 # 管理员登录后进入后台 -> 景点增删改查 -> 订单状态人工修正 -> 查看全部用户 # 4. 数据库数据是否足够演示 # 至少准备10个景点、8条线路、5个不同状态的订单 # 5. 报告关键章节是否和代码对应 # 数据库设计章节里的表名要和SQL文件一致，功能模块章节的截图要重新截

我自己的习惯是答辩前一天不看代码，而是打开PPT把每个功能页面讲一遍，看哪些地方卡壳就重点补哪块。这个办法帮我发现过不少认知盲区，比如讲订单模块时突然想起“重复支付防护”没写，赶紧回去补上。旅游管理系统作为毕设的性价比相当高，关键是把每一层逻辑都吃透，而不是停留在“能跑就行”。希望这份拆解能帮你在做毕设的路上少走几步弯路。

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