1. 技术选型背后的那笔账为什么是这套组合先把结论放在前面这套源码的定位是企业级它不是那种只有一个景点列表和登录注册的教学Demo而是真正扔到服务器上能持续跑业务、能扛住日常并发、能让人事后来改代码的完整项目。所以技术栈不是拍脑袋定的每一层选择都有实际理由。后端我用了SpringBoot而不是传统SSM。SSM本身没有错但SpringBoot把配置从一堆XML里解放出来内嵌Tomcat又省掉了外置容器的部署动作这对快速迭代和团队协作都友好得多。更重要的是SpringBoot的自动配置让换环境、换数据库、发新版本这些琐事成本大幅降低企业里最怕的不是写业务代码而是环境不一致导致的在我机器上明明能跑。持久层选了MyBatis而不是JPA或MyBatis-Plus这点争议最大。我的判断逻辑是旅游管理系统的查询往往带着大量动态条件——日期范围、价格区间、目的地标签、余位数量这些场景拼SQL是家常便饭。MyBatis的XML里写动态SQL特别直观sql片段还能复用团队里即便是刚入门的人也能快速看懂而JPA的复杂查询到最后基本都在写JPQL或者原生SQL反而不如MyBatis直接。至于MyBatis-Plus它确实让单表CRUD变快了但项目里一旦出现五六张表的关联聚合查询底层还是得回到MyBatis的SQL能力上所以核心框架我坚持用原生的。前端选了Vue搭配Vue Router和Vuex现在可以换Pinia但源码里保留了经典写法UI组件库用Element-UI。Vue在表单处理、数据绑定、组件复用这三个维度的开发效率对管理后台来说几乎是量身定做的。页面多、字段多、交互杂Vue的响应式机制能让开发节奏快很多。数据库用MySQL也是深思熟虑过的。MySQL的InnoDB引擎在事务、行锁、崩溃恢复这几个关键指标上完全够用生态成熟度又是所有关系型数据库里最高的。从备份、主从复制到各种可视化客户端运维成本低招人也容易。企业选型有一个隐形成本叫团队熟悉度MySQL正好在这上面得分最高。2. 这套旅游管理系统到底管理了些什么标题里的旅游管理系统听起来宽泛但它落地的业务边界其实非常清楚它管的是旅游产品从设计、上架、销售到履约结算的全过程而不是只有景点增删改查。2.1 业务全景从用户下单到导游接单的完整链路我梳理业务时把整个系统拆成了六条核心链路产品管理链、订单交易链、支付对账链、资源库存链、员工权限链、统计报表链。产品管理链管的是景点、线路、酒店、餐饮、车辆这些基础资源运营人员把它们组合成可销售的旅游产品比如三亚五日游就是机票酒店景点门票接送巴士的组合产物。订单交易链是整个系统的心脏。用户在前端选产品、下订单、支付后端生成订单号、锁定库存、回调更新支付状态。这条链路里最容易出问题的不是CRUD而是支付成功但订单状态没更新这类一致性问题。我的做法是支付回调接口设计成幂等的无论微信或支付宝回调多少次最终状态都是已支付同时用消息日志表记录每一次回调的原始报文方便排查扯皮问题。资源库存链解决的是卖超问题。旅游产品不像普通商品有无限库存每个团期有固定的人数上限所以库存扣减必须做到原子操作。我的方案是使用数据库行锁配合乐观锁版本号在极端并发下宁可部分请求失败也绝不超卖。2.2 权限模型五种角色六类权限的落地方式企业管理后台必须做权限控制不然运营人员能看到订单毛利、财务能看到成本底价迟早出事。这套系统采用基于RBAC基于角色的访问控制的权限模型内置了五种角色超级管理员、运营人员、财务人员、导游、普通用户。超级管理员拥有全部菜单和按钮权限运营人员只能操作产品、线路、班期上下架导游只开放接单、填写出团记录、上传游客签到信息。前端通过动态路由实现菜单权限后端通过Spring Security拦截器校验每个接口的角色标识双重保障。角色主要菜单权限关键按钮权限超级管理员全部模块全部操作运营人员产品管理、线路管理、班期管理新增、编辑、上架、下架财务人员订单管理、结算管理、报表中心查看、导出、对账导游出团管理、签到管理填写出团记录、上传签到普通用户前台浏览、个人中心下单、支付、评价这套权限模型最大的好处是新增一个岗位时不需要改代码只需要在角色管理里配置新的角色和权限点。热词里很多人搜mybatis面试题时都会遇到RBAC相关考题其实就是问你对权限模型的设计能力这套系统里已经有了完整答案。2.3 核心表设计概览数据库里一共26张表核心的几张是sys_user用户表、sys_role角色表、t_product产品表、t_product_sku产品SKU表用于存团期、余位、价格、t_order订单表、t_order_item订单明细表、t_payment_log支付日志表、t_resource资源表存景点酒店等基础资源。其中订单表上必须建订单号唯一索引产品SKU表必须建产品ID团期日期的联合唯一索引这两个索引直接决定业务数据是否干净。MySQL默认值这块也有讲究。比如订单状态字段我默认设成0待支付删除标记默认0创建时间用TIMESTAMP默认当前时间。热词里有人搜mysql设置默认值为0在实际项目中硬编码默认值比在代码里手动赋值更可靠因为绕过代码直连数据库做数据修正时默认值能兜底。3. 前端工程化与Vue的实战细节很多自学Vue的朋友会卡在会写组件但不会搭项目这个阶段。这套源码的前端部分就是一个完整的Vue工程化范例从目录结构到路由守卫都有讲究。3.1 动态路由与按钮级权限的实现思路前端权限控制分成两步。第一步是登录成功后后端返回当前用户的权限标识列表比如[product:add, order:export]。前端拿到这个列表后在路由拦截器里动态添加该用户可见的路由表。// vue-router 前置守卫里的核心逻辑 router.beforeEach((to, from, next) { const token localStorage.getItem(token) if (!token to.path ! /login) { next(/login) } else if (token !router.getRoutes().some(r r.path to.path)) { // 动态加载该用户有权限的路由 const permissionRoutes generateRoutes(store.state.permissionList) permissionRoutes.forEach(r router.addRoute(r)) next({ ...to, replace: true }) } else { next() } })按钮级权限用自定义指令实现v-permissionproduct:add没有权限的按钮直接移除。这个细节是热词里vue路由参数之外最容易被忽略的点——很多同类项目只做了菜单级别的权限但企业后台真正防的是有人绕过菜单直接通过URL访问非法接口所以前端按钮权限只是体验优化后端接口鉴权才是底线。3.2 跨域配置与接口封装前端开发时要对接后端的localhost:8080必须配置开发代理否则浏览器会拿同源策略卡你。我在vue.config.js里配置了代理转发module.exports { devServer: { proxy: { /api: { target: http://localhost:8080, changeOrigin: true, pathRewrite: { ^/api: } } } } }这里踩过一个坑如果后端接口路径本身就带/api前缀那pathRewrite需要相应调整不然会出现404。我见过不少新手在 Stack Overflow 上提问前端请求404、后端线程堆栈有请求但返回404八成就是代理路径重写错了。接口请求封装层面我统一用axios实例请求拦截器自动携带token响应拦截器统一处理错误码。超时时间设成15秒因为订单导出接口可能涉及大量数据时间设太短容易被误杀。3.3 表单校验与组件封装的工程化套路旅游管理后台有大量复杂表单产品编辑页里有基本信息、图片上传、SKU列表、行程安排一个页面可能有七八个区块。如果每个区块都写在自己的组件里父子组件之间靠事件通信会非常混乱。我采用的方法是按区块封装组件组件内部管理自己的局部数据通过v-model语法糖对外暴露值。页面只负责汇总数据提交不关心每个组件的内部状态。这符合Vue官方推荐的单向数据流通过事件向上传递模式也让后来的维护者不用读完整套代码才能上手。Element-UI的el-table在处理大量行数据时性能一般超过500条会出现明显卡顿我通常在列表页用分页加懒加载来规避。后端接口坚持分页查询每页20条不要图省事返回全量数据这对前后端都是好习惯。4. 数据库设计与MyBatis数据访问层的那些坑这一部分我要讲系统里最核心的数据访问层设计顺便把热词里关于MyBatis的疑惑逐个说透。4.1 库存扣减的正确写法乐观锁VS悲观锁旅游产品每个团期有固定余位比如3月20日三亚五日游只能收30人卖完就得关团。两个用户同时下单如果代码这么写// 错误示范 int stock skuMapper.selectStock(skuId); if (stock 0) { stock stock - 1; skuMapper.updateStock(skuId, stock); }那一定会超卖因为两个线程读到的stock可能都是1然后都执行减一最终库存变成0但卖出去了两单。正确做法是使用乐观锁版的原子更新在SQL里直接扣减并校验库存充足update iddeductStock UPDATE t_product_sku SET stock stock - 1, version version 1 WHERE id #{skuId} AND stock 0 /update同时给SKU表加一个version字段在更新时带上版本号判断可以防止ABA问题。这种先到先得、卖完即止的策略比用分布式锁简单可靠得多也符合企业级系统的常规实现路径——不是所有并发问题都要上Redis锁数据库本身的行锁和原子操作已经能解决大部分场景。4.2 MyBatis一级缓存与二级缓存的真实差异热词里有mybatis缓存和mybatis中初始化工作流程这里分享下我的实践理解。MyBatis一级缓存是SqlSession级别的默认开启同一个SqlSession内执行两次相同的查询第二次会直接命中缓存。这个特性在单机小项目里很舒服但在Spring管理的SqlSession里它每次请求创建的SqlSession也不完全一样所以一级缓存的实际收益有限。二级缓存是namespace级别的默认关闭。我强烈建议企业项目不要开二级缓存原因有三一是多表关联查询时只要关联的某一张表数据变了所有相关的二级缓存都可能变成脏数据缓存失效策略非常难写二是项目一旦部署到多实例二级缓存存在单机内存里各节点数据不一致三是MyBatis二级缓存本身不支持细粒度的失效控制不如Redis可控。我在源码里遵循的原则是查询用MySQL索引优化不依赖缓存兜底。高频查询的景点列表、线路列表我会在前端用Vuex做一层简单缓存后端不缓存保证数据永远是最新的。4.3 TypeHandler把数据库类型和Java类型正确对应起来MySQL的DateTime、JSON、枚举类型在Java里到底映射成什么需要一个明确约定。MyBatis自带的TypeHandler支持基础类型但项目里遇到LocalDateTime和枚举时就得自定义了。Java 8的LocalDateTime是个典型场景。MyBatis 3.4以上版本已经支持LocalDateTime但前提是数据库连接的JDBC驱动要够新而且SQL里不能把LocalDateTime当Date用。我写过自定义TypeHandler继承BaseTypeHandlerLocalDateTime重写setNonNullParameter和getNullableResult三个方法MappedJdbcTypes(JdbcType.TIMESTAMP) public class LocalDateTimeTypeHandler extends BaseTypeHandlerLocalDateTime { Override public void setNonNullParameter(PreparedStatement ps, int i, LocalDateTime parameter, JdbcType jdbcType) throws SQLException { ps.setObject(i, Timestamp.valueOf(parameter)); } Override public LocalDateTime getNullableResult(ResultSet rs, String columnName) throws SQLException { Timestamp timestamp rs.getTimestamp(columnName); return timestamp ! null ? timestamp.toLocalDateTime() : null; } // 其余两个重载方法省略 }自定义TypeHandler的价值在于统一了格式化规则、兼容了不同数据库驱动的时间处理差异也让枚举类型可以以字符串形式安全地存进MySQL。源码里订单状态、支付方式、产品类型这些字段都是枚举配合TypeHandler后在代码里读起来非常干净不用到处写数字对应的含义。4.4 动态SQL企业查询从不简单我为什么这么坚持MyBatis因为它的XML里动态SQL确实好用。订单查询页有大量筛选条件时间段、订单状态、产品名称、手机号、支付渠道。用MyBatis写就是whereif的自然拼接而JPA写这种查询往往要面向Specification构造一大堆对象代码可读性直线下降。从维护角度看这类查询SQL经常被DBA要求看执行计划、优化索引。MyBatis的XML文件可以直接扔给DBA看团队沟通成本低这也是企业选型时一个容易被忽略的隐形优势。5. 部署这套源码的完整实录从环境准备到线上运行为了让拿到源码的人能顺利跑起来我把自己从零部署一次的实际过程写下来。5.1 环境版本搭配关键点版本组合是这套源码最容易被卡住的地方。我测试过比较稳的组合是JDK 1.8切记不是JDK 17SpringBoot 2.x在JDK 17上会出现反射相关的兼容问题Maven 3.6.3MySQL 5.78.0也行但驱动要对应Node.js 14以上Vue2项目在Node 16上运行最稳npm 6.14版本太高可能导致依赖树解析报错热词里有人搜springboot版本太高很多新人习惯下载最新版SpringBoot结果发现项目根本编译不过。这套源码基于SpringBoot 2.3.7.RELEASE这是2.x里非常稳定且教程资料最多的版本别轻易升级大版本。5.2 数据库初始化与MySQL连接配置源码的sql目录下有一个tourism.sql包含建库、建表、初始数据。执行时注意字符集我统一用utf8mb4不然存储emoji表情或生僻字会报错。连接串里最容易出问题的是useSSL参数。如果你本地MySQL没配SSL连接字符串必须加上这些参数不然启动时会卡在SSL握手或者直接抛异常spring.datasource.urljdbc:mysql://localhost:3306/tourism?useUnicodetruecharacterEncodingutf8useSSLfalseserverTimezoneAsia/ShanghaiserverTimezoneAsia/Shanghai必须加否则数据库时区默认是UTCJava 8的LocalDateTime在存取时间会差8个小时。这个坑我在接手项目时踩过用户下单时间显示成下午而不是上午查了半天才发现是时区配置问题。5.3 前端项目启动流程前端项目在frontend目录下。第一步npm install如果报错大概率是Node版本与依赖不兼容换成Node 14基本都能解决。第二步配置代理保证vue.config.js里的target指向后端地址。第三步npm run dev访问localhost:8081默认登录账号admin/123456。一个容易被忽略的启动细节后端项目里的application.yml配置了后端端口为8080如果这个端口被占用前端所有接口都会失败。我在Windows上遇到过8080端口被某个服务占用一查发现是Oracle的TNS监听废了好大劲才定位到。推荐用端口检测工具提前确认环境。5.4 反编译别人jar包作为参考的合法工作流热词里有一条怎么将springboot jar反编译成项目这其实是一种很常见的学习和企业内部维护手段。你可能会遇到领导丢来一个线上运行的jar让分析它应该怎么配置或者里面某个类的逻辑此时用反编译工具看字节码是待定的但要提醒两点反编译仅供学习和排查自身公司系统绝不能把别人有知识产权的系统反编译后直接改个名字对外售卖。工具层面我常用的是CFR和Luyten先反编译出Java文件再用IDEA打开整个目录能极大提升阅读效率。但反编译源码始终没有原始工程舒服因为注解、注释、资源文件的原始结构会有损失。5.5 全局过滤器处理XSS攻击很多开发者做项目从来没考虑过XSS直到某天运营反馈后台编辑器里粘贴的内容把页面样式搞坏了或者更严重的登录Cookie被偷了。这套源码里我加了全局XSS过滤器对用户提交的所有参数做HTML转义存储层不做变更但输出到页面时能防止脚本执行。过滤器实现原理很简单继承OncePerRequestFilter重写doFilterInternal把请求体包装成可重复读取的流然后对参数值做HtmlUtils.htmlEscape。这里容易踩的坑是文件上传接口也会经过过滤器导致上传的文件内容被转义所以要注意对上传类接口做白名单放行。6. 这套源码还能往哪里升级从单体到企业级的进阶思路如果你拿这套系统当毕设或课设现在的完整度已经很够了。但如果你想把它真正运营起来有几个升级方向值得做这也是我觉得企业级三个字的另一层含义——不是做完交差而是能持续演进。第一个升级是引入Redis。目前所有热点数据都查MySQL景点列表和产品列表在流量上来后会频繁命中数据库虽然MySQL扛得住几千QPS但没必要。把首页推荐、热销线路、用户会话token这类数据放进Redis响应速度立竿见影。热词里搜minio加入到springboot那就是第二个升级方向把文件存储从本地磁盘换成MinIO图片、PDF、Excel导出文件都走对象存储系统部署到多台服务器时才不会出现图片在这台机器有、在另一台机器没有的尴尬。第三个升级是网关化。现在前后端分离是直连的如果未来要做小程序端、App端就得再抽一个API网关层统一做鉴权、限流、日志采集。这个思路可以从NacosGateway的组合开始在Gateway里把接口鉴权的公共逻辑抽出来后端服务专注于业务。第四个升级是数据统计实时化。目前的报表中心是定期统计的离线报表有点滞后。如果运营要实时看各条线路的销售转化漏斗必要时可以接入ClickHouse或者直接用MySQL的定时汇总表把核心指标预先聚合查询性能能提升一个量级。我在实际部署这套系统时最大的感受是企业项目和技术Demo之间的差距从来不是某个炫酷的框架或算法而是对边界情况的处理。库存别超卖、回调别重复、时区要统一、权限要双重校验这些细碎的点构成了系统的可靠性也最终决定了它能不能真正上线见用户。如果你也想基于这套源码做二次开发我的建议是先别急着加功能把订单链路和权限链路完整跟一遍想清楚每一步为什么这么设计再动手改代码。这套系统目前的扩展性已经预留了接口比如订单状态流转可以平滑接成状态机权限模块可以无缝换成更细粒度的数据权限你只需要在正确的位置做加法就够了。