SpringBoot2+Vue3+MyBatis-Plus旅游平台实战全解析

1. 从“给老家做个旅游系统”说起这套组合为什么能打“甘肃旅游服务平台”这个项目我前后断断续续写了差不多两个月。最开始的出发点其实很简单——想把一个区域级的旅游电商流程完整走一遍用户浏览景点和线路、查看攻略、下单预订酒店后台做内容管理和订单处理。最终落地的技术组合是SpringBoot2 Vue3 MyBatis-Plus MySQL 8.0配套完整的接口文档和部署文档。这篇文章不打算只贴源码也不打算吹技术多新而是把整个项目的设计思路和实现过程拆开来讲技术栈为什么这样选、数据库表怎么设计、后端核心接口怎么写、Vue3前端工程化怎么组织、以及最后部署上线时踩过的几个坑。如果你是正在做Java Web项目、准备毕业设计、或者想自己完整开发一个前后端分离系统的开发者这篇文章应该能省下你不少摸索时间。先解释一个很多初学者第一眼就会问的问题为什么是SpringBoot2而不是SpringBoot3为什么前端选了Vue3而不是Vue2SpringBoot2到今天依然是国内绝大多数中小型项目的稳定选择生态成熟、第三方整合资料多MyBatis-Plus对SpringBoot2的适配也最稳妥。SpringBoot3虽然已经发布但依赖版本升级会牵扯到javax到jakarta的包迁移对时间有限的开发者来说补坑成本偏高没必要为了“新”而新。Vue3这边则正好反过来——Composition API带来的组件复用能力、以及周边生态的完善都已经足够让新项目直接上车没必要再回头写Vue2的Options API。MySQL 8.0在数据查询性能、窗口函数、JSON支持、安全认证机制上都比5.7有明显提升尤其是它的caching_sha2_password认证方式配合新版驱动连接稳定性比老版本好不少。这个组合放在一个旅游平台上核心诉求就是开发速度快、维护简单、能承受中等流量跑业务完全够用。我见过不少人一上来就设计微服务架构、引入Redis缓存、搞MQ异步消息结果业务代码还没写几行先把基础设施的坑踩了一个遍。旅游服务平台这种业务核心其实就是内容展示流程交易单体应用加上合理的代码分层反而是最务实的选择。等到访问量真的大到需要拆服务的时候再按业务边界去拆分比一开始就过度设计要靠谱得多。2. 模块边界与业务链路游客、管理端和订单状态机2.1 双端功能地图前台“逛”与后台“管”做这类系统最忌讳一上来就写代码。我给自己定的第一步是先把用户角色和功能边界画清楚。这个平台面向的核心用户是两类人游客和管理员。游客端解决的是“逛”的问题。游客进入平台后能浏览景点列表、查看景点详情、搜索旅游线路、查看攻略文章可以把感兴趣的景点和线路加入收藏也可以直接在线提交预订订单。订单不涉及真实支付——这是我在设计时明确划出的边界因为真实支付会牵扯商户号、回调签名、退款流程等一大堆第三方对接工作作为独立项目来说不做在线支付反而更清晰订单统一走“待确认-已确认-已完成-已取消”的状态流转后续接入微信支付或支付宝再在提交订单环节加一步即可。管理端解决的是“管”的问题。管理员登录后台后可以维护景点信息、上传景点图片、管理旅游线路、发布攻略文章、审核用户的预订订单。每个模块的功能清单我整理成了下面这张表格模块游客端功能管理端功能景点管理列表浏览、详情查看、关键词搜索新增/编辑/上架下架/图片上传旅游线路按类型筛选、查看行程安排线路维护、关联景点、价格设置攻略文章列表阅读、分类筛选文章发布、编辑、置顶收藏中心收藏景点与线路不需要管理订单管理提交预订、查看订单状态订单确认、完成、取消这套功能地图的价值在于它把开发工作量变成了一个清单每个模块都能独立推进。实际上我编码时也是这么干的先做景点模块再做攻略模块然后做线路与收藏最后才碰订单因为订单依赖前面所有业务数据。2.2 订单状态机让数据流转不再“拍脑袋”订单模块是整个系统里最容易写乱的地方。很多人做订单时喜欢在Controller里直接update订单状态今天加一个逻辑明天改一个状态最后代码里到处都是魔法数字。我在这里采取了一种更可控的做法为订单定义一个明确的状态机。订单有四个状态我用数字存储注释写清楚含义0待确认1已确认2已完成3已取消。前端列表页只需要根据数字映射成文字即可。流转规则只有四条待确认的订单管理员确认后变更为“已确认”已确认的订单在用户完成行程后由管理员变更为“已完成”待确认和已确认的订单用户或管理员都可以发起取消变为“已取消”已完成和已取消是终态不能再变更。这个规则我直接写在了Service层的业务方法里没有在Controller里做判断确保所有入口都经过同一套校验逻辑。前端提交订单时创建的是“待确认”状态管理员看到的待办事项本质上就是一个待处理订单列表这对后台体验来说很直观。2.3 前后端交互契约接口返回结构必须统一前后端分离的项目最怕接口返回格式五花八门。有的接口返回{code:200,data:...}有的返回{success:true,result:...}联调的时候光对字段名就能对到怀疑人生。我从第一个接口开始就强制统一了返回结构{ code: 200, message: 操作成功, data: {} }这个结构我用一个Result类封装后端所有Controller的返回值都是它泛型指定data的类型。前端封装axios拦截器时只需要判断code是否为200非200直接弹出messageHTTP层面的错误再单独处理。这套约定让前后端的协作成本降到最低联调阶段几乎没有为“字段名对不上”吵过架。3. 数据库设计核心表关系与MyBatis-Plus实践细节3.1 表结构规划不搞过度设计但也别留隐患数据库是这套系统里最值得花时间的地方。我总共设计了8张核心表用户表、景点表、景点图片表、旅游线路表、线路景点关联表、攻略表、收藏表、订单表。这个规模对一个单体旅游平台来说刚刚好既能覆盖业务又不至于让表之间关系复杂到难以维护。用户表是最基础的一张表字段包括id、用户名、密码加密存储、昵称、手机号、角色、创建时间。密码加密我用了BCrypt这是Spring Security里的PasswordEncoder默认实现即使用户表数据泄露明文密码也不会直接暴露。景点表是内容核心字段有景点id、名称、所在城市、简介、详细描述、封面图、门票价格、开放时间、状态、排序值。城市字段我用的是普通字符串而不是外键因为甘肃的市州数量固定且很少变更没必要为此建一张单独的城市表。排序值很关键后台可以手动控制热门景点的展示顺序。订单表算是关联最复杂的因为它同时关联用户、景点和线路。我采用了冗余设计的思路订单里除了外键id之外额外保存了用户昵称、景点名称、线路名称、单价、数量、总价等快照字段。这样做的原因是商品信息可能被后台修改而订单代表了交易发生那一刻的真实状态必须用快照保留。很多订单查询页面需要直接展示商品名称冗余字段让我们不需要每次join多张表查询性能也更好。3.2 MyBatis-Plus的四个习惯建议新项目直接照抄MyBatis-Plus是这套系统开发效率的重要来源。用好了能省掉大量重复的Mapper XML用不好反而会让代码更乱。我总结了四个实际项目里的使用习惯。第一个是主键策略统一用ASSIGN_ID。这是MyBatis-Plus的雪花算法生成的是Long类型分布式id既避免数据库自增主键在数据迁移时的冲突性能也完全没问题。只要在实体类的主键字段上标注TableId(type IdType.ASSIGN_ID)即可。第二个是逻辑删除必须配全局配置。旅游平台的景点数据有下架需求但我从来不直接delete物理数据而是加了一个deleted字段。实体类上用TableLogic标注配置文件里加一行mybatis-plus: global-config: db-config: logic-delete-field: deleted logic-delete-value: 1 logic-not-delete-value: 0这条配置的价值在于所有通过MyBatis-Plus生成的select、update语句都会自动带上deleted0条件业务代码里完全感知不到逻辑删除的存在。如果哪天真要物理清理数据写一段SQL单独处理即可。第三个是分页查询必须依赖分页插件。MyBatis-Plus的分页插件是PaginationInnerInterceptor在配置类里声明为一个MybatisPlusInterceptor的Bean。这里有一个容易踩的坑最新版本的分页插件参数是DbType.MYSQL而不是之前那种传mysql字符串版本不同写法不通用我就在这上面花过十几分钟排查。第四个是条件构造器LambdaQueryWrapper优先。老手写动态SQL喜欢用QueryWrapper但字段名写字符串有个隐患——实体字段一改字符串不会跟着改编译期根本发现不了。用LambdaQueryWrapper或者LambdaQueryChainWrapper字段通过方法引用传递类型安全重构时无需额外维护。比如景点搜索接口里的动态条件我写起来是这样的逻辑参数非空才拼接条件参数为空就跳过代码干净且可控。4. 后端接口的骨架逻辑鉴权、检索与订单落库4.1 JWT无状态鉴权轻量方案在中小项目里最合适登录鉴权我选的是JWT没有引入Spring Security这种重框架。原因很直接这个项目没有复杂的权限粒度要求只有“游客”和“管理员”两个角色用一套简单的拦截器配合JWT就能满足需求。Spring Security的过滤器链和配置体系对很多新手来说有学习成本一个简单的项目没必要把它搞得那么重。具体实现上用户登录成功后后端用userId和role生成一个Token有效期我设为了24小时。前端拿到Token后存放在localStorageaxios请求拦截器统一从localStorage取出Token并加到请求头Authorization字段。后端写了一个拦截器拦截所有/api/**请求除了登录接口和景点列表这样不需要登录的公开接口其余请求都会校验Token。Token无效或过期直接返回401。有个细节值得提醒密码校验不要用MD5也不要自己发明加密算法。BCrypt每次的哈希值都不同验证方法在同一个PasswordEncoder里面闭合安全性和易用性都更好。注册逻辑里只有一个容易被忽视的坑——一定要在插入前先查一次用户名是否已存在否则会出现重复账号虽然数据库层面可以加唯一索引兜底但Service层先校验一次对用户体验更友好。4.2 景点检索接口多条件查询的容器思维景点列表页既要支持城市筛选、关键词搜索又需要按热度或价格排序这对应了后端接口的动态SQL。写这个接口时我最深的体会是查询条件别散落在Controller里最好用一个Query对象承接所有筛选参数。比如ScenicSpotQuery里包含city、keyword、sortType、pageNum、pageSize字段Controller只需要把这个对象传给Service层Service内部再根据对象组装条件。排序逻辑我这样处理sortType为1按排序值升序为2按门票价格降序为3按创建时间倒序。用LambdaQueryWrapper的orderBy方法动态追加排序字段默认情况按排序值升序。这里有一个细节如果查询条件里有keyword我会把name和brief两个字段都作为模糊搜索的目标配合MySQL的like语句。对于这种中小型项目景区数据量最多几千条全表like的查询压力完全可以接受没必要为了纯文本搜索去额外搭建搜索引擎。分页返回的数据不能只是一个list必须包含总数、总页数、当前页码等元数据。MyBatis-Plus的分页插件返回的Page对象里正好自带这些信息后端直接封装到统一Result里返回前端渲染分页组件完全够用。4.3 订单提交的原子性问题敏感数据必须在后端计算订单提交接口是整个系统里对安全要求最高的地方。前端提交订单时容易犯的错误是把“总价”也作为参数传过来后端不做计算直接落库。这样做的结果是价格可以被恶意用户篡改——前端能传入的任何字段都不要相信。我采取的做法是前端只传景点id或线路id、数量、出行日期后端根据id查出最新的价格再在后端计算总价。数量和单价在前端可能因为页面缓存显示错误但后端拿到的价格一定是数据库里最新的。订单一经创建这个冗余的单价和总价就成为快照后续即使景点价格被后台调整订单金额也能保持历史正确。同时创建订单的事务处理也值得一提。订单的创建会同时影响库存或名额数据但在当前这个项目里其实没有真正的票库存概念所以我在Service层只是加了一个Transactional注解保证如果出现异常不留下半截订单数据。这个习惯很重要宁可暂时没有复杂的一致性问题也要从一开始就把事务机制用起来否则后续加字段、加状态时很容易埋坑。5. Vue3前端的工程化路由、状态与API层设计5.1 前端目录按照业务模块而不是文件类型来组织Vue3前端部分我用的构建工具是Vite开发体验比Webpack好很多冷启动基本秒开。目录结构我按照业务模块来组织而不是按“components、views、router”这种纯文件类型划分。这样做的理由是一个业务模块的组件、API调用、页面路由在物理位置上就近放改动一个功能时不需要在多个目录里来回切换。src/ api/ scenic.ts order.ts auth.ts strategy.ts components/ NavBar.vue ScenicCard.vue OrderStatusTag.vue Pagination.vue views/ home/HomeView.vue scenic/ScenicListView.vue scenic/ScenicDetailView.vue line/LineListView.vue strategy/StrategyListView.vue strateview/StrategyDetailView.vue order/OrderListView.vue order/OrderCreateView.vue login/LoginView.vue admin/AdminDashboard.vue admin/ScenicManage.vue admin/OrderManage.vue router/index.ts store/user.ts utils/request.ts每个api模块封装的是对应后端接口的函数比如api/scenic.ts里就是getScenicList(query)、getScenicDetail(id)这类函数。视图只负责调用api函数和渲染数据业务逻辑尽可能放在api与store层避免把请求代码写在组件里这是组件可维护性的关键。5.2 axios统一封装拦截器比想象中更重要axios封装是前端工程化里的一个核心环节。我做了三件主要的事请求拦截、响应拦截、错误统一处理。请求拦截器负责在每次请求发出前从localStorage里取Token并塞到请求头。响应拦截器里判断后端返回的code如果code为401表示Token失效直接清除本地登录态并跳转到登录页如果code为其他非200值弹出一条错误提示并让当前请求的Promise reject防止业务代码拿到非正常数据还继续执行。这里要注意一个细节axios的响应拦截器里如果后端返回的是业务层面的错误码比如“订单不存在”ideally不应该当HTTP错误处理而是保持HTTP状态码200只在body里用code标记失败。这样HTTP层与业务层的错误可以清晰分离网络层面的500、502等异常走全局异常捕获业务错误走message提示排查问题时好定位。5.3 Pinia状态管理与路由守卫的配合用户登录状态的管理我用了Pinia。store/user.ts里保存了用户信息、Token和登录角色页面初始化时从localStorage恢复用户信息保证刷新后登录态不丢失。与Vuex相比Pinia的API更简洁没有mutation和action的区分直接可以定义方法和状态对新手友好很多。路由守卫配合Pinia实现访问控制是前端鉴权的重要一环。在路由配置里带meta: { requiresAuth: true }的路由表示需要登录带meta: { requiresAdmin: true }的表示只有管理员能进入。全局前置守卫里先判断是否需要认证需要的话再看有没有Token没有就跳登录页并记录来源路径登录成功后再跳回去。管理端路由还额外检查用户角色非管理员访问时直接跳回首页后端接口层面也有相同的权限拦截这样才能做到双保险。5.4 行程卡片组件联调中的用户体验细节景点和线路的前台展示使用频率最高的组件是行程卡片。卡片上会展示封面图、名称、价格、标签。联调时发现一个很容易被忽略的问题图片加载失败的展示。后端上传的图片地址如果失效前端会显示一个破图图标为了这件事我在卡片组件的img标签上加了onerror事件失败时替换成默认占位图并且在接口请求失败时保留上一次的数据而不是白屏。前端展示“价格”这一项时也要注意数据精度问题。后端返回的价格如果是Double类型前端展示可能会出现89.999999这种浮点误差。解决方案是后端在实体类中用BigDecimal定义价格字段前端展示时用toFixed(2)格式化我在实际项目里遇到的这个坑虽然不复杂但确实影响体验。6. 部署细节与文档编写从“本地能跑”到“真正能用”6.1 配置文件区分环境开发、测试、生产各玩各的项目能跑起来和能部署上线中间隔着一条很宽的河。最常见的问题就是配置文件一点到底开发环境的数据库密码和生产环境混在一起。我在resources目录下分了三个配置文件application-dev.yml、application-test.yml、application-prod.yml再配合一个application.yml作为公共入口里面只放spring.profiles.active来决定使用哪个环境。dev环境我设置了数据库连接指向本地MySQL日志级别是debug方便开发时看到每一条SQL语句。prod环境的日志级别是info并且把MyBatis-Plus的SQL日志关掉或降低级别避免生产日志被大量日志刷爆。切换环境时不需要改动业务代码只需要修改active的值这个机制在交付源码时对方很容易上手。SpringBoot的默认端口配置也提醒一下打算部署到云服务器时不要把后端端口设置成8080后就完事最好结合Nginx的代理策略一起规划。我在项目里后端跑在8080端口Nginx监听80并反向代理到对应路径前端静态资源由Nginx直接托管。前后端分离部署最关键的一点是前端请求地址不能写死localhost我用的是相对路径/api加上Nginx的location /api { proxy_pass http://127.0.0.1:8080; }规则统一转发这样无论前端部署在哪里请求路径都不用改。6.2 初始化与构建的两个坑第一次启动项目时数据库初始化是一个很容易出错的环节。MySQL 8.0的默认字符集其实是utf8mb4但如果你在Navicat里手动建库可能字符集被设成了utf8就会导致中文乱码和排序异常。我建议在项目的SQL初始化脚本里显式指定CREATE DATABASE IF NOT EXISTS gansu_tourism DEFAULT CHARSET utf8mb4 COLLATE utf8mb4_general_ci;接着导入表结构和初始化数据再改数据库连接地址这样交给任何环境都能快速跑起来。我在交付文档里把初始化步骤写得特别细包括MySQL版本要求8.0及以上、字符集要求、账号密码修改点就是为了让使用者不用对着报错一遍遍猜。前端构建时也有个坑需要注意Vite默认构建输出的资源路径是绝对路径/assets/...如果项目不是部署在域名根目录而是部署在某个子路径下就会出现404。解决方法是修改vite.config.ts里的base配置或者部署时把构建产物放在域名根目录。为了简单起见我在文档里直接推荐放在根目录这样最省事。6.3 MySQL8.0驱动的版本匹配一个十次有九次会踩的坑SpringBoot2和MySQL 8.0搭配时maven依赖里用的是mysql-connector-java还是mysql-connector-j版本号很容易写错。SpringBoot2.7之前的官方驱动坐标是mysql:mysql-connector-java2.7之后变成了com.mysql:mysql-connector-j。如果版本不匹配最典型的报错是Public Key Retrieval is not allowed解决方法是给JDBC连接串加上allowPublicKeyRetrievaltrueuseSSLfalse或者升级驱动版本。这个坑我在第一次用MySQL 8.0时就碰到过花了半小时才排查出来。现在我把这个配置直接写进了项目文档的常见问题小节里后来接手这套源码的同事基本没有在这里卡住。6.4 项目文档应该包含哪几部分这套系统题目里特别标注了【含文档】这也是我在交付之前花了几天时间专门整理的部分。文档的目录结构是这样的第一部分是项目概述和技术栈说明第二部分是环境准备包含JDK、Maven、Node、MySQL版本的对应关系第三部分是数据库初始化教程从建库到导入SQL脚本每个步骤都有截图位置说明第四部分是启动步骤分后端和前端两部分后端用IDE启动或命令行打包启动前端用npm install和npm run dev两种模式说明第五部分是核心接口列表每个接口都标注了请求方式、接口路径、请求参数、返回结构示例这部分相当于一个迷你版的接口文档第六部分是部署上线指导包含服务器环境搭建、Nginx配置示例、jar包启动命令、常见报错排查。写文档这件事看起来不产生“代码价值”但实际交付时它的价值往往比代码本身还高。给我代码最多让我能运行给我一份好文档能让我在理解业务和二次开发上节省大量时间。我在实际使用中就遇到过只给了源码没有文档的项目数据库脚本缺失、配置文件残缺光靠猜就能耗掉一整天。7. 二次开发与扩展方向这套系统还能往哪里走系统的基本功能完成了但离一个“商业化旅游平台”其实还差好几层。做二开时我的建议是先明确方向再评估改动范围。第一个可以扩展的方向是接入真实支付。在订单提交成功之后增加一个支付步骤前端接入微信支付或支付宝的网页支付。后端需要增加支付回调接口、订单状态与支付状态的映射逻辑、以及对账补偿机制。这个扩展会让订单状态机从四态变成至少六态需要仔细评估前端和后端同时改造的成本。第二个方向是增加评论与评分功能。景点详情页目前只展示文字和图片如果能增加一个评论区用户可以在游览后发表评价、上传照片并打分。再进一步可以做一个评分聚合展示比如“4.8分·128条评论”这会让平台更有社区感也更能辅助用户决策。数据表上需要新增评论表并在景点列表接口里增加聚合查询。第三个更好的方向是做成多区域版本。当前系统的表设计里城市字段是普通字符串如果把城市改成可配置的实体表再增加一个区域id关联字段同一套代码就能快速复制成“青海旅游服务平台”“陕西旅游服务平台”。这对于准备把这个项目写成系列作品、或者作为课程设计交付的人来说是一个性价比很高的扩展。第四个方向是后台数据统计。管理端目前只有基础管理功能如果想让系统看起来更专业可以增加一个数据看板用ECharts展示每日订单趋势、热门景点Top10、用户来源分布。后端只需要新增几个统计接口按日期和景点分组查询订单表前端再画几张图表整个平台的完成度就会再上一个台阶。8. 最后说几个实操中让我记忆深刻的细节系统跑通之后的很长一段时间里我还在不断调整一些边角细节。这些细节没有写在任何教科书里但它们在真实使用中对体验的影响特别大。第一个是空数据状态的展示。列表页如果没有数据前端一定要有一个友好的空状态占位而不是空白一片。我在景点列表和订单列表里都加入了这种空状态内容包括一张简单的插图风格的提示图片和一句“暂无相关数据”的提示文案。这个功能开发起来成本很低但对用户感知的提升非常明显。第二个是后端统一异常处理的必要。如果不写全局异常处理器Controller里每抛一个运行时异常用户看到的就可能是Spring默认的错误页或包含堆栈的JSON这既不友好也可能泄露项目结构信息。我的做法是用RestControllerAdvice做全局异常处理器捕获BusinessException、MethodArgumentNotValidException等常见异常统一转成Result结构返回同时记录错误日志方便排查。第三个是时间字段的格式化问题。后端默认的LocalDateTime序列化格式是2024-01-05T10:24:00中间有个T前端直接展示非常难看。我通过配置全局的Jackson格式化方式把时间输出为yyyy-MM-dd HH:mm:ss前端就不再需要写格式化方法。第四个细节是数据导入。初始化数据脚本里的景点描述我写了一些示例文本实际使用时后台需要导入真实景点数据。由于每张图片的URL都是真实链接如果连接失效前端要做兜底处理。不过我在后台管理系统里做了图片地址校验的提示管理员上传时能第一时间发现无效链接。做完整套系统我最大的体会是技术选型不需要追新稳定合理比华丽重要业务流程不需要复杂状态清晰比堆功能重要文档不需要洋洋洒洒能让不了解项目的人按步骤跑起来最重要。这套SpringBoot2 Vue3 MyBatis-Plus MySQL 8.0的组合在一个区域旅游平台项目里体现出的开发效率和可维护性都让人满意。如果你正打算着手类似的前后端分离项目不妨直接从这套架构开始先从“把业务逻辑跑通”入手再逐步加上增强功能整个过程中的收获会比单纯看教程多得多。