你有没有遇到过这种情况需求方甩过来一个旅游管理系统的项目说得很简单——能登录、能订门票、能管订单就行。但真到动手的时候才发现一个所谓的简单系统背后牵扯的远不止几个页面。用户注册登录要鉴权、线路和酒店要分类管理、下单要有状态流转、前端要处理权限、后端要控制并发更别提部署上线时的跨域、端口、静态资源这些细枝末节每一个都是坑。我最近完整落地了一套前后端分离的旅游管理系统技术栈锁定在SpringBoot Vue MyBatis MySQL。这套组合不花哨但非常耐打尤其是带新人和快速交付项目时稳定性和可复制性都很好。这篇文章我会把整个项目的设计思路、数据库建模、前后端核心实现、部署流程以及我踩过的坑全部记录下来方便想复现这套架构的同行直接参考。1. 项目整体定位与架构选型考量1.1 前后端分离到底解决了什么问题很多刚接触这类项目的同学会疑惑为什么非要前后端分离传统JSP模板一把梭不也挺爽的吗说实话在小项目里传统方式确实更快但一旦涉及下面几个场景分离架构的优势就非常明显了。首先是协作效率。旅游管理系统涉及管理员后台、用户端小程序/网页、运营配置端等多个入口前端团队和后端团队可以各干各的后端定义好接口契约后前端用Mock数据就能推进界面开发不用等对方联调。其次是部署灵活性。前端构建出的纯静态文件可以放在任意CDN或Web服务器上后端只暴露API两者甚至可以在不同机器上独立扩容。第三是技术栈解耦。Vue负责路由和状态管理SpringBoot只做业务逻辑和数据存取未来前端想换React、后端想换微服务框架都不需要推翻重来。当然分离也带来了一些新问题最常见的就是跨域。开发环境我通过Vite代理解决生产环境则用Nginx反向代理统一入口这个细节我后面在部署章节会展开讲。1.2 为什么是这套技术栈选型的时候我不是没考虑过更偏现代化的组合比如Spring Cloud Alibaba全家桶或者干脆用若依这种脚手架二次开发。但最终敲定SpringBoot Vue MyBatis MySQL是经过实际场景权衡的。SpringBoot的价值在于约定优于配置。起步依赖、自动装配、内嵌Tomcat三分钟就能把一个可运行的后端工程拉起来这对交付周期紧张的项目来说是实打实的效率。Vue选择当前主流的Vue 3 Composition API配合Vite构建工具开发时的热更新速度也是Vue 2时代无法比的。MyBatis和MyBatis-Plus在这儿我多说一句。很多教程喜欢把MyBatis-Plus直接引入然后全都用Wrapper查询这样确实快但容易把SQL基本功荒废。我在这套系统里采用原生MyBatis 少量MyBatis-Plus逆向生成的方式复杂多表关联用XML手写SQL简单单表操作用通用Mapper这个平衡点对项目可维护性最友好。MySQL则采用8.0版本InnoDB引擎事务隔离级别保持默认的REPEATABLE READ足以应对这个量级的业务。提示技术选型不要盲目追新团队熟悉度、交付时间、维护成本这三项权重最高。这套栈的优势在中小型管理系统中非常实用你完全可以在简历里写“独立完成系统架构选型”因为你的确做过权衡。2. 功能模块拆解与数据库设计2.1 核心业务模块边界划分拿到需求第一件事不是写代码而是把业务模块的边界划清楚。我按角色和业务域把系统拆成五块第一块是用户中心。包含注册、登录、个人信息维护、密码找回后台管理员也是独立的一套账号体系。第二块是资源管理。这是系统的基础数据来源包括景点信息、旅游线路、酒店房型、餐饮套餐等。每一类资源都有独立的增删改查接口并且要支持上传图片。第三块是订单中心。用户选定线路或景点后生成订单订单状态分为待支付、已支付、已出票、已取消、已退款几个阶段后台可以对订单进行审核和操作。第四块是内容管理。包括新闻公告、旅游攻略、轮播图配置主要是为了撑起前端首页的门面。第五块是数据看板。后台首页需要展示营收汇总、订单趋势、热门线路Top5这块其实就是为了让管理端看起来像个正经系统。这里踩过一个坑一开始我把景点、线路、酒店设计成三张完全独立的表结果订单表里要关联不同类型的商品表结构搞得非常别扭。后来我把可预订的资源抽象为商品表旅游线路和酒店房型都关联到商品ID上订单只记录商品ID和类别字段一下子清爽了很多。2.2 数据表设计与关联关系数据库设计是整个项目的基石表结构设计得不好后面写查询就是灾难。我的核心表一共八张外加一张用于存储字典数据的表。用户表(user)包含id、username、password、nickname、phone、avatar、role、status、create_time这几个字段。密码我用BCrypt加密存储不用MD5因为MD5对暴力破解基本没有防御力。role字段用字符串区分普通用户和管理员简单场景用这个方案完全可以等以后角色多了再引入单独的权限表。商品表(product)的结构相对复杂id、type区分景点/线路/酒店、name、description、cover_image、price、stock、status。这里有个设计点价格用分单位存储的整数避免浮点数运算误差。很多新手喜欢用decimal也能接受但用整数在统计聚合时能省掉不少麻烦。订单表(order)是核心中的核心字段包括id、order_no、user_id、product_id、product_type、quantity、total_amount、status、pay_time、create_time、update_time。order_no用时间戳随机数生成保证唯一性的同时方便按时间回溯。其他还有收藏表、公告表、轮播图表和评论表设计思路中规中矩需要注意的是所有表都默认带上create_time和update_time字段这对排查线上问题极其重要。多说一句数据库设计的规范主键用自增id就够了别一上来就搞雪花算法和分布式ID单机单库的小系统自增主键的插入性能和顺序性最好等真到了分库分表的阶段再换也来得及。2.3 接口文档与状态码约定接口文档我坚持用YApi这类工具在线维护不是为了追求仪式感而是因为联调时前后端各看各的时间一长极易扯皮。下面把核心接口列出方便你理解整个系统提供了什么能力用户相关的接口有POST /api/auth/register、POST /api/auth/login、GET /api/user/info、PUT /api/user/info。商品相关的有GET /api/product/list、GET /api/product/detail?id、POST /api/admin/product、PUT /api/admin/product、DELETE /api/admin/product。订单相关的有POST /api/order/create、GET /api/order/myList、POST /api/order/cancel、GET /api/admin/order/list、POST /api/admin/order/audit。统一返回格式我用Result对象封装包括code、message、data三个字段。code为200表示成功401表示未登录或登录过期403表示无权限500表示服务器异常。注意接口返回的JSON格式必须全局统一这比什么都重要。另外时间字段统一返回时间戳前端负责格式化避免不同环境下时区解析出新问题。3. SpringBoot后端从零到一的实现细节3.1 工程初始化与分层结构我不建议用在线生成器生成一个满是配件的工程规范的手动初始化反而更清晰。我用Spring Initializr创建基础工程选择Web、MyBatis、MySQL Driver、Validation这几个起步依赖。Java版本用的8不要一上手就升到17很多服务器环境生产JDK8更稳妥。项目结构按经典三层架构来组织controller层负责接收参数和响应结果、service层处理核心业务逻辑、mapper层负责数据访问。我这里会额外加一个dto文件夹存放接收参数的类一个vo文件夹存放返回给前端的对象。这样做的理由很直接接收参数和返回结果永远不要直接用实体类。用实体类接收参数的后果就是当接口新增字段时必须改动数据库映射类一个偷懒操作能引发一连串的耦合问题这是我多次吃过亏之后总结出来的。application.yml的配置也是老生常谈但有几个关键点需要留意。MyBatis的mapper-locations要指向XML文件目录map-underscore-to-camel-case设为true这样数据库的下划线字段就能自动映射到Java驼峰属性。MySQL的url里必须加上useUnicodetrue和characterEncodingutf8否则中文乱码问题够你排查一整晚。3.2 登录鉴权与拦截器实现鉴权方案我选的是JWT没有引入Spring Security。不是Security不好而是旅游管理系统这种角色的权限并不复杂用Security反而要写大量配置类和过滤器对团队协作来说学习成本偏高。我只需要一个拦截器加一个注解就能搞定大部分需求。JWT工具类负责生成和解析token。生成时把userId和role塞进payload设置过期时间为48小时。拦截器对需要登录的接口进行校验从请求头的Authorization字段取出token解析成功就把用户信息放到ThreadLocal里后续业务直接从ThreadLocal取值不用每个方法都传userId参数。这里有个非常容易忽略的细节放行登录、注册、商品列表这些公开接口时路径匹配一定要写清楚我之前就是写顺手把/admin开头的接口也放行了导致管理员接口裸奔了一天还好是测试环境否则影响很大。密码存库用BCrypt。登录时调用加密工具的matches方法校验原始密码和哈希值。需要说明的是BCrypt每次生成的哈希值都不一样所以绝对不能直接用等值查询去匹配密码这也是很多新手常犯的错误。3.3 MyBatis动态SQL与关联查询列表页的动态条件查询是MyBatis的高频使用场景我的办法是在XML中引用一个叫Base_Column_List的SQL片段里面列出所有需要返回的字段避免select *然后利用where标签和if标签组装动态条件。这套写法既清晰又不会把SQL字符串拼在Java代码里可维护性比在service层手写if拼接要好得多。关联查询上重点处理了两个场景。第一个是订单列表页需要显示商品名称和用户昵称这时就需要订单表joined商品表注意查询时要用别名区分字段两表joins时返回的异构结果用Map或自定义VO接收。第二个是商品详情页需要展示关联的评论列表这个我采用两次查询的方式去实现第一次先查商品信息第二次查评论列表避免一条SQL里嵌套复杂的子查询影响响应速度。分页用MyBatis-Plus的分页插件配置一个拦截器即可。前端传pageNum和pageSize后端返回pageList对象里面包含当前页数据、总量、总页数。这样前端分页组件的页码计算逻辑就不用自己写了。3.4 数据校验与异常统一处理接口入参校验在后端必须做千万不要指望前端过滤了就可以不做。在DTO字段上用Hibernate Validator的注解比如NotBlank、Email、Min、Size然后在Controller参数上标注Validated。如果校验不通过全局异常处理器会捕获MethodArgumentNotValidException并返回统一格式的提示信息。全局异常处理类一般标注RestControllerAdvice把业务异常、参数校验异常、系统异常分层次处理。业务异常我自定义一个BizException比如选择位已满、库存不足这类问题直接在这个类里抛出。数据库异常和空指针属于系统异常日志打出来前端返回一个系统繁忙请稍后再试绝不能让用户看到堆栈信息。注意全局异常处理不只是为了体验也是为运维减负。你永远不想大半夜因为在代码里漏了try-catch而被用户截图堆栈更成熟的做法是捕获所有异常后统一记录日志并推送告警这套系统里可以先从统一的日志格式开始。4. Vue前端开发与接口联调4.1 工程初始化与路由设计前端工程我用的Vite创建方式很简单直接npm create vite选项选择Vue模板即可。目录结构上views按页面维度区分目录components放可复用的子组件router集中管理路由配置store用Pinia管理全局状态api目录统一放接口调用方法。路由设计是这里的关键。我划分了客户端页面和管理后台两套路由。客户端包括首页、商品列表、商品详情、订单确认、个人中心后台包括数据看板、商品管理、订单管理、用户管理、公告管理。这两套路由不能混在一个路由数组里面我用嵌套路由的方式withLayout布局组件统一引入顶部导航和底部footer后台则用单独的后台布局组件包含侧边栏和头部。路由守卫的作用是防止未登录用户进入后台页面。我在全局前置守卫里获取token值判断目标路由的meta是否需要登录。后台路由统一设置meta: { requiresAuth: true }守卫里如果发现没有token就重定向到登录页同时携带redirect参数登录成功后再跳回原页面。4.2 请求封装与状态管理axios请求封装是每个Vue项目里的必修课。我自己封装了一个request模块用axios.create指定baseURL为/api把请求头里的Content-Type设为application/json。请求拦截器把token写进Authorization头里响应拦截器统一处理返回结构。响应拦截器里判断code如果code为401则清理本地token并跳转到登录页这是无感续期前的简单兜底方案。如果code为200但业务逻辑失败直接reject一个带有message的Error全局弹一个消息提示。如果code为500统一提示服务器异常。这套处理逻辑看起来简单但在项目中很实用。Pinia存储当前登录用户信息和token。刷新页面时store会被清空所以初始化时我要从localStorage里恢复状态再从接口拉取用户信息。这里有一个持久化技巧可以不引第三方库直接手写一个store插件订阅state变化后同步写入localStorage。4.3 核心页面组件实现要点首页的开发重点是轮播图和商品卡片区。轮播图我直接用Element Plus的Carousel组件数据来自管理后台配置的轮播图表。商品卡片用el-card嵌套el-image点击跳转到详情页时传商品ID参数。商品详情页需要处理几个状态的变化价格显示、库存数量、选择的数量、加入购物车还是立即购买。由于商品有类型之分我在这里加了tab切换不同类型展示不同的属性面板。这个页面联调时要多测几遍因为后端返回的数据结构因商品类型差异而不一致。订单确认页是相对复杂的页面要展示商品信息、联系人信息、支付金额还要选择支付方式。我先展示信息让用户确认最后调创建订单接口。支付这块我做了模拟支付直接调用mock接口替换订单状态为已支付实际生产时对接微信支付或支付宝的流程可以在这个位置换掉。管理后台数据看板页面我用的ECharts做图表展示。折线图展示近七日订单趋势柱状图展示各线路销量饼图展示营收占比。图表数据从专门的统计接口获取这个接口分别用聚合查询和分组查询来完成统计计算。4.4 权限控制与路由守卫前端的权限控制实际上是视觉层面上的控制真正的安全控制必须依赖后端接口校验这个本末不能倒置。后台管理系统有两类角色超级管理员和普通管理员。超级管理员能看到系统的全部菜单普通管理员只能管理商品和公告不能进入用户管理模块。实现思路是登录成功后后端返回用户信息和权限标识列表。前端根据权限标识动态拼接该用户可见的路由表用addRoute方法动态添加路由这是Vue Router的动态路由注册也是前端权限控制最优雅的方案。动态路由注册有个坑需要提醒直接调用addRoute后如果用户刷新页面动态路由会丢失。原因在于路由表是内存对象刷新即清零。常见的解决办法是在应用初始化时重新拉取用户信息并再次动态注册路由或者把路由表持久化到localStorage。我选择在全局守卫里做一次异步的权限路由初始化避免初次刷新时白屏。5. 完整部署流程与参数解析5.1 后端打包与运行配置后端部署第一步是打成可执行的JAR包。我建议在pom.xml里配置Spring Boot Maven插件然后执行mvn clean package -DskipTests。跳过测试的选项在交付时间紧张时很有用但上线前一定要手工跑一遍核心测试用例。打包完成后运行面试时一句j java -jar。但生产环境我用nohup方式让进程在后台运行并输出日志到指定文件。启动参数里一定要配置堆内存大小比如-Xms512m -Xmx1024m不配置的话JVM默认按照物理内存四分之一来分配很容易把机器内存打满。生产环境的MySQL连接信息不要写在application.yml里改用启动命令的参数覆盖。例如 bspring.datasource.urldatabaseurl 。这样源码仓库里不会出现敏感信息部署的人只需要改启动脚本里面的参数就可以了。5.2 前端构建与静态资源部署前端部署比较简单执行npm run build后dist目录就是需要发布的静态文件。构建过程会把Vue组件编译成JS文件资源文件名带上hash字段。这个hash很重要因为浏览器缓存策略要求文件名变化后才能加载新版本。有多种部署方式推荐用Nginx承载前端静态资源再同时充当反向代理处理API请求。Nginx配置里最核心的是location /api应该用proxy_pass转发到后端服务地址。另外前端路由采用history模式如果一个用户直接在浏览器输入网站某个子路径Nginx会返回404所有请求都要try_files重定向到index.html这是部署Vue项目时的经典易错点。5.3 端口、跨域与安全配置开发环境怎么做跨域的配置因为Vite的devServer默认跑在5173端口后端跑在8080端口。跨域这个问题其实不用在服务端解决只需要在Vite配置文件里面设置proxy选项。开发环境的全部/api请求都会转发到8080端口而浏览器感知不到也就不存在跨域报错的问题。生产环境是靠Nginx解决代理转发的问题。前端静态文件监听80端口接口请求也走的80后端8080当作内部服务不对公网开放。这样可以统一入口避免为后端单独配置CORS。安全配置方面可以考虑增加IP黑白名单把管理后台的访问IP限到指定网段。再一个就是给后端加Spring Security或简单的过滤器限制后台接口的调用来源这能有效防住外部扫描工具对后台API的大范围探测。6. 实战排坑实录与运维心得6.1 七类高频问题速查表我把这个项目里遇到过的高频问题整理成一张速查表方便团队新人快速定位。现象可能原因解决思路前端请求404路由history模式未配置try_files检查Nginx的location配置接口请求403拦截器未放行公开接口核对拦截器路径匹配规则登录成功后刷新即失效Pinia状态未持久化检查localStorage同步逻辑中文乱码数据库连接URL缺少编码参数添加characterEncodingutf8列表页白屏动态路由注册失败检查addRoute执行时机定时任务不触发服务时间与服务器时间不一致检查心跳及时区设置图片加载失败静态资源路径写死改用动态拼接的完整路径这几个问题几乎覆盖了前后端分离项目里80%的线上异常。排查思路其实是固定的先从网络请求层看状态码再到后端日志里查找对应操作记录最后检查配置文件和代码逻辑。6.2 排查套路与工具推荐日志是运维排查的第一生产力。我要求后端的日志输出格式统一包含时间、线程名、日志级别、类名和消息内容。生产环境用Logback的配置文件按天滚动保留30天日志。在代码切面里做一次请求日志拦截包括请求路径、参数、响应时间和状态码这样线上排查时不用猜。工具方便的话重点说两个。第一个是Postman推荐用它的环境变量来管理不同环境的请求地址接口调试时把token放在collection变量里避免测试时频繁拷贝。第二个建议装一个简易的内存监控工具或命令比如使用jsta或prometheus与grafana组合虽然这套SkyWalking级别的监控对小项目来说重了但对后端服务可用率、线程数量和内存指标的基本关注还是要做到位。6.3 改动一个字段引发的连锁故障案例踩过最有代表性的坑是改了商品表的价格字段类型。一开始没太在意反正改动只是从分单位的整数改成以元为单位的decimalSQL查询基本不用动。结果订单中心模块的营收统计接口就开始出现金额不一致的问题因为我按小数求和的结果因为尾差和不同环境下浮点数精度问题跟实际订单表记录的总和差了0.01元。这个问题的根源在于底层存储模型的变更没有同步评估上层所有消费方。后来把价格存储统一回分为单位对外的响应层再换算成元彻底修掉了精度问题。这件事给我的教训是做数据库字段变更时不能只看数据表本身的影响要顺着调用链把涉及的计算逻辑都推演一遍。写在最后的几个小建议整套系统从设计到落地、再到部署上线我前后总共用了一周左右的时间。过程中最大的体会是这种全栈项目技术本身永远不是瓶颈瓶颈在于面对细节时的耐心。也许你实现登录时觉得token太麻烦就放宽校验条件也许你觉得订单状态流转就三步不需要设计状态图这些偷懒行为单独看都不致命但加起来就会让一个系统变得脆弱。如果你打算复现这套项目我建议从数据库建表开始先把表的字段关系理清楚再动手写后端接口最后才轮到前端页面。很多新手喜欢从搭建Vue界面开始结果后端的字段改了又改前端跟着返工这是最浪费时间的路径。最后再说一个扩展方向——这套架构完全可以把订单模块替换成实际的支付功能把商品模块替换成任何你熟悉的行业资源骨架不变换的是业务壳。说白了学会一套健壮的开发骨架比背熟某个项目的代码有价值得多。希望这篇记录能让你少走一些我正在走的弯路。 
长河君 · 2026/10/14 15:38:44 · 阅读 1.2k 前后端分离旅游管理系统实战：SpringBoot+Vue+MyBatis+MySQL架构与部署
你有没有遇到过这种情况需求方甩过来一个旅游管理系统的项目说得很简单——能登录、能订门票、能管订单就行。但真到动手的时候才发现一个所谓的简单系统背后牵扯的远不止几个页面。用户注册登录要鉴权、线路和酒店要分类管理、下单要有状态流转、前端要处理权限、后端要控制并发更别提部署上线时的跨域、端口、静态资源这些细枝末节每一个都是坑。我最近完整落地了一套前后端分离的旅游管理系统技术栈锁定在SpringBoot Vue MyBatis MySQL。这套组合不花哨但非常耐打尤其是带新人和快速交付项目时稳定性和可复制性都很好。这篇文章我会把整个项目的设计思路、数据库建模、前后端核心实现、部署流程以及我踩过的坑全部记录下来方便想复现这套架构的同行直接参考。1. 项目整体定位与架构选型考量1.1 前后端分离到底解决了什么问题很多刚接触这类项目的同学会疑惑为什么非要前后端分离传统JSP模板一把梭不也挺爽的吗说实话在小项目里传统方式确实更快但一旦涉及下面几个场景分离架构的优势就非常明显了。首先是协作效率。旅游管理系统涉及管理员后台、用户端小程序/网页、运营配置端等多个入口前端团队和后端团队可以各干各的后端定义好接口契约后前端用Mock数据就能推进界面开发不用等对方联调。其次是部署灵活性。前端构建出的纯静态文件可以放在任意CDN或Web服务器上后端只暴露API两者甚至可以在不同机器上独立扩容。第三是技术栈解耦。Vue负责路由和状态管理SpringBoot只做业务逻辑和数据存取未来前端想换React、后端想换微服务框架都不需要推翻重来。当然分离也带来了一些新问题最常见的就是跨域。开发环境我通过Vite代理解决生产环境则用Nginx反向代理统一入口这个细节我后面在部署章节会展开讲。1.2 为什么是这套技术栈选型的时候我不是没考虑过更偏现代化的组合比如Spring Cloud Alibaba全家桶或者干脆用若依这种脚手架二次开发。但最终敲定SpringBoot Vue MyBatis MySQL是经过实际场景权衡的。SpringBoot的价值在于约定优于配置。起步依赖、自动装配、内嵌Tomcat三分钟就能把一个可运行的后端工程拉起来这对交付周期紧张的项目来说是实打实的效率。Vue选择当前主流的Vue 3 Composition API配合Vite构建工具开发时的热更新速度也是Vue 2时代无法比的。MyBatis和MyBatis-Plus在这儿我多说一句。很多教程喜欢把MyBatis-Plus直接引入然后全都用Wrapper查询这样确实快但容易把SQL基本功荒废。我在这套系统里采用原生MyBatis 少量MyBatis-Plus逆向生成的方式复杂多表关联用XML手写SQL简单单表操作用通用Mapper这个平衡点对项目可维护性最友好。MySQL则采用8.0版本InnoDB引擎事务隔离级别保持默认的REPEATABLE READ足以应对这个量级的业务。提示技术选型不要盲目追新团队熟悉度、交付时间、维护成本这三项权重最高。这套栈的优势在中小型管理系统中非常实用你完全可以在简历里写“独立完成系统架构选型”因为你的确做过权衡。2. 功能模块拆解与数据库设计2.1 核心业务模块边界划分拿到需求第一件事不是写代码而是把业务模块的边界划清楚。我按角色和业务域把系统拆成五块第一块是用户中心。包含注册、登录、个人信息维护、密码找回后台管理员也是独立的一套账号体系。第二块是资源管理。这是系统的基础数据来源包括景点信息、旅游线路、酒店房型、餐饮套餐等。每一类资源都有独立的增删改查接口并且要支持上传图片。第三块是订单中心。用户选定线路或景点后生成订单订单状态分为待支付、已支付、已出票、已取消、已退款几个阶段后台可以对订单进行审核和操作。第四块是内容管理。包括新闻公告、旅游攻略、轮播图配置主要是为了撑起前端首页的门面。第五块是数据看板。后台首页需要展示营收汇总、订单趋势、热门线路Top5这块其实就是为了让管理端看起来像个正经系统。这里踩过一个坑一开始我把景点、线路、酒店设计成三张完全独立的表结果订单表里要关联不同类型的商品表结构搞得非常别扭。后来我把可预订的资源抽象为商品表旅游线路和酒店房型都关联到商品ID上订单只记录商品ID和类别字段一下子清爽了很多。2.2 数据表设计与关联关系数据库设计是整个项目的基石表结构设计得不好后面写查询就是灾难。我的核心表一共八张外加一张用于存储字典数据的表。用户表(user)包含id、username、password、nickname、phone、avatar、role、status、create_time这几个字段。密码我用BCrypt加密存储不用MD5因为MD5对暴力破解基本没有防御力。role字段用字符串区分普通用户和管理员简单场景用这个方案完全可以等以后角色多了再引入单独的权限表。商品表(product)的结构相对复杂id、type区分景点/线路/酒店、name、description、cover_image、price、stock、status。这里有个设计点价格用分单位存储的整数避免浮点数运算误差。很多新手喜欢用decimal也能接受但用整数在统计聚合时能省掉不少麻烦。订单表(order)是核心中的核心字段包括id、order_no、user_id、product_id、product_type、quantity、total_amount、status、pay_time、create_time、update_time。order_no用时间戳随机数生成保证唯一性的同时方便按时间回溯。其他还有收藏表、公告表、轮播图表和评论表设计思路中规中矩需要注意的是所有表都默认带上create_time和update_time字段这对排查线上问题极其重要。多说一句数据库设计的规范主键用自增id就够了别一上来就搞雪花算法和分布式ID单机单库的小系统自增主键的插入性能和顺序性最好等真到了分库分表的阶段再换也来得及。2.3 接口文档与状态码约定接口文档我坚持用YApi这类工具在线维护不是为了追求仪式感而是因为联调时前后端各看各的时间一长极易扯皮。下面把核心接口列出方便你理解整个系统提供了什么能力用户相关的接口有POST /api/auth/register、POST /api/auth/login、GET /api/user/info、PUT /api/user/info。商品相关的有GET /api/product/list、GET /api/product/detail?id、POST /api/admin/product、PUT /api/admin/product、DELETE /api/admin/product。订单相关的有POST /api/order/create、GET /api/order/myList、POST /api/order/cancel、GET /api/admin/order/list、POST /api/admin/order/audit。统一返回格式我用Result对象封装包括code、message、data三个字段。code为200表示成功401表示未登录或登录过期403表示无权限500表示服务器异常。注意接口返回的JSON格式必须全局统一这比什么都重要。另外时间字段统一返回时间戳前端负责格式化避免不同环境下时区解析出新问题。3. SpringBoot后端从零到一的实现细节3.1 工程初始化与分层结构我不建议用在线生成器生成一个满是配件的工程规范的手动初始化反而更清晰。我用Spring Initializr创建基础工程选择Web、MyBatis、MySQL Driver、Validation这几个起步依赖。Java版本用的8不要一上手就升到17很多服务器环境生产JDK8更稳妥。项目结构按经典三层架构来组织controller层负责接收参数和响应结果、service层处理核心业务逻辑、mapper层负责数据访问。我这里会额外加一个dto文件夹存放接收参数的类一个vo文件夹存放返回给前端的对象。这样做的理由很直接接收参数和返回结果永远不要直接用实体类。用实体类接收参数的后果就是当接口新增字段时必须改动数据库映射类一个偷懒操作能引发一连串的耦合问题这是我多次吃过亏之后总结出来的。application.yml的配置也是老生常谈但有几个关键点需要留意。MyBatis的mapper-locations要指向XML文件目录map-underscore-to-camel-case设为true这样数据库的下划线字段就能自动映射到Java驼峰属性。MySQL的url里必须加上useUnicodetrue和characterEncodingutf8否则中文乱码问题够你排查一整晚。3.2 登录鉴权与拦截器实现鉴权方案我选的是JWT没有引入Spring Security。不是Security不好而是旅游管理系统这种角色的权限并不复杂用Security反而要写大量配置类和过滤器对团队协作来说学习成本偏高。我只需要一个拦截器加一个注解就能搞定大部分需求。JWT工具类负责生成和解析token。生成时把userId和role塞进payload设置过期时间为48小时。拦截器对需要登录的接口进行校验从请求头的Authorization字段取出token解析成功就把用户信息放到ThreadLocal里后续业务直接从ThreadLocal取值不用每个方法都传userId参数。这里有个非常容易忽略的细节放行登录、注册、商品列表这些公开接口时路径匹配一定要写清楚我之前就是写顺手把/admin开头的接口也放行了导致管理员接口裸奔了一天还好是测试环境否则影响很大。密码存库用BCrypt。登录时调用加密工具的matches方法校验原始密码和哈希值。需要说明的是BCrypt每次生成的哈希值都不一样所以绝对不能直接用等值查询去匹配密码这也是很多新手常犯的错误。3.3 MyBatis动态SQL与关联查询列表页的动态条件查询是MyBatis的高频使用场景我的办法是在XML中引用一个叫Base_Column_List的SQL片段里面列出所有需要返回的字段避免select *然后利用where标签和if标签组装动态条件。这套写法既清晰又不会把SQL字符串拼在Java代码里可维护性比在service层手写if拼接要好得多。关联查询上重点处理了两个场景。第一个是订单列表页需要显示商品名称和用户昵称这时就需要订单表joined商品表注意查询时要用别名区分字段两表joins时返回的异构结果用Map或自定义VO接收。第二个是商品详情页需要展示关联的评论列表这个我采用两次查询的方式去实现第一次先查商品信息第二次查评论列表避免一条SQL里嵌套复杂的子查询影响响应速度。分页用MyBatis-Plus的分页插件配置一个拦截器即可。前端传pageNum和pageSize后端返回pageList对象里面包含当前页数据、总量、总页数。这样前端分页组件的页码计算逻辑就不用自己写了。3.4 数据校验与异常统一处理接口入参校验在后端必须做千万不要指望前端过滤了就可以不做。在DTO字段上用Hibernate Validator的注解比如NotBlank、Email、Min、Size然后在Controller参数上标注Validated。如果校验不通过全局异常处理器会捕获MethodArgumentNotValidException并返回统一格式的提示信息。全局异常处理类一般标注RestControllerAdvice把业务异常、参数校验异常、系统异常分层次处理。业务异常我自定义一个BizException比如选择位已满、库存不足这类问题直接在这个类里抛出。数据库异常和空指针属于系统异常日志打出来前端返回一个系统繁忙请稍后再试绝不能让用户看到堆栈信息。注意全局异常处理不只是为了体验也是为运维减负。你永远不想大半夜因为在代码里漏了try-catch而被用户截图堆栈更成熟的做法是捕获所有异常后统一记录日志并推送告警这套系统里可以先从统一的日志格式开始。4. Vue前端开发与接口联调4.1 工程初始化与路由设计前端工程我用的Vite创建方式很简单直接npm create vite选项选择Vue模板即可。目录结构上views按页面维度区分目录components放可复用的子组件router集中管理路由配置store用Pinia管理全局状态api目录统一放接口调用方法。路由设计是这里的关键。我划分了客户端页面和管理后台两套路由。客户端包括首页、商品列表、商品详情、订单确认、个人中心后台包括数据看板、商品管理、订单管理、用户管理、公告管理。这两套路由不能混在一个路由数组里面我用嵌套路由的方式withLayout布局组件统一引入顶部导航和底部footer后台则用单独的后台布局组件包含侧边栏和头部。路由守卫的作用是防止未登录用户进入后台页面。我在全局前置守卫里获取token值判断目标路由的meta是否需要登录。后台路由统一设置meta: { requiresAuth: true }守卫里如果发现没有token就重定向到登录页同时携带redirect参数登录成功后再跳回原页面。4.2 请求封装与状态管理axios请求封装是每个Vue项目里的必修课。我自己封装了一个request模块用axios.create指定baseURL为/api把请求头里的Content-Type设为application/json。请求拦截器把token写进Authorization头里响应拦截器统一处理返回结构。响应拦截器里判断code如果code为401则清理本地token并跳转到登录页这是无感续期前的简单兜底方案。如果code为200但业务逻辑失败直接reject一个带有message的Error全局弹一个消息提示。如果code为500统一提示服务器异常。这套处理逻辑看起来简单但在项目中很实用。Pinia存储当前登录用户信息和token。刷新页面时store会被清空所以初始化时我要从localStorage里恢复状态再从接口拉取用户信息。这里有一个持久化技巧可以不引第三方库直接手写一个store插件订阅state变化后同步写入localStorage。4.3 核心页面组件实现要点首页的开发重点是轮播图和商品卡片区。轮播图我直接用Element Plus的Carousel组件数据来自管理后台配置的轮播图表。商品卡片用el-card嵌套el-image点击跳转到详情页时传商品ID参数。商品详情页需要处理几个状态的变化价格显示、库存数量、选择的数量、加入购物车还是立即购买。由于商品有类型之分我在这里加了tab切换不同类型展示不同的属性面板。这个页面联调时要多测几遍因为后端返回的数据结构因商品类型差异而不一致。订单确认页是相对复杂的页面要展示商品信息、联系人信息、支付金额还要选择支付方式。我先展示信息让用户确认最后调创建订单接口。支付这块我做了模拟支付直接调用mock接口替换订单状态为已支付实际生产时对接微信支付或支付宝的流程可以在这个位置换掉。管理后台数据看板页面我用的ECharts做图表展示。折线图展示近七日订单趋势柱状图展示各线路销量饼图展示营收占比。图表数据从专门的统计接口获取这个接口分别用聚合查询和分组查询来完成统计计算。4.4 权限控制与路由守卫前端的权限控制实际上是视觉层面上的控制真正的安全控制必须依赖后端接口校验这个本末不能倒置。后台管理系统有两类角色超级管理员和普通管理员。超级管理员能看到系统的全部菜单普通管理员只能管理商品和公告不能进入用户管理模块。实现思路是登录成功后后端返回用户信息和权限标识列表。前端根据权限标识动态拼接该用户可见的路由表用addRoute方法动态添加路由这是Vue Router的动态路由注册也是前端权限控制最优雅的方案。动态路由注册有个坑需要提醒直接调用addRoute后如果用户刷新页面动态路由会丢失。原因在于路由表是内存对象刷新即清零。常见的解决办法是在应用初始化时重新拉取用户信息并再次动态注册路由或者把路由表持久化到localStorage。我选择在全局守卫里做一次异步的权限路由初始化避免初次刷新时白屏。5. 完整部署流程与参数解析5.1 后端打包与运行配置后端部署第一步是打成可执行的JAR包。我建议在pom.xml里配置Spring Boot Maven插件然后执行mvn clean package -DskipTests。跳过测试的选项在交付时间紧张时很有用但上线前一定要手工跑一遍核心测试用例。打包完成后运行面试时一句j java -jar。但生产环境我用nohup方式让进程在后台运行并输出日志到指定文件。启动参数里一定要配置堆内存大小比如-Xms512m -Xmx1024m不配置的话JVM默认按照物理内存四分之一来分配很容易把机器内存打满。生产环境的MySQL连接信息不要写在application.yml里改用启动命令的参数覆盖。例如 bspring.datasource.urldatabaseurl 。这样源码仓库里不会出现敏感信息部署的人只需要改启动脚本里面的参数就可以了。5.2 前端构建与静态资源部署前端部署比较简单执行npm run build后dist目录就是需要发布的静态文件。构建过程会把Vue组件编译成JS文件资源文件名带上hash字段。这个hash很重要因为浏览器缓存策略要求文件名变化后才能加载新版本。有多种部署方式推荐用Nginx承载前端静态资源再同时充当反向代理处理API请求。Nginx配置里最核心的是location /api应该用proxy_pass转发到后端服务地址。另外前端路由采用history模式如果一个用户直接在浏览器输入网站某个子路径Nginx会返回404所有请求都要try_files重定向到index.html这是部署Vue项目时的经典易错点。5.3 端口、跨域与安全配置开发环境怎么做跨域的配置因为Vite的devServer默认跑在5173端口后端跑在8080端口。跨域这个问题其实不用在服务端解决只需要在Vite配置文件里面设置proxy选项。开发环境的全部/api请求都会转发到8080端口而浏览器感知不到也就不存在跨域报错的问题。生产环境是靠Nginx解决代理转发的问题。前端静态文件监听80端口接口请求也走的80后端8080当作内部服务不对公网开放。这样可以统一入口避免为后端单独配置CORS。安全配置方面可以考虑增加IP黑白名单把管理后台的访问IP限到指定网段。再一个就是给后端加Spring Security或简单的过滤器限制后台接口的调用来源这能有效防住外部扫描工具对后台API的大范围探测。6. 实战排坑实录与运维心得6.1 七类高频问题速查表我把这个项目里遇到过的高频问题整理成一张速查表方便团队新人快速定位。现象可能原因解决思路前端请求404路由history模式未配置try_files检查Nginx的location配置接口请求403拦截器未放行公开接口核对拦截器路径匹配规则登录成功后刷新即失效Pinia状态未持久化检查localStorage同步逻辑中文乱码数据库连接URL缺少编码参数添加characterEncodingutf8列表页白屏动态路由注册失败检查addRoute执行时机定时任务不触发服务时间与服务器时间不一致检查心跳及时区设置图片加载失败静态资源路径写死改用动态拼接的完整路径这几个问题几乎覆盖了前后端分离项目里80%的线上异常。排查思路其实是固定的先从网络请求层看状态码再到后端日志里查找对应操作记录最后检查配置文件和代码逻辑。6.2 排查套路与工具推荐日志是运维排查的第一生产力。我要求后端的日志输出格式统一包含时间、线程名、日志级别、类名和消息内容。生产环境用Logback的配置文件按天滚动保留30天日志。在代码切面里做一次请求日志拦截包括请求路径、参数、响应时间和状态码这样线上排查时不用猜。工具方便的话重点说两个。第一个是Postman推荐用它的环境变量来管理不同环境的请求地址接口调试时把token放在collection变量里避免测试时频繁拷贝。第二个建议装一个简易的内存监控工具或命令比如使用jsta或prometheus与grafana组合虽然这套SkyWalking级别的监控对小项目来说重了但对后端服务可用率、线程数量和内存指标的基本关注还是要做到位。6.3 改动一个字段引发的连锁故障案例踩过最有代表性的坑是改了商品表的价格字段类型。一开始没太在意反正改动只是从分单位的整数改成以元为单位的decimalSQL查询基本不用动。结果订单中心模块的营收统计接口就开始出现金额不一致的问题因为我按小数求和的结果因为尾差和不同环境下浮点数精度问题跟实际订单表记录的总和差了0.01元。这个问题的根源在于底层存储模型的变更没有同步评估上层所有消费方。后来把价格存储统一回分为单位对外的响应层再换算成元彻底修掉了精度问题。这件事给我的教训是做数据库字段变更时不能只看数据表本身的影响要顺着调用链把涉及的计算逻辑都推演一遍。写在最后的几个小建议整套系统从设计到落地、再到部署上线我前后总共用了一周左右的时间。过程中最大的体会是这种全栈项目技术本身永远不是瓶颈瓶颈在于面对细节时的耐心。也许你实现登录时觉得token太麻烦就放宽校验条件也许你觉得订单状态流转就三步不需要设计状态图这些偷懒行为单独看都不致命但加起来就会让一个系统变得脆弱。如果你打算复现这套项目我建议从数据库建表开始先把表的字段关系理清楚再动手写后端接口最后才轮到前端页面。很多新手喜欢从搭建Vue界面开始结果后端的字段改了又改前端跟着返工这是最浪费时间的路径。最后再说一个扩展方向——这套架构完全可以把订单模块替换成实际的支付功能把商品模块替换成任何你熟悉的行业资源骨架不变换的是业务壳。说白了学会一套健壮的开发骨架比背熟某个项目的代码有价值得多。希望这篇记录能让你少走一些我正在走的弯路。