做这个项目之前我其实犹豫过要不要把技术栈拉得更高一点。毕竟市面上微服务、高并发那套东西讲得确实热闹但最后我还是选了Spring Boot Vue这种单体全栈方案。原因很简单这是一个要落地、要交付、还要有人长期维护的商城系统不是用来炫技的实验室产品。整个项目从需求分析到上线跑通前后折腾了将近两个月踩了不少坑也攒了不少经验。这篇文章就把整个设计思路和实现过程掰开揉碎讲一遍尤其是那些在教科书里看不到的细节希望能给准备做类似系统的朋友省点时间。1. 这个系统到底要解决什么一张蓝图拆开的业务面1.1 购物公园商业形态对线上的特殊要求先交代一下项目背景。大概是去年年中有位客户找到我说他们所在的商业综合体准备做一个网上商城。这个商业综合体不是普通的商场而是那种集合了购物、餐饮、亲子、影院、户外广场的购物公园业态。它有大量线下门店和公共空间线上系统的定位不是和线下抢生意而是把逛公园这件事延伸到手机上让顾客在去之前就能看店铺、领券、预约停车甚至直接把商品加进购物车到店试完再付款。这个定位直接决定了很多功能走向。我做的第一件事不是打开IDE写代码而是拉着运营团队开了三次需求讨论会把网上商城这四个字拆成了几个核心场景用户在家刷手机看到某家餐饮店排队太长可以先在线取号顺便看看周边店铺有没有优惠券可领用户逛到某家服饰店看中一件衣服但码数不确定可以在线上预留下单、到店核验用户买完东西不想拎着走可以选择统一到服务台自提或者加钱配送到家停车场和商场的联动消费满多少可以积分抵停车费。这些场景听起来很散但落到系统上就变成了几个核心模块用户中心、商品中心、订单中心、支付与售后、营销中心优惠券/积分、内容运营店铺介绍/活动公告。每块都是一个子系统级别的复杂度但在单体架构里我们还是可以把它拆得清清楚楚。1.2 功能清单定版不是越多越好需求阶段最容易犯的错误就是什么都想做结果每个功能都做成了半成品。我当时和客户达成了一个共识第一版只做交易主链路把逛、加购、下单、支付、退款跑通营销活动只支持满减券和积分抵扣不做拼团、秒杀不做社区种草不做会员日抽奖。原因很实际——这些玩法每一个都会引入额外的并发控制、活动配置和数据一致性逻辑第一版就上等于给自己埋雷。最终定版的功能清单大概是这样的模块功能点备注用户端手机号注册登录、微信授权绑定、个人中心、地址管理简化注册流程优先保证能下单商品端商品列表、详情、搜索、分类筛选商品数据由运营后台录入交易端购物车、结算页、下单、支付、退款/售后支持到店自提及配送两种履约方式营销端优惠券领取/核销、积分累计/抵扣满减券积分抵现门店端订单核销、商品上下架、门店数据看板给实体店员工用页面要足够简单另外还有一个管理后台给运营人员维护商品、订单、财务和内容。这个后台我用的是同一套Vue前端代码通过路由和权限控制区分用户端和管理端没有单独再开一个项目。好处是公共组件能复用坏处是包体积会大一点后面打包时再处理。1.3 技术选型背后的一次次取舍技术选型我盯着两个目标一是一定要稳二是招人好招。所以后端选了Spring Boot 2.x MyBatis-Plus MySQL Redis前端选了Vue 3 Element Plus Pinia Axios。举几个具体的取舍例子。数据库为什么不用PostgreSQL因为团队里最熟的是MySQL而且这个项目的查询压力并不复杂MySQL完全能扛住。为什么不用Spring Cloud那套微服务体系因为交付节奏紧、运维水平有限一个单体应用打成一个jar包就能部署出了问题也好排查。为什么前端用Pinia而不是Vuex因为Pinia对TypeScript的支持更顺代码也更简洁Vue 3官方推荐直接用Pinia没必要为了大家都用Vuex而去用旧工具。有一件事值得多说两句生产环境我没用JWT做无状态登录而是用了传统的Session Redis共享。很多人一上来就喜欢用JWT说前后端分离要无状态。但实际上这个系统的前端有自己的域后端API是独立域天然存在跨域问题JWT虽然能解决一部分问题但踢人下线、修改用户角色、服务端主动失效这些需求JWT做起来非常别扭。最后我用了Spring Session Redis把SessionId放在HttpOnly的Cookie里前端请求时自动携带后端从Redis取会话信息。实测下来无论是安全性和开发体验都比裸JWT好。2. 后端不是“写接口”而是把业务重头扛起来2.1 分层架构Controller层瘦身、Service层管事务这个项目后端代码我严格分成了四层Controller、Service、Mapper、Entity。很多朋友写Spring Boot项目喜欢把业务逻辑全塞在Controller里图省事。但只要你做一个中大型系统这种写法会让你在改需求时痛不欲生。Controller只干三件事接收参数、调用Service、返回统一结果。Service层管业务规则事务加在Service层方法上。Mapper层只处理SQL和对象映射。举个下单接口的例子我简化一下代码结构RestController RequestMapping(/api/order) public class OrderController { Resource private OrderService orderService; PostMapping(/create) public ResultOrderVO createOrder(RequestBody CreateOrderDTO dto, HttpServletRequest request) { Long userId UserContext.getUserId(request); OrderVO orderVO orderService.createOrder(userId, dto); return Result.success(orderVO); } }Service层的核心方法长这样Transactional(rollbackFor Exception.class) public OrderVO createOrder(Long userId, CreateOrderDTO dto) { // 1. 校验购物车和商品状态 ListCartItem cartItems cartMapper.selectCartItems(userId, dto.getCartItemIds()); // 2. 价格计算包含优惠券和积分抵扣 PriceCalcResult calc priceCalculator.calc(userId, cartItems, dto.getCouponId(), dto.getUsePoints()); // 3. 扣减库存下面细讲 boolean success stockService.deductStock(cartItems); if (!success) { throw new BizException(部分商品库存不足); } // 4. 创建订单主表和订单明细 Order order OrderBuilder.build(userId, calc, dto); orderMapper.insert(order); // 5. 记录支付单等待支付 payOrderMapper.insert(PayOrderBuilder.build(order, calc)); return OrderAssembler.toVO(order); }为什么事务一定要放在Service层而不是Mapper层因为一个下单动作涉及购物车、商品库存、订单、支付单四张以上的表任何一步失败都必须回滚否则就会出现库存扣了但订单没建的脏数据。Spring声明式事务最方便一个Transactional搞定。但要特别注意事务只对运行时异常和指定异常生效如果代码里catch住了异常没往外抛事务就不会回滚这是个很隐蔽的坑。2.2 商品库设计SPU与SKU拆分商品的表结构设计直接决定后续扩展是否顺畅。很多初学者会把商品设计成一张大表所有属性都往里塞结果做规格选择时就很痛苦。我做的是标准的SPU-SKU两级结构。SPUStandard Product Unit是商品聚合信息比如某品牌白色T恤是一个SPUSKUStock Keeping Unit是具体可卖的单品比如白色T恤-红色-M码。用户浏览列表时看的是SPU下单结算时选的是SKU。数据结构拆开之后商品详情页的规格联动、库存管理、价格变化都变得非常清晰。SPU表重点字段包括商品名称、主图、详情富文本、分类ID、状态、上下架时间。SKU表重点字段包括SPU_ID、规格值组合、价格、成本价、库存、预警阈值。价格和库存是放在SKU上的因为同一款T恤白色和红色价格可能不一样库存更是各自独立。规格数据我用了一个比较常见的方案用JSON字段存规格项比如[{name:颜色,value:红色},{name:尺码,value:M}]。查询的时候用普通where条件不参与复杂索引展示的时候Jackson直接解析成对象。这个方案简单灵活运营后台配置新规格不需要改表结构MySQL的JSON字段在5.7以上版本已经很稳定性能也没有问题。2.3 一个商品列表接口的“慢查询”优化过程项目做到一半运营反馈商品分类页打开很慢接口耗时都在2秒以上。我排查之后发现罪魁祸首是列表接口里做了一次N1查询。原来的逻辑是先查分类下的SPU列表然后依次查询每个SPU的销量、SKU最低价格、SKU图片、优惠券信息。如果一页返回20个SPU就是20次附加查询。由于优惠券信息还要关联活动表这20次查询里有几次特别慢。优化动作主要有三个第一把SPU列表、SKU最低价和主图合并成一次带子查询的联表查询让MySQL一次返回完整列表数据。SQL层面利用窗口函数取每个SPU下最低价格的SKUSELECT t.spu_id, t.spu_name, t.main_image, sku.price AS min_price, ROW_NUMBER() OVER (PARTITION BY spu_id ORDER BY sku.price ASC) AS rn FROM product_spu t LEFT JOIN product_sku sku ON t.spu_id sku.spu_id WHERE t.category_id #{categoryId} AND t.status 1查到rn 1的行就是最低价SKU。窗口函数在MySQL 8.0里很好用5.7要用子查询或者变量来模拟不过我们生产环境就是8.0所以直接用了。第二优惠券信息改成Redis缓存。营销活动不是每分钟都在变我把当前可领优惠券列表和每个SPU可用优惠券ID做了缓存过期时间设为5分钟。运营在后台修改活动后主动调用一个接口删除相关缓存key下次请求自动重建。第三给查询频率高的列补了联合索引。比如(category_id, status)加了一个索引商品上架状态筛选加上分类筛选走索引后扫描行数从几万降到了几百。优化完商品列表接口耗时从2秒降到了150毫秒左右。这个经验其实很通用遇到接口慢先看SQL执行计划再看是否查了不该查的数据最后才考虑加缓存。缓存是解决方案但不是万能药数据一致性会变复杂能少用就少用。3. Vue端如何让“逛”和“买”两个动作顺滑起来3.1 用组件树还原商场的导览心智购物公园的线上商城和淘宝、京东那种纯货架式商城不一样。用户在线下是逛的状态走到哪看到哪线上界面也要尽量延续这种心智。所以前端首页我设计成了板块化结构而不是单纯的商品瀑布流。整个首页由几个核心组件拼装而成顶部搜索区、楼层导航、活动Banner区、品牌馆、分类橱窗区、门店快报区。每个区域由一个独立组件封装数据来源统一走一个首页聚合接口后端把各板块数据一次性返回前端按组件拆分渲染。组件的拆分原则是展示内聚、数据隔离。比如门店快报区只依赖mallStoreInfo接口品牌馆只依赖brandList接口组件之间不互相传数据。这样改某个板块的样式时不需要翻其他组件的代码项目维护起来很舒服。父组件只负责布局不负责业务数据获取每个业务组件内部自己调接口也方便做懒加载和缓存控制。3.2 购物车与登录态状态管理为什么不能只靠“把数据存起来”前端状态管理用Pinia。网上很多教程把Pinia讲成全局变量管理器这是一种误解。在这个项目里购物车状态和登录态两个store就够我踩很多坑了。先说购物车状态。购物车最核心的需求是用户加了几个商品跨页面跳转后不能丢商品数量变化、选中变化、优惠信息变化要实时反映到结算页。我一开始图省事把购物车数据放在组件内部用provide/inject传下去结果一刷新页面就回到解放前。后来把购物车从后端拉取并在Pinia中维护同时做了两件关键的事每次加购、删购、修改数量时调用后端接口同步数据接口返回最新的购物车快照后更新storestore里存的数据是展示数据真正的计算逻辑比如选中的商品总价、可用优惠、运费使用getter派生。// stores/cart.js export const useCartStore defineStore(cart, { state: () ({ items: [], updatedAt: null }), getters: { selectedItems: (state) state.items.filter(item item.selected), selectedTotalPrice: (state) state.items.filter(item item.selected) .reduce((sum, item) sum item.price * item.quantity, 0) }, actions: { async fetchCart() { const res await api.fetchCart(); this.items res.data.items; this.updatedAt Date.now(); }, async addToCart(spuId, skuId, quantity) { await api.addCartItem({ spuId, skuId, quantity }); await this.fetchCart(); } } });为什么一定要让后端返回快照因为用户的实际库存、价格、优惠信息都以服务端为准前端的store只负责展示层同步避免出现前端显示的价格和后端结算的价格不一致的尴尬。登录态这里也踩过一个坑。用户首次访问时可以不用登录就浏览商品、加购物车但结算时必须登录。如果用户加了购物车没登录就关了页面下次打开还想看到购物车数据怎么办我采用的方案是未登录时购物车数据挂在游客身份下保存在后端Redis中用Cookie里的临时ID标识下单前强制登录登录成功后提供一个合并购物车的接口把游客购物车合并入用户正式购物车。这个逻辑在用户体验上非常自然也是电商系统的通用做法。3.3 按路由懒加载的取舍首屏速度与代码拆分前端打包体积这个问题你开发时完全无感等到上线跑在低端手机上就能感受到什么叫卡。我们的首屏涉及首页、商品列表页、购物车等多个模块打包后主JS文件一度达到了1.8MB在4G网络下加载要好几秒白屏时间非常难熬。解决方案就是路由懒加载把每个页面拆成独立chunk。Vue Router里引入组件时使用动态导入const routes [ { path: /, name: Home, component: () import(/views/Home.vue), meta: { title: 首页 } }, { path: /product/:id, name: ProductDetail, component: () import(/views/ProductDetail.vue), meta: { title: 商品详情 } }, { path: /cart, name: Cart, component: () import(/views/Cart.vue), meta: { title: 购物车 } } ]这样改造完首屏只需要加载首页对应的chunk其他页面代码等用户真正跳转时才加载。首屏JS体积从1.8MB降到了340KB左右体感快了很多。当然懒加载也有代价就是跳转新页面时会有短暂加载态。我的处理是在路由切换时显示顶部进度条用NProgress这种轻量级组件用户感知到的不是卡而是正在加载体验反而更稳。另外还有一个细节第三方库按需引入。Element Plus如果全量引入光它自己就有几百KB。我改成按需引入组件和样式用unplugin-vue-components这个插件在构建时自动解析模板中用到的组件只打包需要的部分。这一步也省了不少体积。4. 订单闭环支付、库存、对账这三座大山4.1 下单时的幂等与防重订单模块是整个系统里最容易出隐性Bug的地方。用户在结算页点了一次提交订单按钮如果网络抖动让他又点了一次或者前端没有把按钮置灰就会发出两个请求。如果后端不做防重就会产生两笔一模一样的订单用户被扣两次钱这种事故一旦发生售后处理起来极其麻烦。我的防重方案是在服务器端做幂等控制。核心思路生成一个唯一的idempotentKey作为请求标识。前端进入结算页时就向后端申请一个下单令牌这个令牌存放在Redis里设置了5分钟有效期提交订单时必须携带这个令牌后端检查令牌是否存在存在则删除令牌并继续下单不存在则说明这个下单请求已经处理过直接返回请勿重复提交。代码逻辑差不多是public OrderVO createOrder(Long userId, CreateOrderDTO dto) { String idempotentKey dto.getIdempotentKey(); Boolean success redisTemplate.opsForValue() .setIfAbsent(order:idempotent: userId : idempotentKey, 1, 5, TimeUnit.MINUTES); if (!success) { throw new BizException(请勿重复提交订单); } // 继续后续的下单逻辑 }setIfAbsent是个原子操作同一时刻只会有一个请求能拿到这个key其他请求直接失败天然防重。不过要注意这个key定在5分钟是有讲究的太短了用户思考时间不够太长了Redis里堆积太多垃圾key。我是根据实际运营数据调的大部分用户从结算页到下单不会超过3分钟5分钟是比较合适的值。4.2 库存扣减为什么用Redis预扣更稳妥下单时要扣库存退货时要加库存但多线程并发下单时很容易出现超卖问题。比如某商品库存只有10件10个人同时下单每个人都查到库存大于0然后都扣减成功最后库存变成负数超卖了。传统方案是SQL扣减时带上库存条件UPDATE product_sku SET stock stock - 1 WHERE sku_id #{skuId} AND stock 0这个语句在数据库层面是原子性的affected rows返回0就表示库存不足。这个方案其实够用但在这个系统里我用了更符合场景的Redis预扣方案原因有两点直接扣数据库在高并发下会让行锁竞争激烈下单接口响应变慢我们希望在用户点击立即购买时就能立刻反馈库存不足而不是等订单写库时才报错。Redis预扣的核心逻辑是用Redis的DECR命令预扣库存如果结果大于等于0说明占位成功如果结果小于0说明库存不足同时执行INCR把扣掉的库存还回去。真正下单成功后再异步同步库存到数据库。如果订单超时未支付要释放预扣的库存。public boolean deductStock(ListCartItem items) { for (CartItem item : items) { Long remain redisTemplate.opsForValue() .decrement(stock:sku: item.getSkuId(), item.getQuantity()); if (remain 0) { // 扣超了回滚库存 redisTemplate.opsForValue() .increment(stock:sku: item.getSkuId(), item.getQuantity()); return false; } } return true; }这里有个细节要说清楚Redis里的库存数据怎么初始化我在商品上下架时同步写入Redis并且每天早上用定时任务重新从MySQL同步一次库存防止极端情况下Redis数据因为过期或者缓存重建丢失导致的不一致。订单完成支付后异步任务会更新MySQL中的真实库存。这套机制会带来轻微的库存短暂不一致比如用户在界面上看到有货下单时却说库存不足这个对运营来说是可以接受的总比超卖强。4.3 支付回调与订单状态机的推进支付环节我接入的是通用的第三方支付平台。支付行为的核心是异步回调用户付完钱支付平台会向我们的回调接口发一个通知告诉我们这笔订单支付成功。这里有个新手必踩的坑回调接口不是只调一次平台会有重试机制可能同一笔订单回调好几次。如果回调逻辑不是幂等的就会把订单状态从已支付更新成已完成甚至重复加积分、重复通知发货。我设计订单状态机的时候每一步的状态转移都不是无条件的当前状态事件目标状态备注待支付用户发起支付已支付第三方回调确认待支付超时未支付已取消定时任务处理已支付商家发货待收货后台手动操作待收货用户确认收货已完成支持自动确认已完成用户申请售后售后中进入退款流程回调接口里我拿到支付通知后首先要校验签名和金额确认这个通知是真的然后更新支付单状态。在更新订单状态时我会加一个条件判断只能从待支付状态流转到已支付如果当前状态已经是已支付说明回调已经处理过直接返回成功不再执行后续逻辑。public void handlePayCallback(PayNotify notify) { // 1. 验签 if (!payClient.verifySign(notify)) { throw new BizException(签名校验失败); } // 2. 更新支付单 PayOrder payOrder payOrderMapper.selectByOutTradeNo(notify.getOutTradeNo()); // 3. 幂等判断支付单已处理则跳过 if (payOrder.getStatus() PayStatus.PAID) { return; } // 4. 更新订单状态 int rows orderMapper.updateStatusIfCurrentStatus(payOrder.getOrderId(), OrderStatus.WAIT_PAY, OrderStatus.PAID); if (rows 0) { // 支付成功后的联动增加积分、发送通知、释放库存扣减确认 salesService.afterPaid(payOrder.getOrderId()); } }另外一个容易忽略的点支付回调涉及金额核对。用户下单时生成了一个支付单里面存了预期金额回调通知里也带了一个实付金额。这两个金额必须一致才算支付成功否则可能是黑客伪造的请求或者平台异常必须进入人工核查队列。5. 上线前必须做的性能体检与踩坑记忆5.1 数据库连接池与慢SQL的排查上线前我做了一轮压测并发量到200时支付回调接口出现大量超时。查日志发现数据库连接池Tomcat JDBC的连接数不够等待获取连接的时间过长。HikariCP默认最大连接数是10200并发时肯定不够。我调整了连接池配置最大连接数调到50最小空闲连接数调到10同时优化了几个核心接口的SQL连接池问题才缓解。调整连接池不能盲目往高调数据库连接数是和MySQL的max_connections挂钩的。连接数太高MySQL会频繁切换线程上下文性能反而下降。我当时的经验值是单实例4核8G的数据库连接池上限50每个连接占用的内存大概在10MB-20MB之间50个连接就是1G左右这个量级可以接受。慢SQL排查我用的是MySQL自带的slow_query_log打开慢查询日志把阈值设为1秒然后跑了一晚上。第二天收集日志看到几个问题一是商品搜索的LIKE %关键词%查询没有走索引二是订单列表在按时间排序时使用了文件排序。针对商品搜索我引入了MySQL全文索引但后面发现准确率不如人意最终换成了ES。订单列表那个问题字段排序用的默认方向需要微调建了一个(user_id, create_time)联合索引查询计划就避免了文件排序。5.2 前端打包体积与图片懒加载前面讲了路由懒加载其实还有一个大头是图片。购物公园商城是重度图片应用每个商品至少三张图Banner活动图、门店实拍图加一起光首页就有几十张图。如果不做处理用户打开首页会一次性下载所有图片并发请求太多还会被服务器限流。我做了三件事图片全部走CDN源站只存一份访问时通过URL规则生成不同尺寸的缩略图页面滚动时用懒加载指令图片进入视口前不请求img v-lazyitem.imageUrl :altitem.name后端返回的商品图片URL统一加上?imageView2/1/w/400/h/400这类缩略图参数按需裁剪。列表页只要400像素的图详情页才要800像素以上的原图。这样每个列表接口返回的图片体积平均不到50KB。还有个小细节给图片加width和height属性可以避免页面加载时因图片尺寸未确定而导致的布局跳动。这个看起来不起眼但对用户体感影响很大尤其是移动端。5.3 几个我自己调了很久才明白的“反直觉”问题做这个项目的过程中有几个问题回头看挺有意思都属于原理都懂实际一跑就翻车的类型。第一个是跨域问题。前后端分离后前端跑在http://localhost:8080后端跑在http://localhost:8081开发时我从前端页面请求后端接口浏览器直接拦截了。我一开始以为加上CrossOrigin注解就万事大吉结果发现携带Cookie的请求还是通不过。原因是跨域时浏览器不允许跨域请求携带非白名单的Cookie而且Access-Control-Allow-Origin不能是*必须明确指定前端域名。后来我把CORS配置写成了后端全局配置允许前端域名并设置allowCredentials(true)这才把问题解决。生产环境我用Nginx做了反向代理让前后端共用同一个域名同源策略就不再卡人了。第二个是全局异常处理。最开始我的Controller没有统一异常处理结果前端拿到的错误信息千奇百怪有的是一堆堆栈有的是undefined。后来我加了一个RestControllerAdvice的全局异常处理器把业务异常、校验异常、未知异常分别做了格式化。这个不只是体验问题更关键的是线上排障时统一格式的日志能让我快速定位到是哪个环节出的问题。第三个是前端接口请求超时。上线后运营反馈某些后台操作经常卡死。排查后发现是Axios默认没有设置超时时间服务端线程池满的时候请求会一直挂在那里用户看着像死机。我给Axios设置了15秒超时并在后端SuperService层的耗时操作上加了一个异步改造把一些不需要实时返回的日志、短信、积分操作异步化。这样即使某个环节慢了用户也等得到反馈。写在最后整个项目从立项到上线最深的体会是做系统不是堆功能而是要在每一层做决策并且为决策承担后果。Spring Boot和Vue这对组合的生态足够成熟成熟到一个人就能撑起一个中型的电商系统但这种成熟也意味着所有坑都有人踩过只要你愿意多花时间查原理、看源码大部分问题都能找到解法。项目上线后我收到过运营同事的反馈说顾客在商场里拿着手机核销订单、领停车券的时候确实比以前方便了很多。作为一个开发者听到这种反馈比代码跑通本身更让人高兴。如果这篇文章提到的哪个细节能帮到你我也算没白写这趟经验分享了。
