做Java Web这么多年，最深的体会就是：技术栈本身不值钱，把技术栈组合起来解决一个具体业务问题才值钱。这套喀什旅游网站系统就是典型例子——Java SpringBoot + Vue3 + MyBatis + MySQL 四个关键词单独拆开，每个都是面试八股里的常客，合在一起做成一个前后端分离的web系统，就覆盖了景点展示、线路查询、酒店信息、留言互动、后台管理等一套真实业务场景。你要是在学后端、准备课程设计或者想练手一个能写在简历上的完整项目，这篇拆解思路和实操记录应该能帮你少走不少弯路。
先说清楚这套系统能干什么：游客端可以浏览喀什的景点、旅游线路、酒店信息，查看详情、发表留言、注册登录、提交线路咨询或预订；管理端可以维护景点、线路、酒店等所有数据，处理留言和订单。技术分工非常明确，SpringBoot负责提供REST接口，Vue3负责页面渲染和用户交互，MyBatis负责数据库操作，MySQL存数据。下文我会把项目从需求拆解、数据库设计、后端实现、前端联调到上线部署的完整链路都过一遍，重点讲为什么要这么做，以及真正动手时容易踩哪些坑。
1. 项目定位与技术选型：这套组合的逻辑
1.1 一个旅游网站系统到底要解决什么问题
很多新手拿到"旅游网站"这个需求，第一反应就是开始建表写接口，结果做着做着发现功能越堆越多、代码越来越乱。我拿到这个项目时先做的一件事，是把这个系统的核心问题圈定下来：它本质上是一个内容展示+信息检索+轻量交互的站点。
内容展示，指的是景点、线路、酒店这些信息要有分类、有详情、有图片；信息检索，指的是用户能不能按地区、按名称、按价格区间找到想要的内容；轻量交互，指的是注册、登录、留言、下单这类操作。这三层需求决定了系统的复杂度不需要上微服务、不需要分布式缓存，用一个单体后端加上一个前端SPA应用就能很好覆盖。
明确了业务边界之后，技术选型就顺理成章了。业务简单不代表可以乱选型，恰恰因为业务简单，选型更应该考虑生态成熟度和团队上手成本。SpringBoot + Vue3 + MyBatis + MySQL这套组合，几乎是国内Java后端项目最常见的主流搭配，遇到问题网上资料最多，招人也好找，这本身就是一种隐形的技术红利。
1.2 前后端分离和传统模板渲染的取舍
早期做Java网站，很多人用的是SpringBoot + Thymeleaf或者JSP，服务端直接渲染页面。那种模式不是不能用，而是开发和联调体验比较痛苦：前端改个样式要碰后端代码，后端改个接口参数又影响页面渲染，两边的工作完全耦合在一起。
这套系统采用前后端分离，本质上是把页面渲染和数据处理彻底分开。前端用Vue3开发，通过axios发起HTTP请求拿JSON数据；后端只负责处理请求、执行逻辑、返回数据，完全不关心数据最终在页面上长什么样。这样带来的直接好处有两个：
第一，前后端可以并行开发。后端把接口文档定好，前端Mock数据就能开始写页面，不用等后端代码跑起来。我实操的时候，前端页面和后端接口几乎是同时动工的，整体开发周期至少缩短了三分之一。
第二，部署和演进更灵活。前端打包出来是一堆静态文件，扔到Nginx里就能跑；后端是独立的Java服务。后面就算要换一套前端框架重做界面，后端接口一行都不用改。
当然，前后端分离也引入了新的问题，比如跨域、联调效率、接口约定不一致等。这些坑我会在第5章专门讲排查经验，这里先记住一个原则：接口文档要前置，联调效率才能有保障。
1.3 SpringBoot、Vue3、MyBatis、MySQL各自承担什么
一句话总结这套技术栈的分工：MySQL负责把数据落盘，MyBatis负责在Java和MySQL之间架桥，SpringBoot负责把桥上的业务逻辑串起来并以接口形式暴露，Vue3负责把这些接口返回的数据变成用户能看懂、能操作的页面。
SpringBoot的优势在于约定优于配置。以前写SSH或者SSM，各种XML配置能把人绕晕，SpringBoot把绝大多数配置都自动化了，内嵌Tomcat，一个java -jar就能启动，对中小项目来说非常友好。
MyBatis在这套系统里承担的是SQL控制权和开发效率之间的平衡。相比MyBatis-Plus那种自动生成SQL的框架，原生MyBatis需要手写SQL，这看起来麻烦，但换来的是对SQL的完全掌控。旅游网站涉及很多多表关联查询，手写SQL反而更容易调优和排查问题，而且面试的时候MyBatis部分能讲的点也更多。
Vue3相比Vue2最大的变化是组合式API，逻辑复用比Options API舒服得多。配合Element Plus组件库做后台管理页面，表格、表单、弹窗这些现成的组件能省下大量时间。MySQL则不用多说，社区版免费、稳定、资料多，这个量级的项目用MySQL绰绰有余。
2. 数据库设计：数据是一切功能的地基
2.1 核心表结构与业务建模
数据库设计是整个项目里最不应该省时间的环节。我见过太多项目，上来就建表，建着建着发现字段不够、关系理不清，最后只能一边写代码一边改表结构，项目就这么烂尾了。这套系统的核心业务可以拆成四个部分：内容信息、用户体系、互动记录、订单交易。
内容信息相关的表包括：
scenic_spot景点表：id、name、area_id、summary、content、cover_image、images、ticket_price、open_time、click_count、status、create_time。travel_route线路表：id、title、days、summary、price、cover_image、status、create_time。route_scenic线路景点关联表：id、route_id、scenic_id、day_order。hotel酒店表：id、name、level、price、address、cover_image、status。food美食表：id、name、category、address、cover_image、recommend。
用户体系和互动记录相关的表包括：
user用户表：id、username、password、nickname、avatar、phone、create_time。comment留言/评论表：id、user_id、target_type、target_id、content、create_time。
订单交易相关的表：
orders订单表：id、order_no、user_id、route_id、contact_name、contact_phone、travel_date、people_count、total_price、status、create_time。
这套设计里有两个点需要解释一下。
第一个是为什么订单表和线路表关联，而不和具体的景点关联。因为旅游网站的预订行为通常以线路为单位——比如"喀什老城+帕米尔高原三日游"，一次预订涉及多个景点，如果订单去关联景点，表结构会非常复杂。以线路为单位，订单逻辑简单清晰，也更贴近真实业务。
第二个是为什么用逻辑关联而不是数据库外键。早期我写项目喜欢加外键约束，后来在真实项目里吃过亏：外键约束在数据量大、并发高的时候会影响写入性能，而且业务逻辑改了之后，外键结构会变成沉重的包袱。现在的做法是在SQL查询里用JOIN来维护关系，数据完整性由Service层代码保证，这也是主流互联网项目的做法。
2.2 表关系映射与MyBatis结果集设计
表结构定好之后，要思考MyBatis怎么把这些关系映射到Java对象里。这个过程最容易出错，也最能体现MyBatis的设计功力。
比如景点和地区是多对一关系，一个地区有多个景点。在Java里，景点实体类会有一个Area area属性；在MyBatis的XML里，就要用association来映射：
<resultMap id="ScenicVOMap" type="com.kashgar.vo.ScenicVO"> <id property="id" column="scenic_id" /> <result property="name" column="scenic_name" /> <result property="summary" column="summary" /> <result property="coverImage" column="cover_image" /> <result property="ticketPrice" column="ticket_price" /> <association property="area" javaType="com.kashgar.entity.Area"> <id property="id" column="area_id" /> <result property="name" column="area_name" /> </association> </resultMap>查询语句就通过JOIN把地区名称带出来：
SELECT s.id AS scenic_id, s.name AS scenic_name, s.summary, s.cover_image, s.ticket_price, a.id AS area_id, a.name AS area_name FROM scenic_spot s LEFT JOIN area a ON s.area_id = a.id WHERE s.status = 1这里有个容易被忽略的细节：如果查询结果里的列名和Java属性名对不上，一定要起别名。比如两条记录都有id字段，MyBatis分不清哪个是景点的id哪个是地区的id，必须通过AS scenic_id和AS area_id让列名唯一，再在resultMap里用column属性精确绑定。
线路和景点是多对多关系，一条线路包含多个景点，一个景点可能出现在多条线路上。这种关系在Java里体现为List<ScenicSpot> scenicList，在MyBatis里用collection映射：
<collection property="scenicList" ofType="com.kashgar.entity.ScenicSpot"> <id property="id" column="scenic_id" /> <result property="name" column="scenic_name" /> </collection>查询线路详情时，先查线路主信息，再用LEFT JOIN把关联景点查出来，MyBatis会自动根据主键做一对多的结果集合并。
2.3 喀什旅游数据的初始化思路
数据库结构搭好只是第一步，系统跑起来还需要真实的数据。很多人的项目做完demo感很强，就是因为里面存的全是"测试数据1""测试数据2"，看起来就不专业。
这套系统的业务场景是喀什旅游，数据初始化就有很多可以发挥的地方。比如景点表可以准备这些数据：喀什古城、艾提尕尔清真寺、香妃园、帕米尔高原、慕士塔格峰、喀拉库勒湖、白沙湖、盘龙古道等。每个景点配上简介、门票价格、开放时间，图片可以先放网络URL占位，后续再替换成MinIO存储的上传图片。
线路表可以围绕景点组合设计，比如"喀什老城文化一日游""帕米尔高原两日游"这种真实线路。酒店表可以准备喀什当地的特色酒店，美食表可以录入烤包子、缸子肉、手抓饭这些当地特色。
初始化数据的SQL建议单独整理成一个data.sql文件，和建表语句分开放。每次重置数据库时，直接执行建表脚本再导入数据脚本，开发环境就能恢复到一致的初始状态。这一步做得规范，后面测试接口和调前端的时候会省很多事情。
3. 后端代码实现：SpringBoot与MyBatis的实战落地
3.1 工程搭建与核心配置
后端工程可以直接用Spring Initializr生成，也可以自己搭Maven骨架。依赖上需要引入这几个核心组件：spring-boot-starter-web、mybatis-spring-boot-starter、mysql-connector-j、lombok，如果做分页查询再加一个pagehelper-spring-boot-starter。如果是自己手动建Maven工程，注意SpringBoot 2.x和3.x对Java版本要求不同，3.x必须用Java 17及以上，很多朋友一上来版本没对齐，编译就各种报错。
application.yml里的配置有几个关键点要仔细处理：
spring: datasource: url: jdbc:mysql://localhost:3306/kashgar_travel?useSSL=false&serverTimezone=Asia/Shanghai&characterEncoding=utf8mb4 username: root password: 123456 driver-class-name: com.mysql.cj.jdbc.Driver mybatis: mapper-locations: classpath:mapper/*.xml type-aliases-package: com.kashgar.entity configuration: map-underscore-to-camel-case: true log-impl: org.apache.ibatis.logging.stdout.StdOutImpl server: port: 8080useSSL=false是为了避免连接MySQL时的SSL证书警告，本地开发完全不需要SSL加密；serverTimezone=Asia/Shanghai是因为MySQL 8.0以上的驱动默认时区是UTC，不改的话日期时间会差8个小时；characterEncoding=utf8mb4是为了支持存储emoji和生僻字。
map-underscore-to-camel-case这个配置一定要开。数据库里的cover_image映射到Java的coverImage，全靠这个开关自动转换，否则每写一个实体类都要手动加一堆@TableField注解。log-impl配置成StdOutImpl后，控制台会打印每一条SQL语句，后端调试时看SQL日志是最直接的排查手段。
3.2 列表查询、分页与DTO设计
后端代码的分层标准是Controller、Service、Mapper三层。Controller只做参数接收和结果返回，不写业务逻辑；Service层处理业务规则，比如参数校验、状态流转、事务控制；Mapper层负责SQL执行。这个分层看起来简单，但很多项目做着做着就变形了，Controller里堆满了SQL拼接和业务代码，维护起来非常痛苦。
以景点列表接口为例，前端传入page、pageSize、areaId、keyword几个参数，后端接口设计大概是这样的：
@GetMapping("/scenic/list") public Result<PageResult<ScenicVO>> list( @RequestParam(defaultValue = "1") Integer page, @RequestParam(defaultValue = "10") Integer pageSize, @RequestParam(required = false) Integer areaId, @RequestParam(required = false) String keyword) { return Result.success(scenicService.pageList(page, pageSize, areaId, keyword)); }页面返回的数据结构建议统一封装成Result对象，包含code、message、data三个字段，前端统一处理成功和失败分支，整个项目看起来规范得多。
分页这里我用的是PageHelper插件，使用方式极其简单：查询前调用PageHelper.startPage(page, pageSize)，紧接着执行的Mapper查询方法就是分页查询，返回结果再用PageInfo包装一下，就能拿到总记录数、当前页数据等完整分页信息。很多朋友第一次用PageHelper会踩一个坑：startPage只对接下来的一条查询生效，如果在它之后又执行了别的查询，分页就会落在错误的SQL上。所以一定要养成习惯，startPage和Mapper查询之间不要插入任何其他数据库操作。
3.3 动态SQL与MyBatis高级玩法
旅游网站的列表页有个典型场景：用户搜索线路时可能按名称模糊查，可能按天数过滤，也可能按价格区间过滤，关键是有时候只有一个条件，有时候几个条件都传。如果为每种组合写一个SQL，那代码会膨胀得没法看。MyBatis的动态SQL就是为解决这种问题设计的：
<select id="selectRouteList" resultType="com.kashgar.entity.TravelRoute"> SELECT * FROM travel_route <where> <if test="keyword != null and keyword != ''"> AND title LIKE CONCAT('%', #{keyword}, '%') </if> <if test="days != null"> AND days = #{days} </if> <if test="minPrice != null"> AND price >= #{minPrice} </if> <if test="maxPrice != null"> AND price <= #{maxPrice} </if> </where> ORDER BY create_time DESC </select><where>标签会自动处理开头多余的AND，这是最常用的动态SQL写法。要特别注意的是，XML里面的>和<符号会被解析成XML标签，所以大于号小于号必须写成>、<，或者用CDATA包起来。我第一次写的时候没注意，直接在XML里写price < 5000，MyBatis直接报错，排查了半天才发现是XML转义的问题。
MyBatis的高级特性在这套系统里也用了两个。第一个是缓存。MyBatis默认开启一级缓存，也就是同一个SqlSession内，相同查询条件会直接走缓存；二级缓存需要显式开启，适合放热门景点详情这种读取多、更新少的数据。但要注意，增删改操作会清空缓存，如果业务对数据一致性要求很高，还是建议少用二级缓存。
第二个是TypeHandler。景点详情里的images字段在数据库里存的是一段JSON字符串，比如["url1","url2"]，在Java里想直接映射成List<String>。这就可以自定义一个TypeHandler，在写入时把List转成JSON字符串，读取时把JSON字符串转回List。这个技巧在真实项目中非常实用，能省掉大量手动转换代码。
3.4 登录鉴权与事务处理
用户登录功能每个系统都有，但实现方式差别很大。早期很多项目用Session保存登录态，前后端分离之后Session跨域不好使，主流方案变成了JWT。JWT的原理一句话就能说清：用户登录成功后，服务端生成一个包含用户信息的加密Token返回给前端，前端后续请求都带上这个Token，服务端验证Token合法就认为是已登录用户。
这套系统里我用的方案是JWT + SpringBoot拦截器。拦截器统一校验所有以/api/user/开头的接口，从请求头里取Token，校验通过就把用户信息放到ThreadLocal里，方便Controller直接获取当前登录用户。Token里只放userId和用户名，不要放密码之类敏感信息。密码存储用的是BCrypt加密，不是MD5。MD5虽然快，但没有加盐很容易被彩虹表破解，BCrypt每次加密结果都不同，安全性高得多。
事务控制是另一个要重点关注的点。用户提交订单涉及多个操作：创建订单记录、更新线路的报名人数、可能还要给用户增加一条订单历史。任何一个环节失败，都必须把整个操作回滚，否则就会出现下完单没扣名额、或者扣了名额没生成订单的脏数据。SpringBoot里只需要在Service方法上加一个@Transactional注解即可：
@Transactional(rollbackFor = Exception.class) public Order createOrder(OrderCreateDTO dto) { // 1. 校验线路是否存在、是否有余位 // 2. 创建订单记录 // 3. 更新线路报名人数 // 4. 返回订单信息 }rollbackFor = Exception.class这个参数要写，SpringBoot默认只回滚RuntimeException，如果业务代码抛的是检查异常，不加这个参数事务就不会回滚，这属于一个很隐蔽的坑。
4. Vue3前端：从页面搭建到联调踩坑
4.1 基于Vite创建Vue3工程
前端部分我用Vite来搭建Vue3工程，创建命令很直接：
npm create vue@latest这个命令会引导你选择需要的功能模块，建议勾上Vue Router和Pinia。Vite相比Webpack最大的优势就是启动速度快，开发时改代码热更新几乎是即时的。工程创建完成后，再安装几个必用依赖：
npm install element-plus axios piniaElement Plus是Vue3生态里最成熟的组件库，表格、表单、分页、弹窗、消息提示这些后台管理页面高频使用的组件都有现成的，不用自己手写样式。axios负责发HTTP请求，Pinia负责全局状态管理，主要存登录用户的Token和用户信息。
目录结构我习惯这么组织：views目录放页面组件，components目录放公共组件，api目录放接口请求方法，router目录放路由配置，store目录放Pinia状态，utils目录放axios封装。这种按功能划分的方式在中小型项目里足够清晰。
4.2 页面模块与组件拆分方式
前台页面需要覆盖这些模块：首页、景点列表页、景点详情页、线路列表页、线路详情页、酒店列表页、登录注册页、个人中心页。后台管理端需要覆盖：景点管理、线路管理、酒店管理、留言管理、订单管理、用户管理。
页面多，组件拆分就显得特别重要。以景点列表为例，一个景点卡片被首页和景点列表页共用，所以抽成一个ScenicCard.vue组件：接收一个景点对象作为props，内部渲染图片、名称、简介、价格。首页和列表页只需要传入不同的数据，就能复用整套卡片UI，这就是组件化的核心价值。
后台管理页面是Element Plus的主场。景点管理页面就是典型的表格页：顶部是搜索栏，中间是表格，底部是分页器。新增和编辑功能用el-dialog弹窗承载表单，删除操作先用el-popconfirm弹窗二次确认再调接口。这套交互模式在后台管理里几乎通用，第一个页面写熟练之后，后续的管理页面基本都是复制粘贴改字段名。
4.3 接口封装、状态管理与本地转发
axios封装是前端工程质量的关键。我习惯在utils/request.js里创建axios实例，设置基础配置和拦截器：
import axios from 'axios'; 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 => response.data, error => { if (error.response?.status === 401) { window.location.href = '/login'; } return Promise.reject(error); } ); export default request;请求拦截器统一在Header里加Token，响应拦截器统一处理错误状态码，所有接口请求都基于这个封装好的实例去写。接口文件单独放在api目录下，比如api/scenic.js里导出getScenicList、getScenicDetail等方法，页面里只负责调用，不直接接触axios，这样后端的接口路径统一管理，换接口时改一处就行。
开发环境的联调配置是前后端分离项目最关键的环节。前端开发服务器默认跑在5173端口，后端接口跑在8080端口，浏览器直接跨域。解决方法是在Vite配置文件里设置本地转发：
server: { port: 5173, proxy: { '/api': { target: 'http://localhost:8080', changeOrigin: true } } }这样前端请求/api/scenic/list时，Vite开发服务器会自动把请求转发到后端的http://localhost:8080/api/scenic/list，从浏览器的角度看请求是同源的，就不会出现跨域报错。
5. 上线路上的常见问题与排查经验
5.1 前后端联调典型难点
联调阶段是bug高发期，说几个我实际碰到最多的问题。
第一个是返回的数据结构和前端预期不一致。后端返回的数据里某个字段是null，前端直接访问这个字段的属性就报错了，比如后端返回的景点对象里area是null，前端模板里写scenic.area.name就直接抛TypeError。解决思路是后端统一在VO里把可能的空对象初始化成空字符串或空对象，前端也要用可选链?.兜底。
第二个问题是路由模式导致404。Vue Router用的是HTML5的History模式，路径好看但不带#号。这种模式在开发环境没问题，部署到Nginx后一刷新页面就404，因为Nginx不知道该把/scenic/detail/1这个路径交给前端路由处理。解决办法是在Nginx配置里加上try_files：
location / { try_files $uri $uri/ /index.html; }网上大量文章只教你Vue代码怎么写，却很少提这个部署坑，等真上线刷新一下才发现问题，就晚了。
第三个问题是接口字段命名风格不统一。数据库字段是下划线风格，Java属性是驼峰，前端如果直接用Java Entity返回的数据，下划线和驼峰混在一起很难看。所以后端接口的数据返回建议都用VO（视图对象），把要返回的字段整理成前端友好的结构，这也是后端规范化的体现。
5.2 MyBatis高频报错与排查
MyBatis的报错信息看起来吓人，但常见的其实就那么几类。
Invalid bound statement (not found)是出现频率最高的问题。这个错误的核心原因是Mapper接口和XML映射文件没有正确对应，排查顺序是这样的：先看XML文件的namespace是否和Mapper接口的全限定名一致；再看方法名是否和XML里的select id一致；最后看配置文件里mapper-locations是否指向了正确的路径。还有一个隐藏点，如果XML文件放在src/main/java目录下，打包的时候会被Maven过滤掉，必须把XML放resources/mapper目录，或者在pom.xml里配置resources时把XML类型也包含进去。
动态SQL里参数为空导致查询结果不对也经常发生。比如if test="areaId != null"，前端传了areaId=0，数据库里area_id是从1开始自增的所以查不到数据；前端没传areaId，参数是一个空字符串，!= null判断通过但等于空串，SQL就变成了AND area_id = ''，数据库不报错但结果为空。合理的写法是areaId != null and areaId != ''，前端传参时尤其要注意未选择的值不要传空字符串。
分页查询数据不准确的问题也很典型。用了PageHelper之后发现总记录数不对，或者每页数据重复。大概率是没有在同一个Mapper方法里既查了列表又查了count，或者同时传了多个startPage导致线程复用。PageHelper底层用的ThreadLocal存储分页参数，如果有多线程环境，分页参数会串台。排查时尽量把分页查询单独隔离在一个Service方法里。
5.3 MySQL连接、部署与运维细节
MySQL连接相关的坑主要集中在连接串配置和驱动版本上。
启动时报Public Key Retrieval is not allowed，需要在连接串上加allowPublicKeyRetrieval=true，这是因为MySQL 8.0默认使用caching_sha2_password认证插件，客户端第一次连接时需要拿服务器的公钥做密码加密传输。加了这个参数连接就会正常建立。
报The server time zone value 'Öйú±ê׼ʱ¼ä' is unrecognized，是时区没配置的原因，这个问题在3.1节已经说过，连接串里加上serverTimezone=Asia/Shanghai就能解决。
上线部署时，后端直接打jar包运行，前端把dist目录里的静态文件部署到Nginx。数据方面有几个点要提前检查：数据库字符集要确保是utf8mb4而不是utf8，否则存emoji和生僻字会报错；MySQL的sql_mode不要开启STRICT_TRANS_TABLES再往日期列插默认值，否则插入0000-00-00这种日期会直接失败；生产环境数据库账号不要直接用root，创建独立账号并只授权业务库的权限，安全性会好很多。
6. 一点个人体会和后续扩展
整套系统做下来，我最大的体会是：这个量级的项目，技术深度不是关键，把业务梳理清楚、把工程规范立住、把常见坑提前避开才是项目能顺利交付的核心。
比如数据库设计和接口约定，前期花的时间多一点，后面写代码速度会快很多；前后端联调文档不清晰，改来改去浪费的时间才是最让人崩溃的。
如果你做完这套系统还想继续扩展，我建议按这个顺序往深走：第一步加图片上传和MinIO对象存储服务，让景点图片从写死的URL变成系统自定义上传；第二步引入日志框架，统一记录请求日志和异常日志；第三步给搜索功能加上分词，比如用HanLP做中文分词，让关键词能匹配到更丰富的内容；第四步做权限控制细分，普通用户、运营、管理员三种角色，对应不同的操作权限。
做项目这件事，代码只是最后一个环节，想清楚为什么这么设计、怎么做才不容易出问题，才是真正值钱的部分。希望这篇拆解能给你一些有价值的参考。