SpringBoot+Vue旅游票务系统全栈开发：从架构设计到部署避坑完整指南

刚在群里看到有人问“旅游出行指南类系统怎么选技术栈”，我第一反应就是SpringBoot+Vue这套组合。这年头但凡做毕设、课程设计，或者想给自己简历上添个拿得出手的全栈项目，十有八九绕不开这个搭配。我最近刚好在带一个类似的“旅游出行指南及景点票务管理系统”，从数据库设计到前后端联调一路踩过来，把能拆的细节都拆了一遍。这篇文章就当作一次项目复盘，把我认为真正值钱的经验、那些文档里不会明说的坑，一次性讲清楚。

先说清楚这个系统到底是个啥。它本质上就是一个“旅游攻略+在线票务”的管理平台，面向两类人：普通游客可以在上面看景点介绍、查攻略、订门票、写评价；后台管理员负责维护景点信息、管理订单、处理用户反馈。技术上用SpringBoot提供后端接口，Vue做前端页面，MyBatis操作MySQL数据库，一套典型的互联网Java全栈项目架构。

这篇文章适合两类人看：一是正在做毕业设计或课程设计，想找参考思路的学生；二是springboot刚入门，想通过一个完整案例串起全栈知识点的开发者。你不需要有多深的基础，我会把从环境搭建到前后端联调的完整链路都过一遍。

1. 业务场景与功能架构拆解

想做一个能过审、能答辩、能往简历上写的项目，第一步永远是先把业务想清楚，而不是急着写代码。我见过太多人一上来就建表，结果做了半个月发现表结构撑不起需求，推倒重来。磨刀不误砍柴工，这句话在项目开发里是真真理。

1.1 用户端的核心需求分析

旅游类系统的用户端，说白了三件事：找景点、买门票、写评价。展开来看是这样的。

第一块是“找景点”。游客进来以后要能按城市、按景点类型筛选，能看景点的详细介绍、图片轮播、开放时间、门票价格，最好还能看到其他游客的评分和评论。这块前端要做得好看，后端要给足数据接口，两边都得下功夫。

第二块是“买门票”。正常流程是选择景点、选择游玩日期、填写联系人信息、下单支付。考虑到很多毕设不会真的接支付接口，通常会做成“模拟支付”，也就是下单后默认标记为已支付，或者做一个简单的余额扣减逻辑。这里要注意订单状态的设计：待支付、已支付、已取消、已使用、已退款，每个状态在界面上要有明确的展示和操作入口。

第三块是“写评价”。用户游玩结束后可以对景点打分、写文字评论。这里有个容易被忽略的点：评分数据要能回写到景点表，用做景点列表的“好评率”排序或者综合评分展示，这个联动做出来很加分，答辩时老师特别喜欢问。

除了这三块，还可以加一些锦上添花的功能，比如收藏景点、个人订单列表、个人信息维护。功能不用多，但每个功能要做闭环，做得精致，远比堆十个半成品功能有价值。

1.2 管理端的权限与工作流设计

管理端相对简单，核心是围绕“内容”和“订单”做增删改查，但要体现出清晰的权限层级。

管理员登录后，可以维护景点信息：新增景点、编辑介绍、上传图片、上下架景点。这个环节要注意图片上传的处理方式，本地存储还是OSS，直接影响前端回显的路径逻辑，我后面细说。

订单管理是重中之重。管理员要能查看所有订单，按状态筛选，处理退款申请，标记门票已使用。这些操作都有对应的状态流转，比如用户申请退款后订单变成“退款中”，管理员审核通过后变成“已退款”，同时把支付金额返回给用户账户。这套状态机设计好了，代码写起来会有条理得多。

公告管理也是常见模块，管理员发布节假日通知、景区临时关闭通知，用户端首页轮播或者公告栏展示。这个功能虽然简单，但属于旅游类系统的标配，做上不亏。

1.3 为什么说这种分层结构适合练手

说白了，这个项目的业务足够完整，但又不至于复杂到失控。从架构上看，它具备了一个正经系统该有的所有要素：前端页面交互、后端RESTful接口、数据库表关联、权限控制、文件上传、状态流转。把这些都吃透了，你再去接触更复杂的微服务项目，会发现核心逻辑都是相通的，只是外壳换了。

而且旅游这个主题对前端特别友好。景点图片、风景卡片、路线轨迹，做好了视觉效果很出彩，在答辩或者面试演示的时候能直观打动观众。我见过不少同学做“学生管理系统”，从头到尾就是几个表格，演示起来毫无看点。同样是做毕设，为什么不选一个能让你把前端技能也展示出来的题目呢。

2. 技术选型背后的真实考量

这个项目标题里直接点名的四个关键词是SpringBoot、Vue、MyBatis、MySQL。很多人只把这当做一个“规定动作”去遵守，但如果你能把这套组合为什么能成为主流的原因讲清楚，答辩和面试的时候都是加分项。

2.1 后端为什么是SpringBoot而非SSH或SpringMVC

前几年还经常看到SSH（Spring+Struts+Hibernate）的老项目，现在基本销声匿迹了。SpringBoot的本质是做“约定大于配置”，把原来SpringMVC需要手动配的一大堆XML配置文件全部自动化处理。内嵌Tomcat让应用打个jar包就能直接跑，不需要单独装容器。这些特性对提高开发效率是质的提升。

SpringBoot还有个对新手特别友好的点：起步依赖（Starter）机制。想做Web应用就引入spring-boot-starter-web，想操作数据库就引入mybatis-spring-boot-starter，依赖版本由SpringBoot统一管理，基本告别了“依赖冲突”这种让人抓狂的报错。

不过SpringBoot也不是万能的，很多人误以为学了SpringBoot就等于会了Spring。实际上SpringBoot只是把Spring的复杂配置封装了，底层仍然是Spring IoC和AOP那套东西。面试官问“SpringBoot自动配置原理”的时候，如果你答不出@EnableAutoConfiguration和spring.factories、META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports的关系，基本上就露馅了。所以做项目的同时，一定要把底层原理补上。

2.2 前端框架选Vue还是React

这个项目定的是Vue，原因很现实：Vue的上手曲线比React平缓，模板语法直观，特别适合前后端分离的项目。React的函数式组件和Hooks虽然也很强大，但对初学者来说思维转换成本更高。

Vue本身还有个选择：Vue2还是Vue3。现在已经是2025年，Vue2官方早就不维护了，新项目直接上Vue3。配合Vite构建工具，开发体验比Webpack时代的Vue2快了一个量级。UI组件库选Element Plus，这个库是Vue3生态里最成熟的管理系统组件库，表格、表单、弹窗、分页都有现成组件，能省掉大量造轮子的时间。

如果你是第一次写Vue项目，核心要掌握的知识点就那几个：组件通信（props、emit、provide/inject、Pinia）、生命周期钩子、路由配置与守卫、Axios封装与拦截器。这些覆盖了一个前端项目90%的日常开发需求。

2.3 ORM框架的取舍：MyBatis与MyBatis-Plus

MyBatis在这个项目里的定位是数据访问层框架，负责Java对象和数据库记录之间的映射。它相比Hibernate的优势在于SQL完全可控，性能调优的主动权在自己手里。复杂多表查询、动态SQL拼接，这些都是MyBatis的长项。

不过现在很多新项目直接用MyBatis-Plus，因为它把单表CRUD的通用方法都内置了，不用手写那些简单的insert、selectById，还能配一套分页插件。但标题里写的是MyBatis，所以我还是建议你从原生MyBatis入手，把Mapper接口、XML映射文件、resultMap、动态SQL这些基本功打牢。以后切换到MyBatis-Plus，你会发现几乎零成本，因为MP本身就是基于MyBatis做的增强。

2.4 数据库为什么选MySQL和InnoDB

MySQL目前是中小型项目的绝对主流，开源免费、生态成熟、资料丰富，用的人多意味着你遇到问题的时候，搜索引擎能给你找出几十种解决方案。存储引擎用InnoDB，这是MySQL 8.0的默认引擎，支持事务和外键，支持行级锁，数据安全性比老旧的MyISAM好太多。

MySQL 8.0和5.7相比有个值得注意的变化：默认字符集从utf8mb3变成了utf8mb4，这意味着emoji表情和生僻字都能正常存储。还有一个重要改动是身份认证插件默认是caching_sha2_password，有些老版本的客户端工具连接会报错，需要改成mysql_native_password。第一次装MySQL 8.0的同学很可能会踩到这个坑。

3. 数据库设计与核心表结构

数据库设计是这个项目的地基。我曾经看过一个旅游项目，订单表里直接存了一个用逗号拼接的“景点ID列表”，查询的时候在Java代码里做字符串拆分，这种设计答辩时候必被老师怼。这一章我直接给出核心表结构以及设计思路。

3.1 七张核心数据表的设计思路

整个项目我规划了七张表：用户表、景点表、景点分类表、订单表、订单明细表、评论表和公告表。它们之间的关系说复杂也不复杂，但每张表都有自己存在的理由。

用户表的核心字段是用户名、密码、昵称、头像、手机号、角色标识。密码不存明文，必须用BCrypt加密，这是一个底线要求。角色标识区分管理员和普通用户，我在这个项目里直接用int类型，0表示普通用户，1表示管理员。用Spring Security或者拦截器拦截请求，根据角色决定能否访问管理接口。

景点表要撑起前台展示，字段包括景点名称、所在城市、详细地址、分类ID、封面图片、详细介绍、开放时间、门票价格、库存数量、综合评分、浏览量。其中综合评分不是手动填的，而是根据评论表聚合计算出来的，我在后续接口设计里会详说。

订单表是业务核心，包含订单号、用户ID、订单总金额、订单状态、联系人姓名、联系电话、游玩日期、下单时间、支付时间。订单号别用数据库自增ID，要自己生成，格式可以设计成日期+随机数，方便业务排查问题，看起来也更专业。

订单明细表解决的是一个订单包含多个景点门票的问题，每个明细记录关联订单ID和景点ID，以及购买的数量和单价。这样设计的好处是订单主表只管总览信息，细分明细灵活扩展，统计报表也方便。

评论表包含评论ID、用户ID、景点ID、评分、评论内容、回复内容、评论时间。这里评分建议用0到5的整数或者保留一位小数，避免算平均值时出现过长的浮点数。

公告表就简单了，标题、内容、发布时间、状态。首页公告栏拉取状态为正常的公告，按发布时间倒序展示。

3.2 外键真的有必要加吗

这是一个很多教程不会讲清楚的问题。教科书上说外键能保证数据一致性，但实际开发中，很多大厂开发规范明确规定“禁止使用物理外键，必须在应用层维护数据一致性”。

原因很现实：加了物理外键之后，每次插入子表记录时数据库都要去父表做校验，高并发场景下这个开销是致命的；而且级联删除的限制让删改操作变得极其麻烦，容易误伤数据。所以我在这个项目里同样采用逻辑外键的方式，表结构上没有真的去声明FOREIGN KEY，但所有关联字段在业务逻辑上严格保证一致性。

举个例子，删除景点信息前，先查询订单明细表和评论表里是否还有关联记录，如果有，在前端提示“该景点存在未完成订单，无法删除”。查重和拦截都在Service层做掉，效果等同于外键约束，但灵活性高得多。

3.3 字段类型选择的细节陷阱

数据库设计的时候，类型选不好后面全是坑。我给你列几个最容易出问题的点。

金额字段用DECIMAL(10,2)，绝不用float或double，否则银行业的经典教训会再演一遍：0.1+0.2得到的不是0.3，而是一长串没完没了的小数。DECIMAL是定点数，底层是字符串处理，精度有保证。

库存字段用INT，门票每日可售数量是整数，未来做库存扣减时用UPDATE语句的原子操作，一道SQL就能解决并发超卖问题。具体写法我会在接口实现部分给出。

时间字段用datetime，同时建议MySQL 8.0把explicit_defaults_for_timestamp参数保留默认值。Java端用LocalDateTime接收，配合MyBatis的jdbcType=TIMESTAMP映射，时区问题基本不需要操心。

状态字段建议用int或tinyint，比如订单状态0、1、2、3、4分别代表不同状态。千万别直接存“已支付”这种中文文本，不仅浪费空间，查询效率低，前端显示还会绑手绑脚。

3.4 索引设计的实战经验

这个项目的数据量虽然没有大到需要深度调优的程度，但提前把索引设计好是职业习惯，面试官问到也能侃侃而谈。

景点表的城市字段要加普通索引，因为按城市检索是旅游系统最高频的查询场景。评论表的景点ID字段必须加索引，否则首页展示景点评分时，每查一个景点都要全表扫一次评论表，数据量一大就卡成幻灯片。订单表的用户ID和订单状态需要联合索引idx_user_status(user_id, status)，这样才能高效支撑“查询某个用户的所有订单并按照状态筛选”的场景。

这里提示一个常见误区：索引不是越多越好。每个索引在插入、更新时都要同步维护，索引多了会导致写入性能下降。索引是拿空间换时间的方案，够用就好。

4. 后端核心功能的具体实现

这章是实操重点。我会按SpringBoot项目从初始化到核心接口实现的顺序来拆解，所有代码都来自我实际调试过的版本，直接抄是可以跑的。

4.1 项目初始化和基础架构搭建

创建SpringBoot项目的方式很多，我推荐用Spring Initializr（start.spring.io）在线生成，选择Java 17版本、打包方式jar包，依赖里勾选Spring Web、MyBatis Framework、MySQL Driver、Lombok、Validation。

项目生成后，第一步是配application.yml。我这里直接给一份关键配置示例：

yaml复制server:
  port: 8080

spring:
  datasource:
    url: jdbc:mysql://localhost:3306/travel_db?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai&useSSL=false
    username: root
    password: 123456
    driver-class-name: com.mysql.cj.jdbc.Driver

mybatis:
  mapper-locations: classpath:mapper/*.xml
  type-aliases-package: com.example.travel.entity
  configuration:
    map-underscore-to-camel-case: true
    log-impl: org.apache.ibatis.logging.stdout.StdOutImpl

几个关键的配置我解释一下。map-underscore-to-camel-case改成true之后，数据库里的user_name字段可以自动映射到Java类的userName属性上，省掉一大堆resultMap手写映射，但复杂的多表联查我不建议偷懒，最好还是显式声明resultMap。log-impl配置成StdOutImpl后，控制台会打印出MyBatis实际执行的SQL语句和参数，这是调试利器，排查问题全靠它。

实体类设计走Lombok路线，用@Data注解替代手写Getter和Setter。一个简单的景点实体类长这样：

java复制@Data
@TableName("t_scenic")
public class Scenic {
    private Integer id;
    private String name;
    private String city;
    private String address;
    private Integer categoryId;
    private String coverImg;
    private String description;
    private String openTime;
    private BigDecimal price;
    private Integer stock;
    private Double score;
    private Integer views;
    private Integer status;
    private LocalDateTime createTime;
}

Mapper层是接口加XML映射文件的方式。有一个特别容易踩的坑：Mapper接口上要加@Mapper注解，或者在启动类上加@MapperScan扫描Mapper包。我见过很多新手忘了这一步，启动的时候报Field mapper in ... required a bean of type ...这个错，忙活半天才反应过来是扫描没配。

4.2 登录鉴权：JWT方案快速落地

旅游系统的接口分为两类：需要登录的（用户下单、订单查询、评论）和公开的（景点列表、景点详情、公告）。我用了JWT（JSON Web Token）做无状态鉴权，实现起来不复杂，效果却很不错。

用户登录成功后，服务端生成一个token返回给前端。token里可以携带用户ID和角色信息。前端把token存在localStorage里，然后封装到Axios请求头中。后端用拦截器拦截所有API请求，白名单内的路径（比如登录接口、注册接口、景点列表）放行，其他请求必须校验token合法性。

核心的拦截器代码如下：

java复制public class JwtInterceptor implements HandlerInterceptor {
    @Override
    public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {
        // 放行预检请求
        if ("OPTIONS".equalsIgnoreCase(request.getMethod())) {
            return true;
        }
        String token = request.getHeader("Authorization");
        if (StringUtils.hasText(token) && token.startsWith("Bearer ")) {
            token = token.substring(7);
        }
        try {
            Claims claims = JwtUtil.parseToken(token);
            request.setAttribute("userId", claims.get("userId"));
            request.setAttribute("role", claims.get("role"));
            return true;
        } catch (Exception e) {
            response.setStatus(401);
            response.getWriter().write("{\"code\":401,\"msg\":\"未登录或登录已过期\"}");
            return false;
        }
    }
}

注册登录这块，密码加密使用BCryptPasswordEncoder的encode方法，验证时调用matches方法。有人说这不是Spring Security自带的吗，直接引入security是不是更好。引入Spring Security当然是标准方案，但它的过滤器链以及各种配置对新手来说学习成本偏高。做毕设阶段用拦截器实现JWT鉴权，代码量少，效果直观，面试的时候也能把逻辑讲得清清楚楚，这就够了。

4.3 旅游景点列表查询与多条件筛选

景点列表是旅游系统最核心的接口，前端展示要支持按城市、按分类、按价格区间、按评分排序筛选，而且要做分页。对应的SQL就需要使用MyBatis的动态SQL能力，在XML映射文件里用<where>和<if>标签拼接查询条件。

xml复制<select id="selectByCondition" resultMap="ScenicResultMap">
    SELECT * FROM t_scenic
    <where>
        <if test="city != null and city != ''">
            AND city = #{city}
        </if>
        <if test="categoryId != null">
            AND category_id = #{categoryId}
        </if>
        <if test="minPrice != null">
            AND price &gt;= #{minPrice}
        </if>
        <if test="maxPrice != null">
            AND price &lt;= #{maxPrice}
        </if>
    </where>
    <choose>
        <when test="sortRule == 'score'">
            ORDER BY score DESC
        </when>
        <when test="sortRule == 'price_asc'">
            ORDER BY price ASC
        </when>
        <otherwise>
            ORDER BY views DESC
        </otherwise>
    </choose>
</select>

这里有两个必须注意的点。第一，<if>标签里判断条件要养成习惯，字符串用!= null and != ''双判断，避免空字符串把SQL带坏。第二，<和>是XML文件里小于号和大于号的转义写法，直接写<会导致XML解析报错，新手踩这个坑的频率极高。

分页这块，需要自己写LIMIT参数或者直接引入PageHelper插件。如果用的是PageHelper，用法非常无脑：查询前一行代码PageHelper.startPage(pageNum, pageSize)，紧接着执行的查询自动分页，再用PageInfo包装结果返回。这是我推荐的做法，少写不少代码。

4.4 下单与库存扣减的并发安全

订单模块是整个系统的难点，因为涉及到库存扣减，必须考虑并发场景下会不会超卖。假设剩下最后一张票，两个用户同时下单，如果代码逻辑是先查库存再UPDATE扣减，两个请求可能都查到库存还剩1，同时去扣减，最终就卖出了两张票。

解决超卖的标准做法是使用数据库层面的原子更新。在Service层，先插入订单记录，再执行库存扣减SQL：

sql复制UPDATE t_scenic SET stock = stock - 1 WHERE id = #{scenicId} AND stock > 0

这条SQL的关键在于AND stock > 0条件。MySQL执行UPDATE时会加上行级锁，同一时间只有一个请求能更新成功，另一个请求会因为受影响行数为0判断为库存不足，直接抛出“余票不足”的异常。同时，我们把“查库存”和“扣库存”合并成一步操作，彻底杜绝了并发超卖。

再加上订单超时未支付自动关闭的逻辑会更完整。方案可以用定时任务定时扫描“待支付”超过15分钟的订单设置为“已取消”，并回补库存。这个功能做好了，项目完整度直接上一个档次。

4.5 评分聚合与联表查询

用户对景点评论后，要重新计算景点的综合评分。这里我没有用数据库触发器，而是选择在Service层手动编程实现。每次新增评论时，查评论表算出该景点的平均分，然后UPDATE到景点表。

java复制@Override
@Transactional(rollbackFor = Exception.class)
public void addComment(Comment comment) {
    commentMapper.insert(comment);
    // 重新计算评分
    Double avgScore = commentMapper.selectAvgScoreByScenicId(comment.getScenicId());
    scenicMapper.updateScore(comment.getScenicId(), avgScore);
}

@Transactional注解保证了这个方法里的两步操作要么同时成功，要么同时回滚，不会出现评论插入成功但评分没更新的脏状态。这里注意事务注解的rollbackFor = Exception.class，默认情况下Spring事务只在遇到RuntimeException时回滚，如果忘了指定rollbackFor，遇到受检查异常事务不会生效。

首页的“热门景点推荐”做一次联表查询，一次查出评分最高的前8个景点，同时把每个景点的第一张图片和价格带出来。这类查询建议提前在本地用EXPLAIN命令分析执行计划，确认索引是否走对，避免上线后性能崩盘。

5. 前端Vue3项目的搭建与页面实现

后端接口写得再漂亮，前端拉胯照样白搭。这一章聊前端的工程化搭建思路，以及几个最容易卡脖子的问题。

5.1 快速搭建Vue3 + Vite + Element Plus工程

强烈建议直接用Vite构建工具创建项目，不要再用Vue CLI了。Vite冷启动速度是在是Webpack时代的十倍以上，热更新也是毫秒级别。创建命令如下：

bash复制npm create vite@latest travel-frontend -- --template vue

然后安装Vue Router、Pinia、Axios和Element Plus：

bash复制cd travel-frontend
npm install
npm install vue-router@4 pinia axios element-plus

Element Plus引入方式有两种：完整引入和按需自动导入。毕设项目建议完整引入，代码简单不折腾：

javascript复制import ElementPlus from 'element-plus'
import 'element-plus/dist/index.css'
app.use(ElementPlus)

5.2 Axios封装与请求拦截器

Axios必须封装成统一的请求工具类，否则每个页面都要写一遍axios.get、设置token、处理异常，代码会极其冗余。我在项目里会建一个utils/request.js，统一处理三件事：带上token、统一提示错误信息、处理HTTP 401跳转登录页。

javascript复制import axios from 'axios'
import { ElMessage } from 'element-plus'
import router from '../router'

const request = axios.create({
  baseURL: '/api',
  timeout: 10000
})

// 请求拦截器
request.interceptors.request.use(config => {
  const token = localStorage.getItem('token')
  if (token) {
    config.headers.Authorization = 'Bearer ' + token
  }
  return config
})

// 响应拦截器
request.interceptors.response.use(
  response => {
    const res = response.data
    if (res.code === 401) {
      ElMessage.error('登录已过期，请重新登录')
      localStorage.removeItem('token')
      router.push('/login')
      return Promise.reject(new Error('未登录'))
    }
    if (res.code !== 200) {
      ElMessage.error(res.msg || '请求失败')
      return Promise.reject(new Error(res.msg))
    }
    return res
  },
  error => {
    ElMessage.error('网络异常，请稍后重试')
    return Promise.reject(error)
  }
)

export default request

这样的统一封装带来的价值是：所有业务代码里只需要关心数据返回，错误提示由拦截器统一处理，代码里不再散落着一堆try-catch和alert弹窗。

5.3 路由守卫与权限控制

前端路由需要做一道登录拦截，这是配合后端JWT的“第二道防线”。定义好需要登录才能访问的路由后，在全局前置守卫里做判断。

javascript复制router.beforeEach((to, from, next) => {
  const token = localStorage.getItem('token')
  if (to.meta.requiresAuth && !token) {
    next('/login')
  } else {
    next()
  }
})

管理员页面的路由还需要进一步检查用户角色。最简单的方式是在登录成功后把用户信息（包含角色）存到Pinia里，路由守卫时校验to.meta.role是否匹配当前用户的角色，不匹配就跳转到一个“无权限访问”的页面。

5.4 图片上传与回显的完整闭环

景点封面和攻略内容里的图片，是旅游系统展示效果的灵魂。没有图片的旅游网站，就像没放菜的盘子里，看都不想看。

图片上传接口用SpringBoot实现：接收前端上传的MultipartFile文件，校验文件类型和大小，然后保存到服务器本地指定目录，比如/upload/img/，文件名用UUID重命名，防止中文乱码和重名覆盖。保存成功后返回文件的访问URL。

java复制@PostMapping("/api/upload")
public Result<String> upload(@RequestParam("file") MultipartFile file) {
    if (file.isEmpty()) {
        return Result.error("上传文件不能为空");
    }
    String originalFilename = file.getOriginalFilename();
    String ext = originalFilename.substring(originalFilename.lastIndexOf("."));
    String fileName = UUID.randomUUID().toString().replace("-", "") + ext;
    // 这里做类型和大小校验
    // 保存到 uploadPath 目录
    file.transferTo(new File(uploadPath + fileName));
    return Result.success("/images/" + fileName);
}

前端表单提交时，图片上传走独立的接口，返回的URL作为表单字段一起提交给业务接口。这里有两个坑必须提醒。

第一个坑是后端保存的文件目录不能被外部直接访问。需要在SpringBoot配置里添加静态资源映射，把/images/**映射到本地的upload目录。或者接一下Nginx，配置根目录指向upload文件夹，方式更优。

java复制@Configuration
public class WebConfig implements WebMvcConfigurer {
    @Override
    public void addResourceHandlers(ResourceHandlerRegistry registry) {
        registry.addResourceHandler("/images/**")
                .addResourceHandler("file:" + uploadPath);
    }
}

第二个坑是前端开发时出现了“明明上传成功了，但img标签src访问图片显示404”的状况。这种问题十有八九是请求代理没配好。Vite的vite.config.js里配置proxy，让开发环境的/api和/images请求都代理到后端服务器地址：

javascript复制server: {
  proxy: {
    '/api': 'http://localhost:8080',
    '/images': 'http://localhost:8080'
  }
}

5.5 Vue3的组件通信实践

项目里的组件通信，我用了三类方案：父子组件用props和emit，跨组件共享数据用Pinia，兄弟组件通过事件总线。下单流程的步骤条、景点筛选栏和列表页，我把景区筛选条件放到了Pinia里，避免组件一层一层传递props造成的繁琐逻辑。

javascript复制// store/scenic.js
import { defineStore } from 'pinia'

export const useScenicStore = defineStore('scenic', {
  state: () => ({
    city: '',
    categoryId: null,
    sortRule: 'views'
  }),
  actions: {
    setCity(city) {
      this.city = city
    }
  }
})

这种全局状态管理在景点列表页和筛选组件之间就是天然的解耦方案。筛选组件更新store中的状态，列表组件监听store变化自动重新请求接口，代码逻辑一目了然。

6. 联调过程中的常见问题与排查技巧

咱们做项目，最耗时的永远不是写代码，而是排查那些不知道从哪冒出来的报错。这一章我把自己调试中真正遇到过的问题，以及排查思路整理出来，算是给后来人排雷。

6.1 数据库连接与驱动类问题

MySQL 8.0与5.7坐标不同，驱动类从com.mysql.jdbc.Driver改成了com.mysql.cj.jdbc.Driver。连接URL里的serverTimezone=Asia/Shanghai必须加上，否则报时区错误。如果你用的连接池是HikariCP（SpringBoot 2.x以后默认就是它），连接URL里还必须加useSSL=false，否则控制台会一直打SSL警告，虽然不影响跑，但很烦人。

有一个我印象特别深的排查经历：项目启动时报Failed to configure a DataSource，界面上直接挂了红。这个报错的意思是SpringBoot找不到数据源配置。原因是我在application.yml里把配置文件写成了application.yaml，但是SpringBoot扫描的优先级不对，导致读取不到数据库配置。

6.2 MyBatis相关的经典报错

MyBatis的报错看多了就有经验了，整理成速查表：

关于MyBatis缓存，默认一级缓存是SqlSession级别，同一个SqlSession内重复查询会走缓存。但在SpringBoot集成环境里，每次Mapper调用都会重新获得SqlSession，一级缓存的实际作用有限。二级缓存默认是关闭的，个人项目建议保持关闭，因为缓存刷新时机需要精确控制，处理不好反而会出现脏数据。

6.3 跨域问题与前端联调的坑

前后端分离项目，前端跑在http://localhost:5173，后端跑在http://localhost:8080，二者的端口不同，必定触发跨域。解决方式我推荐在后端加一个全局CORS配置，一劳永逸：

java复制@Configuration
public class CorsConfig {
    @Bean
    public CorsFilter corsFilter() {
        CorsConfiguration config = new CorsConfiguration();
        config.addAllowedOriginPattern("*");
        config.addAllowedHeader("*");
        config.addAllowedMethod("*");
        config.setAllowCredentials(true);
        UrlBasedCorsConfigurationSource source = new UrlBasedCorsConfigurationSource();
        source.registerCorsConfiguration("/**", config);
        return new CorsFilter(source);
    }
}

一个容易忽略的现象是：如果你自己加了JWT拦截器，拦截器里放行了OPTIONS预检请求后，CORS配置才能正常工作。这里有个处理顺序问题：CORS过滤器先于拦截器执行。若返回头设置不当，前端会报“CORS error”。我的习惯是前端开发用Vite代理，生产部署用Nginx代理，两者都不需要后端配置CORS，减少一个变量。

6.4 前端构建失败的典型场景

刚开始接触Vite构建的人在打包时容易碰到内存溢出：

code复制<--- JS heap out of memory

这是Node进程的默认堆内存不够用了。解决办法是在package.json的build脚本里增加NODE_OPTIONS=--max_old_space_size=4096，把Node堆内存上限提升到4GB：

json复制"scripts": {
  "build": "NODE_OPTIONS=--max_old_space_size=4096 vite build"
}

构建完之后还有个很常见的部署问题：前端打包产物dist目录直接扔到服务器上跑，刷新页面时发现404。这是因为Vue Router默认是history模式，它依赖服务器的“所有路由都指向index.html”这个重写规则。如果用的是Nginx，需要在server块里配置：

nginx复制location / {
  try_files $uri $uri/ /index.html;
}

这个配置不加，刷新非首页就白屏。很多不懂前端的后端同学在这里卡了好几天。

6.5 前后端联调时的时间与类型问题

后端接口返回的日期时间格式，默认可能是这样的：2025-01-15T10:30:00，中间的T看起来非常不协调。想在JSON序列化时改成2025-01-15 10:30:00，需要在application.yml里配置：

yaml复制spring:
  jackson:
    date-format: yyyy-MM-dd HH:mm:ss
    time-zone: Asia/Shanghai

金额字段前后端联调时也要注意，数据库的DECIMAL到Java里是BigDecimal，转成JSON后是数字。前端拿到后做人民币格式化显示，用toFixed(2)即可。千万别在前端用浮点数相加，哪怕只算一个0.1+0.2也会给你表演经典IEEE754灾难。

6.6 演示环境准备和答辩注意事项

如果这个项目是要去答辩或者演示的，我强烈建议你提前准备一套演示数据，不要登录进去空空如也一片白。景点至少录入12个，覆盖5个不同城市和4种不同分类，每个景点配3张以上的图片。订单至少造10条不同的状态，演示时可以随时切换给评委看效果。

这套项目做到最后，你手头实际上积累了完整的“需求文档+数据库设计+后端接口+前端页面+部署上线”完整链路。把这些沉淀下来，无论答辩还是面试，都能拿出实打实的东西。

我在实际撸代码的过程中还有个小习惯：每完成一个模块，就在本地git仓库提交一次，写上清晰的commit信息。后面改出问题也好回滚。这看起来没必要，但项目大了之后真能救命。刚开始做的人，往往栽倒不是不会写，而是代码改乱了回不去。