滑雪场的旺季一旦开始售票窗口前面就是一场灾难。排队排到门口、闸口刷票卡死、财务晚上扎账怎么都对不上、票务员被问“还剩几张票”回答不上来——这些我在现场都见过。所以当时决定做一套“javavue基于springboot的滑雪场售票系统”的时候我心里很清楚这不是一个普通的CRUD练习而是一套要扛住并发、算得清账、管得住库存的完整业务系统。这个项目从技术栈上看是标准的SpringBoot Vue前后端分离架构后端用Java写接口、处理业务逻辑前端用Vue做页面交互数据库放MySQL。但它真正难的地方不在技术本身而在“票”这个核心实体上票有票型、有库存、有价格、有有效期卖出去之后还要核销、退款、对账。任何一环没设计好上了线就是事故。这篇文章我会把从数据库设计、库存扣减、订单流程、二维码生成、后端接口、前端页面到部署上线的完整过程拆开写重点讲那些课程设计里不会告诉你、但实战中一定会踩的细节比如超卖、支付回调幂等、跨域配置、JWT过期、Element Plus分页、Nginx反向代理这些。所有代码思路和步骤都是我实际跑通过、验证过的方案适合正在做类似毕业设计、课设或者想入门Java全栈开发的朋友直接参考。1. 系统整体设计与技术选型1.1 项目背景与目标功能滑雪场的售票业务跟普通景区或者电影院有点不一样它的票型非常复杂。除了常见的成人票、儿童票、学生票之外还分平日票和节假日票周末和法定节假日的价格是两套体系有分时段的日场票、夜场票还有租赁套餐比如“雪板雪鞋雪杖”三件套一起租或者单租雪镜、头盔、护具。这些票种还要跟库存关联比如某天日场双板套票就剩17份了卖完就是卖完不能像电商那样等付款后再锁库存。所以系统的核心目标就三件事把票卖出去、把库存算准、把账对得上。从实际功能模块上看我把它拆成了这样几个部分用户端门票浏览与搜索、下单支付模拟支付/微信支付沙箱、订单查询、门票二维码展示、取消与退款。管理端票价与库存管理、订单管理、门票核销、退款审核、用户管理、销售数据统计。公共能力用户注册登录、JWT鉴权、Redis缓存热点数据、定时任务超时取消未支付订单、二维码生成与核销。这个功能清单跟大部分毕设题目的要求是对得上的但你如果只是照着这个列表去写代码最后交出来的东西大概率只是“能跑”离“能用”还差得远。所以我建议所有做类似系统的人上手之前先在纸上把订单状态机和库存扣减流程画出来把最复杂的业务场景想明白再写代码。1.2 技术栈选型的底层逻辑技术选型这件事我一直坚持一个原则不盲目追新选稳定、文档多、自己熟的东西。这个项目后端我用的是SpringBoot 2.7.18并不是说SpringBoot 3.x不好而是这个版本对应JDK 8/JDK 11生态最稳网上资料最多跟MyBatis-Plus的兼容性也最好。很多人一上来就用SpringBoot 3.2甚至SpringBoot 3.4结果MyBatis-Plus版本不兼容、javax换成jakarta、配置类报一堆错光折腾环境就耗掉一两天完全没有必要。如果你的项目刚开始选一个你老师见过、网上有大量教程的稳定版本一定是最优解。持久层我选了MyBatis-Plus而不是原生MyBatis或者JPA。原因很简单原生MyBatis写单表CRUD太啰嗦JPA的复杂查询和自定义SQL写起来又不太直观。MyBatis-Plus处在中间位置单表操作用BaseMapper直接搞定多表联查手写XML也完全可控对订单明细、票种库存这些复杂业务非常友好。前端用的Vue版本是这个项目里我纠结过的一个点。Vue 2在2023年底就停止维护了所以新项目我直接选用了Vue 3。配套的组件库选的是Element Plus路由用Vue Router 4状态管理用PiniaHTTP请求用Axios。这套组合是Vue 3生态的标准搭配遇到问题搜一下基本都有答案不像以前那样要自己到处试。Redis在这个项目里不是摆设。我把它用在了三个地方缓存票种列表和首页营销位减少高频查询打爆MySQL存JWT黑名单实现用户退出登录时立刻让旧token失效生成全局唯一订单号的计数器用Redis的INCR特性保证并发环境下订单号不重复。2. 数据库设计与核心表结构2.1 核心表拆解数据库设计是这类系统里最关键、也最不能偷懒的部分。表结构没设计好后面写业务代码的时候会处处别扭。我最终拆了6张核心表每张表的定位和逻辑我下面串起来讲一遍。第一张是用户表。一般就存手机号、昵称、密码BCrypt加密存储、角色、状态这些字段。角色我用int存1是管理员2是普通用户不做复杂的RBAC权限表因为这个小系统里就两种角色建一堆角色权限表的成本大于收益。第二张是票种表也可以叫商品表。票种ID、票种名称、所属雪场区域、票型类型日场/夜场/节假日、单价、状态。价格字段必须用BigDecimal这个我在后面会专门吐槽一遍。第三张是库存表。这是我认为整个系统设计里最重要的一张表。它把“日期”和“票种”组合成一个维度每条记录代表“某个票种在某天的库存量”这样你可以精确控制每天每种票卖出去多少张。第四张是订单表订单号、用户ID、总金额、支付状态、订单状态、创建时间、支付时间、关闭时间。第五张是订单明细表存每个订单里包含的票种ID、数量、单价、使用的日期。第六张是核销记录表记录了哪张票、什么时候、由哪个闸口/工作人员核销的。2.2 关键字段设计与状态机订单状态我设计了5个状态用int字段存取值0到40未支付1已支付未核销2已核销3已取消4已退款。这个状态机在代码里是有严格流转约束的不能随便乱跳。比如只有“1”才能变“2”“0”只能变“3”“1”才能变“4”如果代码里出现1直接跳3这种逻辑那基本就是Bug。订单号生成这块很多初学者喜欢用时间戳随机数但在高并发下是可能重复的。我用的方案是Redis INCR自增序列拼上日期前缀比如日期的字符串加上8位自增数字然后通过补零保证长度。这套方案简单高效不用引入雪花算法那种复杂度在单机部署的场景下完全够用。账目对得上是对账功能的硬指标。所以我在支付回调成功之后不是直接改订单状态就算完而是额外维护了一张流水记录把支付平台返回的交易号、订单号、回调金额、回调时间完整存下来。这一笔流水之后无论是用户发起退款还是财务月底做审计都能有据可查。2.3 为什么把库存拆出来单独建表有些同学设计的时候会把库存字段直接放到票种表里比如在ticket_sku表上加一个stock字段下单时直接update这个字段扣减。表面上看简单实际上一到并发场景就出问题。比如同一个票型同一天有100张库存如果100个人同时下单最后的update是走行锁的同一行记录的并发更新会被串行化性能就直接被锁死了。更麻烦的是如果票种表里那个stock是“总库存”而不是“日期库存”你根本没法处理“某一天卖爆了但另一天空着”这种场景。拆成独立库存表之后每次下单只锁对应的那一行日期不同的记录互不干扰多日场次还能单独控制逻辑清晰得多。我还给库存表加了两个辅助字段总库存和已售数。下单时判断已售数 总库存扣减用UPDATE ticket_stock SET sold sold #{num} WHERE sku_id #{skuId} AND sell_date #{date} AND sold #{num} stock这样的原子操作用数据库约束加SQL条件双重保证不超卖远比先查再改安全得多。3. 后端核心模块实现3.1 库存扣减与防超卖我在1.1节里说“把票卖出去”是系统第一目标但准确说是“把票恰好卖出去一张不多一张不少”。为了做到这一点我在下单接口里做了一个看似简单但非常关键的动作用MySQL的条件UPDATE来扣库存。下面这个代码片段就是整个防超卖的核心逻辑Override Transactional(rollbackFor Exception.class) public String createOrder(SkuOrderRequest request) { // 1. 校验用户、令牌、参数 UserCredential user userService.getById(request.getUserId()); if (user null) { throw new BizException(用户不存在); } // 2. 扣减指定日期和票种的库存 boolean deducted ticketStockMapper.deductStock( request.getSkuId(), request.getUseDate(), request.getQuantity() ); if (!deducted) { throw new BizException(该日期票量库存不足); } // 3. 创建订单主记录 Order order Order.builder() .orderNo(generateOrderNo()) .userId(user.getId()) .totalAmount(calcTotalAmount(request)) .status(0) .build(); orderMapper.insert(order); // 4. 写订单明细 saveOrderItems(order.getId(), request.getItems()); // 5. 放入延迟队列30分钟后未支付自动关闭 orderExpireProducer.send(order.getOrderNo()); return order.getOrderNo(); }对应的Mapper SQL是这个update iddeductStock UPDATE ticket_stock SET sold sold #{quantity}, version version 1 WHERE sku_id #{skuId} AND sell_date #{sellDate} AND sold #{quantity} stock AND deleted 0 /update注意这个SQL里的核心条件sold #{quantity} stock这是一个数据库级别的断言。两条并发请求同时到达时数据库的行锁会保证只有一个事务先执行UPDATE另一个事务必须等它提交后再执行此时sold已经变大条件不满足影响行数为0方法里判断deducted为false直接抛异常。这是“先查再改”完全做不到的原子性保障。库存扣减成功后事务里紧接着创建订单。有人可能会问扣了库存但用户不付款怎么办这个问题靠步骤5的延迟队列解决下单成功30分钟后如果没有收到支付回调就把订单状态改成已取消同时把库存加回去。Redis的过期key加监听、RabbitMQ的TTL队列都可以实现延迟通知为了不过度引入中间件我采用的是Spring自带Scheduled轮询加一个记录创建时间的字段每30秒扫描一次超时未支付订单批量关单。3.2 支付回调和幂等处理真实支付系统的对接最怕的不是用户不付钱而是支付平台重复通知。支付宝、微信支付为了保证消息必达会重试回调一个订单可能同一个回调消息推三次五次如果你的接口不做幂等处理用户只付了一笔钱系统却把订单金额累加了三遍账就乱了。我的解决方案是在支付回调入口先查流水表如果这笔交易号已经存在直接返回成功不再做任何处理PostMapping(/pay/notify) public String payNotify(RequestBody PayNotifyDTO notify) { String tradeNo notify.getTradeNo(); String orderNo notify.getOrderNo(); // 幂等判断流水已存在则直接返回成功 int count payLogMapper.countByTradeNo(tradeNo); if (count 0) { return success; } // 校验签名伪代码实际用平台SDK验签 if (!rsaUtil.verifySign(notify.getSign(), notify.getOriginData())) { throw new BizException(回调签名验证失败); } // 事务处理写流水、改订单状态、更新已支付标记 payLogMapper.insert(buildPayLog(notify)); int updated orderMapper.markPaid(orderNo); if (updated 0) { log.warn(订单状态更新失败订单号{}, orderNo); return failure; } return success; }这里还有个细节幂等判断和订单状态更新必须放在同一个事务里不然并发回调重复进来countByTradeNo查到0两个请求同时继续往下执行还是要出问题。Spring的Transactional默认隔离级别是Read Committed同时进来两个回调线程第一个还没提交第二个是查不到前面插入的流水记录的。所以我的做法是把幂等判断也放在事务内并且用订单号的唯一索引兜底数据库层面再拦一道。3.3 二维码票务生成与核销闭环用户支付成功后系统会自动生成一张电子票里面包含一条加密的核销凭证。核销凭证的设计我踩过一次坑一开始我直接放了订单号结果发现订单号规律性强而且包含业务信息放在二维码里一旦被截图转发安全性完全没法保证。后来我改成了UUID加盐再经过AES加密生成一串票据Code存到数据库里二维码内容就是这个票据Code加上一个简单的验证前缀。生成二维码我用的是Google的ZXing库核心代码不算复杂public BufferedImage generateTicketQr(String ticketCode) { int width 300; int height 300; QRCodeWriter qrCodeWriter new QRCodeWriter(); MapEncodeHintType, Object hints new HashMap(); hints.put(EncodeHintType.CHARACTER_SET, UTF-8); hints.put(EncodeHintType.ERROR_CORRECTION, ErrorCorrectionLevel.M); hints.put(EncodeHintType.MARGIN, 1); try { BitMatrix bitMatrix qrCodeWriter.encode(ticketCode, BarcodeFormat.QR_CODE, width, height, hints); BufferedImage image new BufferedImage(width, height, BufferedImage.TYPE_INT_RGB); for (int x 0; x width; x) { for (int y 0; y height; y) { image.setRGB(x, y, bitMatrix.get(x, y) ? 0xFF000000 : 0xFFFFFFFF); } } return image; } catch (WriterException e) { throw new BizException(二维码生成失败); } }核销动作对应的是管理端工作人员扫描用户手机上的二维码。核销接口接收票据Code先解密提取票据ID再校验票据状态如果已经核销过直接返回“重复核销”如果订单是退款状态返回“订单已退款禁止入场”。核销成功后把状态改为已核销并插入核销流水。整个闭环走通后闸口核销人员只需要对着屏幕扫一下1秒内就能知道这张票能不能进。3.4 定时任务与销售统计报表业务跑起来之后运营关心的是每天卖了多少票、卖了多少钱、哪个票种最受欢迎。所以我在管理端做了一张销售统计页后端提供按日、按周、按月聚合的接口。聚合逻辑没有用复杂的OLAP只是每天凌晨2点用一个定时任务把前一天各票种的销量、营收汇总到一张统计表里前端查询时直接读汇总表不用实时扫描订单明细。这里有一个性能隐患我特别提一下如果你不做汇总表用户每次按月份查询的时候系统要去扫描几十万条订单明细再做聚合数据库根本扛不住。做一层预聚合几百行数据就把一天的千万级原始数据浓缩了查询时间从秒级降到了毫秒级这在数据量上来之后的体感差异非常大。定时任务我用的是Spring自带的Scheduled注解固定CRON表达式每天执行一次。有同学建议用XXL-Job这类分布式调度框架但在我看来单体部署阶段Spring自带的调度完全够用引入XXL-Job反而增加部署成本和运维负担。技术选型匹配项目规模这是我一直坚持的原则。4. 前端Vue页面与交互实现4.1 Vue项目初始化与结构划分前端我用Vite创建Vue 3项目命令是npm create vitelatest ski-frontend模板选Vue。装好基础依赖之后我再补上Element Plus、Vue Router、Pinia、Axios四个包。目录结构按照业务模块划分而不是按技术类型划分这样后期加功能时脑袋不需要切换上下文src/ api/ # 所有接口请求都收敛在这里 user.js ticket.js order.js stock.js assets/ # 静态资源 components/ # 通用组件上传、分页、表单弹窗等 router/ # 路由表含前端路由守卫 stores/ # Pinia状态用户信息、菜单权限 views/ admin/ # 管理后台页面 user/ # 用户端页面 utils/ # 封装axios实例、JWT处理、日期格式化等工具接口请求封装这一层很多人上来就直接在每个页面里调axios前期看着方便后期一旦遇到要统一加token、统一处理401、统一弹错误提示的情况就傻了。我把axios实例封装在了utils/request.js里用请求拦截器统一从Pinia里拿token塞到Authorization头里用响应拦截器统一处理HTTP状态码import axios from axios import { ElMessage } from element-plus import router from /router import { useUserStore } from /stores/user const request axios.create({ baseURL: /api, timeout: 10000 }) request.interceptors.request.use(config { const userStore useUserStore() if (userStore.token) { config.headers.Authorization Bearer userStore.token } return config }) request.interceptors.response.use( response { const res response.data if (res.code ! 200) { ElMessage.error(res.message || 请求失败) return Promise.reject(new Error(res.message)) } return res.data }, error { if (error.response error.response.status 401) { const userStore useUserStore() userStore.resetState() router.push(/login) } ElMessage.error(error.message || 网络异常请稍后重试) return Promise.reject(error) } ) export default request4.2 核心页面逻辑用户端最重要的页面是票种列表和下单页。票种列表页直接从后端拉取票种数据按分类Tab展示配合日期选择器切换后调用查询库存接口拿到对应日期剩余量。如果库存显示为0或者“已售罄”前端直接禁用下单按钮给用户一个明确的反馈这样可以大幅减少后端无效请求。下单页面的逻辑是选票种、选日期、选数量、显示总价、提交订单。这里有个前后端容易产生分歧的点就是价格前端展示的价格只能作为参考真正的结算价以后端计算为准。我在后端下单接口里重新计算了总金额前端传过来的价格不参与计算这样防止了用户篡改请求参数把价格改成0.01的漏洞。管理端的核心页面是订单管理和库存管理。订单管理用ElTable展示分页订单列表配合ElTag显示订单状态。库存管理页可以直接改某个票种某天的总库存量比如今天天气特别好临时加了200张票这个操作就要走这个页面。核销页面我单独做了一个全屏路由左边是扫描区域右边是最近10条核销流水方便闸口工作人员在高峰期快速操作。4.3 接口联调与异常状态处理前后端联调时跨域问题几乎每个人都会遇到。开发环境下我给Vite配置了代理把前端发往/api的请求转发到后端的localhost:8080这样浏览器看到的是同源的不会触发CORS。Vite的配置在vite.config.js里server: { proxy: { /api: { target: http://localhost:8080, changeOrigin: true, rewrite: path path.replace(/^\/api/, ) } } }生产环境下前端打包成dist目录后放在Nginx里Nginx配置把/api开头的请求反向代理到后端的Java服务同样不需要后端开CORS。很多同学喜欢在后端加一个CrossOrigin或者全局CORS配置类开发时方便一旦前端改成代理方式后端反而不应该再开CORS不然莫名其妙的预检请求会把Nginx代理绕过去造成Nginx和后端双重请求排查起来特别费劲。Vue的响应式数据在这种管理后台页面里有一些坑我印象最深的是ElTable绑定的数据必须是数组而且不能是readonly代理。有一次我用Pinia的state直接给表格赋值结果发现表格怎么点都不排序排查半天发现是数据的响应式代理导致的。后来凡是ElTable的data我都用浅拷贝或者toRaw取原始数据再赋值这类问题就彻底消失了。5. 部署上线与性能优化5.1 后端打包与部署整个项目开发完之后就是打包部署这一步很多人调试的时候是好的一上线就各种问题大多是部署方式不对导致的。后端用Maven打包执行mvn clean package -DskipTests生成jar包。我建议用外置配置文件的方式把application-prod.yml放到jar同级目录的config文件夹里SpringBoot会自动加载外置配置这样打包一次就能部署多套环境。后端我用Systemd管理[Unit] DescriptionSki Ticket Backend Service Afternetwork.target [Service] Userapp ExecStart/usr/local/java/jdk8/bin/java -Xms512m -Xmx1024m -jar /data/ski-ticket/backend/ski-ticket.jar --spring.profiles.activeprod Restarton-failure [Install] WantedBymulti-user.target内存参数这里我特别说明一下滑雪场售票系统高峰期的特点是QPS集中在某个时间段并不是长期保持高位。所以JVM堆内存设成512M到1G之间比较合理太小了高峰期GC频繁太大了闲置的时候浪费云服务器资源。前端部署更简单npm run build之后把dist目录整个上传到服务器的 /data/ski-ticket/frontend 下Nginx配置root指向这个目录再把/api反向代理到后端8090端口server { listen 80; server_name ski.example.com; root /data/ski-ticket/frontend; index index.html; location / { try_files $uri $uri/ /index.html; } location /api/ { proxy_pass http://127.0.0.1:8090/api/; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } }try_files那一行必须要有因为Vue Router如果启用了history模式刷新某个子路由页面时Nginx会返回404加上try_files回退到index.html就让前端路由接管了。5.2 接口性能与并发压力测试系统开发完不要急着往上丢先压一遍测一测心里有个底。我用JMeter搭了个最基本的压力测试场景100个线程并发创建订单每个线程循环10次模拟1000个下单请求。压测结果我印象很深没加Redis缓存之前票种列表接口的TPS大约在320左右加了Redis缓存之后直接跳到3000多。原因显而易见票种列表接口每次接收请求都要查数据库、映射对象、响应JSON而Redis里存的就是已经序列化好的JSON字符串后端取到直接返回连查库都省了。数据库连接池参数也值得调一调。SpringBoot默认的HikariCP参数比较保守maximumPoolSize默认10对并发下单场景来说太小了。我后来配成了最大20个连接minimumIdle保持10核心是让连接池跟得上业务吞吐量不会因为连接获取等待变成瓶颈。负载情况下的日志也很重要。我用Logback按天滚动记录日志生产环境关闭了DEBUG级别只保留INFO和ERROR每天的日志单独一个文件。配合grep命令排查问题非常方便比如高峰期如果发现下单接口报错率高可以先搜ERROR日志看是不是库存表的锁等待超时再决定要不要调整索引或者优化SQL。5.3 安全加固与合规细节系统里有支付、有用户手机号、有身份证号这些都是敏感信息。我做了几层基础加固密码存储必须BCrypt加盐哈希绝对不允许明文或者MD5。MD5在彩虹表面前基本等于没加密BCrypt每次哈希自动带随机盐同样的密码存到数据库里的值也是不一样的即使数据库被拖走用户真实密码也不会被逆向出来。登录接口和下单接口必须做限流。下单接口我用了一个非常简单的Redis计数器方案同一个IP每秒钟最多允许10个请求超过直接返回“操作过于频繁”。这套逻辑用Spring AOP切面写在存储层的外围几分钟就能实现在高德地图抢票那种工具上这是常规操作在滑雪场售票这种场景里也完全适用。SQL注入防线主要靠MyBatis的预编译参数只要不自己拼接SQL字符串基本不会出大问题。但有一个坑是ORDER BY动态排序有些同学会把前端传的字段名直接拼进SQL这里就需要白名单校验否则拼进去的字段名可能变成恶意表达式。我也看到很多项目完全把安全管理抛给框架然后自己在某个不起眼的角落留下个自定义SQL拼字符串的接口这种漏洞全靠运气去赌不值得。6. 常见问题与排查经验6.1 高频问题与解决方案速查我把开发过程中遇到的高频问题和解决方案整理成了一张表这些问题也是我在不少技术群里看大家反复问过的。问题现象根本原因解决方案前端请求接口报跨域后端/CORS与前端代理重复配置开发环境只用Vite代理生产环境只用Nginx代理后端不开CORS并发下单库存出现负数扣减库存逻辑是先查再改改为原子UPDATE并带soldnumstock断言条件支付回调重复处理接口非幂等回调入口先查流水表配合唯一索引兜底时间字段差8小时JVM时区与数据库时区不一致JDBC连接串加serverTimezoneAsia/ShanghaiJVM参数加-Duser.timezoneAsia/ShanghaiRedis缓存和数据库数据不一致更新数据库后未删缓存写操作后执行delete缓存读操作查询后回填刷新子路由页面404前端history路由未配置回退Nginx加try_files $uri $uri/ /index.htmlElement Plus表格操作按钮不生效响应式代理导致事件绑定异常用toRaw或浅拷贝取原始对象再操作大事务导致锁等待超时下单事务里做了远程调用远程调用移到事务外事务内只做数据库操作商品价格显示0.30000000000000004用了double或float存价格数据库字段用decimalJava用BigDecimal前端展示保留两位小数6.2 我踩过的几个实打实的坑第一个坑是BigDecimal精度问题。我一开始把票价字段设计成了double数据库用double存结果某次下单34.8元乘以3显示出来的总价是104.39999999999999。后台财务看到这种订单直接怀疑系统有问题。后来我把所有价格相关的字段全部改成BigDecimal数据库字段改成DECIMAL(10,2)前端传值时用字符串而不是数字类型这个问题才彻底消失。第二个坑是事务和远程调用的顺序问题。早期我在下订单的事务里直接调了支付平台的预下单接口结果支付平台偶尔超时导致数据库事务一直挂着数据库连接池被耗尽。后来我把远程调用移到了事务外层先本地扣库存建订单提交事务后再去请求支付平台如果远程失败就标记订单为待支付状态由定时任务去重试。这个调整之后系统再没因为远程服务卡顿拖垮数据库连接池。第三个坑是MyBatis-Plus更新时的空值问题。默认的updateById方法会把字段值为null的列也更新成NULL但业务上很多时候我只想更新订单状态一个字段结果把订单金额、购票人等信息全部覆盖成了NULL。解决办法是字段上加TableField(updateStrategy FieldStrategy.NOT_NULL)或者在更新时显式构建UpdateWrapper只set需要的字段。这个问题在加字段比较多的表上尤其容易踩到。6.3 新手如何按这个项目去学Java全栈这个项目从功能复杂度来说非常适合用来作为Java全栈入门练手。如果你想跟着复现一遍我建议的路径是先不要碰代码把滑雪场售票的业务流程用一张A4纸画出来标清楚每个状态和动作然后动手写数据库表结构对着Postman把用户登录、下单、库存扣减这几个核心接口打通再用Vue把用户端和管理端的核心页面做出来前后端联调通过就算完成主线。不要一上来就想着把Redis、消息队列、分布式事务全用上。这些技术本身没有问题但一个单体项目里过度设计反而会让学习曲线变陡。先把基础版本跑通在跑通的基础上再逐渐加东西先加JWT做鉴权再加Redis做缓存再上延迟队列关单。每加一项你都会更清楚它解决的是什么问题而不是为了用而用。结尾这个项目做完之后我的真实体会如果让我把这次开发的经验浓缩成一句话送给准备做类似系统的人那就是能用简单方案解决的就不要上复杂的但数据库的原子性约束一条都不能省。这个项目的核心不在Vue有多花哨、SpringBoot用了多新的版本而在于你有没有把“库存不能超卖、支付不能重复入账、订单状态不能乱跳”这三件事想明白。把这三点守住系统就站稳了守不住页面再好看也是花架子。另外一个很实际的小建议开发阶段数据库建索引不要按书上的来要按你实际的查询语句来。我上线之后发现核销记录表查询很慢分析执行计划后才发现是日期字段没走索引加了一个复合索引之后查询时间从800毫秒降到了30毫秒。这些都是在真实数据出现之后才暴露的问题做课程设计的时候数据量小压根感知不到索引的重要性一旦真实用户流量进来索引设计就是生死线。这个滑雪场售票系统的方向还能继续扩展把微信小程序端加上对接真实微信支付接入Redis Cluster或者把库存模块抽成独立的微服务用消息队列做下单与库存的最终一致性。这些扩展方向的复杂度一层比一层高适合在基础版本跑通之后研究。先把手头这个版本做到逻辑闭环、部署稳定比什么都强。正文写到这里技术细节和一些踩坑记录我都分享得差不多了。如果大家真的跟着做一个类似的系统卡在某个环节欢迎在评论区或者后台留言我看到就会回。
滑雪场的旺季一旦开始售票窗口前面就是一场灾难。排队排到门口、闸口刷票卡死、财务晚上扎账怎么都对不上、票务员被问“还剩几张票”回答不上来——这些我在现场都见过。所以当时决定做一套“javavue基于springboot的滑雪场售票系统”的时候我心里很清楚这不是一个普通的CRUD练习而是一套要扛住并发、算得清账、管得住库存的完整业务系统。这个项目从技术栈上看是标准的SpringBoot Vue前后端分离架构后端用Java写接口、处理业务逻辑前端用Vue做页面交互数据库放MySQL。但它真正难的地方不在技术本身而在“票”这个核心实体上票有票型、有库存、有价格、有有效期卖出去之后还要核销、退款、对账。任何一环没设计好上了线就是事故。这篇文章我会把从数据库设计、库存扣减、订单流程、二维码生成、后端接口、前端页面到部署上线的完整过程拆开写重点讲那些课程设计里不会告诉你、但实战中一定会踩的细节比如超卖、支付回调幂等、跨域配置、JWT过期、Element Plus分页、Nginx反向代理这些。所有代码思路和步骤都是我实际跑通过、验证过的方案适合正在做类似毕业设计、课设或者想入门Java全栈开发的朋友直接参考。1. 系统整体设计与技术选型1.1 项目背景与目标功能滑雪场的售票业务跟普通景区或者电影院有点不一样它的票型非常复杂。除了常见的成人票、儿童票、学生票之外还分平日票和节假日票周末和法定节假日的价格是两套体系有分时段的日场票、夜场票还有租赁套餐比如“雪板雪鞋雪杖”三件套一起租或者单租雪镜、头盔、护具。这些票种还要跟库存关联比如某天日场双板套票就剩17份了卖完就是卖完不能像电商那样等付款后再锁库存。所以系统的核心目标就三件事把票卖出去、把库存算准、把账对得上。从实际功能模块上看我把它拆成了这样几个部分用户端门票浏览与搜索、下单支付模拟支付/微信支付沙箱、订单查询、门票二维码展示、取消与退款。管理端票价与库存管理、订单管理、门票核销、退款审核、用户管理、销售数据统计。公共能力用户注册登录、JWT鉴权、Redis缓存热点数据、定时任务超时取消未支付订单、二维码生成与核销。这个功能清单跟大部分毕设题目的要求是对得上的但你如果只是照着这个列表去写代码最后交出来的东西大概率只是“能跑”离“能用”还差得远。所以我建议所有做类似系统的人上手之前先在纸上把订单状态机和库存扣减流程画出来把最复杂的业务场景想明白再写代码。1.2 技术栈选型的底层逻辑技术选型这件事我一直坚持一个原则不盲目追新选稳定、文档多、自己熟的东西。这个项目后端我用的是SpringBoot 2.7.18并不是说SpringBoot 3.x不好而是这个版本对应JDK 8/JDK 11生态最稳网上资料最多跟MyBatis-Plus的兼容性也最好。很多人一上来就用SpringBoot 3.2甚至SpringBoot 3.4结果MyBatis-Plus版本不兼容、javax换成jakarta、配置类报一堆错光折腾环境就耗掉一两天完全没有必要。如果你的项目刚开始选一个你老师见过、网上有大量教程的稳定版本一定是最优解。持久层我选了MyBatis-Plus而不是原生MyBatis或者JPA。原因很简单原生MyBatis写单表CRUD太啰嗦JPA的复杂查询和自定义SQL写起来又不太直观。MyBatis-Plus处在中间位置单表操作用BaseMapper直接搞定多表联查手写XML也完全可控对订单明细、票种库存这些复杂业务非常友好。前端用的Vue版本是这个项目里我纠结过的一个点。Vue 2在2023年底就停止维护了所以新项目我直接选用了Vue 3。配套的组件库选的是Element Plus路由用Vue Router 4状态管理用PiniaHTTP请求用Axios。这套组合是Vue 3生态的标准搭配遇到问题搜一下基本都有答案不像以前那样要自己到处试。Redis在这个项目里不是摆设。我把它用在了三个地方缓存票种列表和首页营销位减少高频查询打爆MySQL存JWT黑名单实现用户退出登录时立刻让旧token失效生成全局唯一订单号的计数器用Redis的INCR特性保证并发环境下订单号不重复。2. 数据库设计与核心表结构2.1 核心表拆解数据库设计是这类系统里最关键、也最不能偷懒的部分。表结构没设计好后面写业务代码的时候会处处别扭。我最终拆了6张核心表每张表的定位和逻辑我下面串起来讲一遍。第一张是用户表。一般就存手机号、昵称、密码BCrypt加密存储、角色、状态这些字段。角色我用int存1是管理员2是普通用户不做复杂的RBAC权限表因为这个小系统里就两种角色建一堆角色权限表的成本大于收益。第二张是票种表也可以叫商品表。票种ID、票种名称、所属雪场区域、票型类型日场/夜场/节假日、单价、状态。价格字段必须用BigDecimal这个我在后面会专门吐槽一遍。第三张是库存表。这是我认为整个系统设计里最重要的一张表。它把“日期”和“票种”组合成一个维度每条记录代表“某个票种在某天的库存量”这样你可以精确控制每天每种票卖出去多少张。第四张是订单表订单号、用户ID、总金额、支付状态、订单状态、创建时间、支付时间、关闭时间。第五张是订单明细表存每个订单里包含的票种ID、数量、单价、使用的日期。第六张是核销记录表记录了哪张票、什么时候、由哪个闸口/工作人员核销的。2.2 关键字段设计与状态机订单状态我设计了5个状态用int字段存取值0到40未支付1已支付未核销2已核销3已取消4已退款。这个状态机在代码里是有严格流转约束的不能随便乱跳。比如只有“1”才能变“2”“0”只能变“3”“1”才能变“4”如果代码里出现1直接跳3这种逻辑那基本就是Bug。订单号生成这块很多初学者喜欢用时间戳随机数但在高并发下是可能重复的。我用的方案是Redis INCR自增序列拼上日期前缀比如日期的字符串加上8位自增数字然后通过补零保证长度。这套方案简单高效不用引入雪花算法那种复杂度在单机部署的场景下完全够用。账目对得上是对账功能的硬指标。所以我在支付回调成功之后不是直接改订单状态就算完而是额外维护了一张流水记录把支付平台返回的交易号、订单号、回调金额、回调时间完整存下来。这一笔流水之后无论是用户发起退款还是财务月底做审计都能有据可查。2.3 为什么把库存拆出来单独建表有些同学设计的时候会把库存字段直接放到票种表里比如在ticket_sku表上加一个stock字段下单时直接update这个字段扣减。表面上看简单实际上一到并发场景就出问题。比如同一个票型同一天有100张库存如果100个人同时下单最后的update是走行锁的同一行记录的并发更新会被串行化性能就直接被锁死了。更麻烦的是如果票种表里那个stock是“总库存”而不是“日期库存”你根本没法处理“某一天卖爆了但另一天空着”这种场景。拆成独立库存表之后每次下单只锁对应的那一行日期不同的记录互不干扰多日场次还能单独控制逻辑清晰得多。我还给库存表加了两个辅助字段总库存和已售数。下单时判断已售数 总库存扣减用UPDATE ticket_stock SET sold sold #{num} WHERE sku_id #{skuId} AND sell_date #{date} AND sold #{num} stock这样的原子操作用数据库约束加SQL条件双重保证不超卖远比先查再改安全得多。3. 后端核心模块实现3.1 库存扣减与防超卖我在1.1节里说“把票卖出去”是系统第一目标但准确说是“把票恰好卖出去一张不多一张不少”。为了做到这一点我在下单接口里做了一个看似简单但非常关键的动作用MySQL的条件UPDATE来扣库存。下面这个代码片段就是整个防超卖的核心逻辑Override Transactional(rollbackFor Exception.class) public String createOrder(SkuOrderRequest request) { // 1. 校验用户、令牌、参数 UserCredential user userService.getById(request.getUserId()); if (user null) { throw new BizException(用户不存在); } // 2. 扣减指定日期和票种的库存 boolean deducted ticketStockMapper.deductStock( request.getSkuId(), request.getUseDate(), request.getQuantity() ); if (!deducted) { throw new BizException(该日期票量库存不足); } // 3. 创建订单主记录 Order order Order.builder() .orderNo(generateOrderNo()) .userId(user.getId()) .totalAmount(calcTotalAmount(request)) .status(0) .build(); orderMapper.insert(order); // 4. 写订单明细 saveOrderItems(order.getId(), request.getItems()); // 5. 放入延迟队列30分钟后未支付自动关闭 orderExpireProducer.send(order.getOrderNo()); return order.getOrderNo(); }对应的Mapper SQL是这个update iddeductStock UPDATE ticket_stock SET sold sold #{quantity}, version version 1 WHERE sku_id #{skuId} AND sell_date #{sellDate} AND sold #{quantity} stock AND deleted 0 /update注意这个SQL里的核心条件sold #{quantity} stock这是一个数据库级别的断言。两条并发请求同时到达时数据库的行锁会保证只有一个事务先执行UPDATE另一个事务必须等它提交后再执行此时sold已经变大条件不满足影响行数为0方法里判断deducted为false直接抛异常。这是“先查再改”完全做不到的原子性保障。库存扣减成功后事务里紧接着创建订单。有人可能会问扣了库存但用户不付款怎么办这个问题靠步骤5的延迟队列解决下单成功30分钟后如果没有收到支付回调就把订单状态改成已取消同时把库存加回去。Redis的过期key加监听、RabbitMQ的TTL队列都可以实现延迟通知为了不过度引入中间件我采用的是Spring自带Scheduled轮询加一个记录创建时间的字段每30秒扫描一次超时未支付订单批量关单。3.2 支付回调和幂等处理真实支付系统的对接最怕的不是用户不付钱而是支付平台重复通知。支付宝、微信支付为了保证消息必达会重试回调一个订单可能同一个回调消息推三次五次如果你的接口不做幂等处理用户只付了一笔钱系统却把订单金额累加了三遍账就乱了。我的解决方案是在支付回调入口先查流水表如果这笔交易号已经存在直接返回成功不再做任何处理PostMapping(/pay/notify) public String payNotify(RequestBody PayNotifyDTO notify) { String tradeNo notify.getTradeNo(); String orderNo notify.getOrderNo(); // 幂等判断流水已存在则直接返回成功 int count payLogMapper.countByTradeNo(tradeNo); if (count 0) { return success; } // 校验签名伪代码实际用平台SDK验签 if (!rsaUtil.verifySign(notify.getSign(), notify.getOriginData())) { throw new BizException(回调签名验证失败); } // 事务处理写流水、改订单状态、更新已支付标记 payLogMapper.insert(buildPayLog(notify)); int updated orderMapper.markPaid(orderNo); if (updated 0) { log.warn(订单状态更新失败订单号{}, orderNo); return failure; } return success; }这里还有个细节幂等判断和订单状态更新必须放在同一个事务里不然并发回调重复进来countByTradeNo查到0两个请求同时继续往下执行还是要出问题。Spring的Transactional默认隔离级别是Read Committed同时进来两个回调线程第一个还没提交第二个是查不到前面插入的流水记录的。所以我的做法是把幂等判断也放在事务内并且用订单号的唯一索引兜底数据库层面再拦一道。3.3 二维码票务生成与核销闭环用户支付成功后系统会自动生成一张电子票里面包含一条加密的核销凭证。核销凭证的设计我踩过一次坑一开始我直接放了订单号结果发现订单号规律性强而且包含业务信息放在二维码里一旦被截图转发安全性完全没法保证。后来我改成了UUID加盐再经过AES加密生成一串票据Code存到数据库里二维码内容就是这个票据Code加上一个简单的验证前缀。生成二维码我用的是Google的ZXing库核心代码不算复杂public BufferedImage generateTicketQr(String ticketCode) { int width 300; int height 300; QRCodeWriter qrCodeWriter new QRCodeWriter(); MapEncodeHintType, Object hints new HashMap(); hints.put(EncodeHintType.CHARACTER_SET, UTF-8); hints.put(EncodeHintType.ERROR_CORRECTION, ErrorCorrectionLevel.M); hints.put(EncodeHintType.MARGIN, 1); try { BitMatrix bitMatrix qrCodeWriter.encode(ticketCode, BarcodeFormat.QR_CODE, width, height, hints); BufferedImage image new BufferedImage(width, height, BufferedImage.TYPE_INT_RGB); for (int x 0; x width; x) { for (int y 0; y height; y) { image.setRGB(x, y, bitMatrix.get(x, y) ? 0xFF000000 : 0xFFFFFFFF); } } return image; } catch (WriterException e) { throw new BizException(二维码生成失败); } }核销动作对应的是管理端工作人员扫描用户手机上的二维码。核销接口接收票据Code先解密提取票据ID再校验票据状态如果已经核销过直接返回“重复核销”如果订单是退款状态返回“订单已退款禁止入场”。核销成功后把状态改为已核销并插入核销流水。整个闭环走通后闸口核销人员只需要对着屏幕扫一下1秒内就能知道这张票能不能进。3.4 定时任务与销售统计报表业务跑起来之后运营关心的是每天卖了多少票、卖了多少钱、哪个票种最受欢迎。所以我在管理端做了一张销售统计页后端提供按日、按周、按月聚合的接口。聚合逻辑没有用复杂的OLAP只是每天凌晨2点用一个定时任务把前一天各票种的销量、营收汇总到一张统计表里前端查询时直接读汇总表不用实时扫描订单明细。这里有一个性能隐患我特别提一下如果你不做汇总表用户每次按月份查询的时候系统要去扫描几十万条订单明细再做聚合数据库根本扛不住。做一层预聚合几百行数据就把一天的千万级原始数据浓缩了查询时间从秒级降到了毫秒级这在数据量上来之后的体感差异非常大。定时任务我用的是Spring自带的Scheduled注解固定CRON表达式每天执行一次。有同学建议用XXL-Job这类分布式调度框架但在我看来单体部署阶段Spring自带的调度完全够用引入XXL-Job反而增加部署成本和运维负担。技术选型匹配项目规模这是我一直坚持的原则。4. 前端Vue页面与交互实现4.1 Vue项目初始化与结构划分前端我用Vite创建Vue 3项目命令是npm create vitelatest ski-frontend模板选Vue。装好基础依赖之后我再补上Element Plus、Vue Router、Pinia、Axios四个包。目录结构按照业务模块划分而不是按技术类型划分这样后期加功能时脑袋不需要切换上下文src/ api/ # 所有接口请求都收敛在这里 user.js ticket.js order.js stock.js assets/ # 静态资源 components/ # 通用组件上传、分页、表单弹窗等 router/ # 路由表含前端路由守卫 stores/ # Pinia状态用户信息、菜单权限 views/ admin/ # 管理后台页面 user/ # 用户端页面 utils/ # 封装axios实例、JWT处理、日期格式化等工具接口请求封装这一层很多人上来就直接在每个页面里调axios前期看着方便后期一旦遇到要统一加token、统一处理401、统一弹错误提示的情况就傻了。我把axios实例封装在了utils/request.js里用请求拦截器统一从Pinia里拿token塞到Authorization头里用响应拦截器统一处理HTTP状态码import axios from axios import { ElMessage } from element-plus import router from /router import { useUserStore } from /stores/user const request axios.create({ baseURL: /api, timeout: 10000 }) request.interceptors.request.use(config { const userStore useUserStore() if (userStore.token) { config.headers.Authorization Bearer userStore.token } return config }) request.interceptors.response.use( response { const res response.data if (res.code ! 200) { ElMessage.error(res.message || 请求失败) return Promise.reject(new Error(res.message)) } return res.data }, error { if (error.response error.response.status 401) { const userStore useUserStore() userStore.resetState() router.push(/login) } ElMessage.error(error.message || 网络异常请稍后重试) return Promise.reject(error) } ) export default request4.2 核心页面逻辑用户端最重要的页面是票种列表和下单页。票种列表页直接从后端拉取票种数据按分类Tab展示配合日期选择器切换后调用查询库存接口拿到对应日期剩余量。如果库存显示为0或者“已售罄”前端直接禁用下单按钮给用户一个明确的反馈这样可以大幅减少后端无效请求。下单页面的逻辑是选票种、选日期、选数量、显示总价、提交订单。这里有个前后端容易产生分歧的点就是价格前端展示的价格只能作为参考真正的结算价以后端计算为准。我在后端下单接口里重新计算了总金额前端传过来的价格不参与计算这样防止了用户篡改请求参数把价格改成0.01的漏洞。管理端的核心页面是订单管理和库存管理。订单管理用ElTable展示分页订单列表配合ElTag显示订单状态。库存管理页可以直接改某个票种某天的总库存量比如今天天气特别好临时加了200张票这个操作就要走这个页面。核销页面我单独做了一个全屏路由左边是扫描区域右边是最近10条核销流水方便闸口工作人员在高峰期快速操作。4.3 接口联调与异常状态处理前后端联调时跨域问题几乎每个人都会遇到。开发环境下我给Vite配置了代理把前端发往/api的请求转发到后端的localhost:8080这样浏览器看到的是同源的不会触发CORS。Vite的配置在vite.config.js里server: { proxy: { /api: { target: http://localhost:8080, changeOrigin: true, rewrite: path path.replace(/^\/api/, ) } } }生产环境下前端打包成dist目录后放在Nginx里Nginx配置把/api开头的请求反向代理到后端的Java服务同样不需要后端开CORS。很多同学喜欢在后端加一个CrossOrigin或者全局CORS配置类开发时方便一旦前端改成代理方式后端反而不应该再开CORS不然莫名其妙的预检请求会把Nginx代理绕过去造成Nginx和后端双重请求排查起来特别费劲。Vue的响应式数据在这种管理后台页面里有一些坑我印象最深的是ElTable绑定的数据必须是数组而且不能是readonly代理。有一次我用Pinia的state直接给表格赋值结果发现表格怎么点都不排序排查半天发现是数据的响应式代理导致的。后来凡是ElTable的data我都用浅拷贝或者toRaw取原始数据再赋值这类问题就彻底消失了。5. 部署上线与性能优化5.1 后端打包与部署整个项目开发完之后就是打包部署这一步很多人调试的时候是好的一上线就各种问题大多是部署方式不对导致的。后端用Maven打包执行mvn clean package -DskipTests生成jar包。我建议用外置配置文件的方式把application-prod.yml放到jar同级目录的config文件夹里SpringBoot会自动加载外置配置这样打包一次就能部署多套环境。后端我用Systemd管理[Unit] DescriptionSki Ticket Backend Service Afternetwork.target [Service] Userapp ExecStart/usr/local/java/jdk8/bin/java -Xms512m -Xmx1024m -jar /data/ski-ticket/backend/ski-ticket.jar --spring.profiles.activeprod Restarton-failure [Install] WantedBymulti-user.target内存参数这里我特别说明一下滑雪场售票系统高峰期的特点是QPS集中在某个时间段并不是长期保持高位。所以JVM堆内存设成512M到1G之间比较合理太小了高峰期GC频繁太大了闲置的时候浪费云服务器资源。前端部署更简单npm run build之后把dist目录整个上传到服务器的 /data/ski-ticket/frontend 下Nginx配置root指向这个目录再把/api反向代理到后端8090端口server { listen 80; server_name ski.example.com; root /data/ski-ticket/frontend; index index.html; location / { try_files $uri $uri/ /index.html; } location /api/ { proxy_pass http://127.0.0.1:8090/api/; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } }try_files那一行必须要有因为Vue Router如果启用了history模式刷新某个子路由页面时Nginx会返回404加上try_files回退到index.html就让前端路由接管了。5.2 接口性能与并发压力测试系统开发完不要急着往上丢先压一遍测一测心里有个底。我用JMeter搭了个最基本的压力测试场景100个线程并发创建订单每个线程循环10次模拟1000个下单请求。压测结果我印象很深没加Redis缓存之前票种列表接口的TPS大约在320左右加了Redis缓存之后直接跳到3000多。原因显而易见票种列表接口每次接收请求都要查数据库、映射对象、响应JSON而Redis里存的就是已经序列化好的JSON字符串后端取到直接返回连查库都省了。数据库连接池参数也值得调一调。SpringBoot默认的HikariCP参数比较保守maximumPoolSize默认10对并发下单场景来说太小了。我后来配成了最大20个连接minimumIdle保持10核心是让连接池跟得上业务吞吐量不会因为连接获取等待变成瓶颈。负载情况下的日志也很重要。我用Logback按天滚动记录日志生产环境关闭了DEBUG级别只保留INFO和ERROR每天的日志单独一个文件。配合grep命令排查问题非常方便比如高峰期如果发现下单接口报错率高可以先搜ERROR日志看是不是库存表的锁等待超时再决定要不要调整索引或者优化SQL。5.3 安全加固与合规细节系统里有支付、有用户手机号、有身份证号这些都是敏感信息。我做了几层基础加固密码存储必须BCrypt加盐哈希绝对不允许明文或者MD5。MD5在彩虹表面前基本等于没加密BCrypt每次哈希自动带随机盐同样的密码存到数据库里的值也是不一样的即使数据库被拖走用户真实密码也不会被逆向出来。登录接口和下单接口必须做限流。下单接口我用了一个非常简单的Redis计数器方案同一个IP每秒钟最多允许10个请求超过直接返回“操作过于频繁”。这套逻辑用Spring AOP切面写在存储层的外围几分钟就能实现在高德地图抢票那种工具上这是常规操作在滑雪场售票这种场景里也完全适用。SQL注入防线主要靠MyBatis的预编译参数只要不自己拼接SQL字符串基本不会出大问题。但有一个坑是ORDER BY动态排序有些同学会把前端传的字段名直接拼进SQL这里就需要白名单校验否则拼进去的字段名可能变成恶意表达式。我也看到很多项目完全把安全管理抛给框架然后自己在某个不起眼的角落留下个自定义SQL拼字符串的接口这种漏洞全靠运气去赌不值得。6. 常见问题与排查经验6.1 高频问题与解决方案速查我把开发过程中遇到的高频问题和解决方案整理成了一张表这些问题也是我在不少技术群里看大家反复问过的。问题现象根本原因解决方案前端请求接口报跨域后端/CORS与前端代理重复配置开发环境只用Vite代理生产环境只用Nginx代理后端不开CORS并发下单库存出现负数扣减库存逻辑是先查再改改为原子UPDATE并带soldnumstock断言条件支付回调重复处理接口非幂等回调入口先查流水表配合唯一索引兜底时间字段差8小时JVM时区与数据库时区不一致JDBC连接串加serverTimezoneAsia/ShanghaiJVM参数加-Duser.timezoneAsia/ShanghaiRedis缓存和数据库数据不一致更新数据库后未删缓存写操作后执行delete缓存读操作查询后回填刷新子路由页面404前端history路由未配置回退Nginx加try_files $uri $uri/ /index.htmlElement Plus表格操作按钮不生效响应式代理导致事件绑定异常用toRaw或浅拷贝取原始对象再操作大事务导致锁等待超时下单事务里做了远程调用远程调用移到事务外事务内只做数据库操作商品价格显示0.30000000000000004用了double或float存价格数据库字段用decimalJava用BigDecimal前端展示保留两位小数6.2 我踩过的几个实打实的坑第一个坑是BigDecimal精度问题。我一开始把票价字段设计成了double数据库用double存结果某次下单34.8元乘以3显示出来的总价是104.39999999999999。后台财务看到这种订单直接怀疑系统有问题。后来我把所有价格相关的字段全部改成BigDecimal数据库字段改成DECIMAL(10,2)前端传值时用字符串而不是数字类型这个问题才彻底消失。第二个坑是事务和远程调用的顺序问题。早期我在下订单的事务里直接调了支付平台的预下单接口结果支付平台偶尔超时导致数据库事务一直挂着数据库连接池被耗尽。后来我把远程调用移到了事务外层先本地扣库存建订单提交事务后再去请求支付平台如果远程失败就标记订单为待支付状态由定时任务去重试。这个调整之后系统再没因为远程服务卡顿拖垮数据库连接池。第三个坑是MyBatis-Plus更新时的空值问题。默认的updateById方法会把字段值为null的列也更新成NULL但业务上很多时候我只想更新订单状态一个字段结果把订单金额、购票人等信息全部覆盖成了NULL。解决办法是字段上加TableField(updateStrategy FieldStrategy.NOT_NULL)或者在更新时显式构建UpdateWrapper只set需要的字段。这个问题在加字段比较多的表上尤其容易踩到。6.3 新手如何按这个项目去学Java全栈这个项目从功能复杂度来说非常适合用来作为Java全栈入门练手。如果你想跟着复现一遍我建议的路径是先不要碰代码把滑雪场售票的业务流程用一张A4纸画出来标清楚每个状态和动作然后动手写数据库表结构对着Postman把用户登录、下单、库存扣减这几个核心接口打通再用Vue把用户端和管理端的核心页面做出来前后端联调通过就算完成主线。不要一上来就想着把Redis、消息队列、分布式事务全用上。这些技术本身没有问题但一个单体项目里过度设计反而会让学习曲线变陡。先把基础版本跑通在跑通的基础上再逐渐加东西先加JWT做鉴权再加Redis做缓存再上延迟队列关单。每加一项你都会更清楚它解决的是什么问题而不是为了用而用。结尾这个项目做完之后我的真实体会如果让我把这次开发的经验浓缩成一句话送给准备做类似系统的人那就是能用简单方案解决的就不要上复杂的但数据库的原子性约束一条都不能省。这个项目的核心不在Vue有多花哨、SpringBoot用了多新的版本而在于你有没有把“库存不能超卖、支付不能重复入账、订单状态不能乱跳”这三件事想明白。把这三点守住系统就站稳了守不住页面再好看也是花架子。另外一个很实际的小建议开发阶段数据库建索引不要按书上的来要按你实际的查询语句来。我上线之后发现核销记录表查询很慢分析执行计划后才发现是日期字段没走索引加了一个复合索引之后查询时间从800毫秒降到了30毫秒。这些都是在真实数据出现之后才暴露的问题做课程设计的时候数据量小压根感知不到索引的重要性一旦真实用户流量进来索引设计就是生死线。这个滑雪场售票系统的方向还能继续扩展把微信小程序端加上对接真实微信支付接入Redis Cluster或者把库存模块抽成独立的微服务用消息队列做下单与库存的最终一致性。这些扩展方向的复杂度一层比一层高适合在基础版本跑通之后研究。先把手头这个版本做到逻辑闭环、部署稳定比什么都强。正文写到这里技术细节和一些踩坑记录我都分享得差不多了。如果大家真的跟着做一个类似的系统卡在某个环节欢迎在评论区或者后台留言我看到就会回。
